madek / madek-graphql-api

Madek

Madek is a media archival, management and sharing system that can archive video, audio and image files along with their metadata. The system crowdsources the chore of retrieving and assigning metadata to the users themselves instead of putting all the burden on the archival expert.

Current Version

The latest stable release is to be found here.

Components and Services

The Madek-Web-Application

The madek-webapp is the main component of Madek. It also has a dedicated Admin Panel as well as a dedicated Authentication Service & UI.

The Madek-API

The madek-api is a JSON / JSON-ROA API for Madek.

Copyright and license

Madek is (C) Zürcher Hochschule der Künste (Zurich University of the Arts).

Madek is Free Software under the GNU General Public License (GPL) v3, see the included LICENSE file for license details.

Visit our main website at http://www.zhdk.ch and the IT center at http://itz.zhdk.ch

madek-graphql-api's Issues

feat: Lists/Collections for MediaEntries

minimal description in query form of the next features to implement. ask for clarification if needed. feel free to send a PR for single steps or just 1 for all.

---

step 1: list of entries

query {
  # get a list of all media entries
  allMediaEntries { 
    id 
    title 
  }
}

Returns array of entries

{
  "allMediaEntries": [
    { 
      "id": "1234",
      "title": "xyz"
    },
   …
  ]
}

step 2: list arguments

query {
  # get the newest 100 entries
  allMediaEntries(first: 100, orderBy: CREATED_AT_DESC) { 
    id 
    title 
  }
}

schema: add enum for media entry sort options with CREATED_AT_DESC and CREATED_AT_ASC

step 3: collection by id with children of type entry

query {
  # get a collection by id including the list of child media entries
  collection(id: "1234…") { 
    id 
    mediaEntries { # same kind of list as in previous steps
      id
      title
    }
  }
}

further

TBD, but likely will be "build a relay-style Connection for the list of media entries

---

aside: an overview of the next steps in general/after this ticket. i hope it helps to better gauge the scope of the above, mainly what not to do for now.

• a few more features: extend types and queries with some more interesting fields, so a demo client using the API can show something somewhat useful
• specs
  • review test strategies, write down something short to guide us going forward
  • add more specs (integration-like, inspired by usage of demo client)
• cleanup models/factories etc (as already discussed, this will be much simpler to do test-driven once more tested features are implemented)
• going forward, alternate between adding features and reviewing the schema and implementation, possible making changes to the schema (in collaboration
  with me) and likely doing refactorings (on your own, but guided by the intended awesome test coverage ;))

---

use case: gallery slide show

see this doc for use case description: https://github.com/Madek/madek-graphql-api/tree/mfa/example-fancybox/examples/fancybox

mock prototype (same as example HTML): https://fancybox-r7lu5zlsc.now.sh

you can make changes to query/data examples if you think it better suits the use case or implementation.
in particular, you can use a relay-style connection instead of simple lists.

timeline: lets check on monday the 17. if first version by friday 21. is possible.

tasks:

• API part, query from README should return expected data
• scenario tests: build a similar set with 3 image-entries inside using factories, then execute same example query
• unit tests: add some basic tests to ensure the public permissions are honored (aka test the default scope works). For MediaEntry and Collection, check that its not visible if get_metadata_and_previews is false, and vice versa.

fix meta data types

2 issues with the metadata as it is currently checked in, both related to not having enough test data/specs till now.

new spec: $ git cherry-pick b7361442a8 b736144

fix:

• some missing models need to be copied (uninitialized constant Keyword), without it spec wont run at all
• make spec non-pending: implement string value handling so test passes

metaDataByContext

[WIP specification]

• contexts arg is optional, if not given = all contexts/no filter
• metaData array must be sorted by context_key.position

query {
  metaDataByContext(contexts: ["summary"]) {
    id
    label
    metaData {
      id
      metaDatum {
        id
      }
      contextKey {
        id
        position
        label
        description
        metaKey {
          id
        }
      }
    }
  }
}

{
  "metaDataByContext": [
    {
      "id": "summary",
      "label": "Medieneintrag",
      "metaData": [
        {
          "id": "1234",
          "metaDatum": "[[[Type MetaDatum]]]",
          "contextKey": {
            "id": "44283286-7506-4618-92ef-0e92735a39d2",
            "label": "Titel",
            "position": 1,
            "metaKey": "[[[Type MetaKey]]]"
          }
        }
      ]
    }
  ]
}