eZ Platform Discussions

Feedback wanted: GraphQL and APIs, entry points into content?


#1

Hi ! I need your help. I’m working on our GraphQL API, and I’m researching about the entry points used to retrieve content.

I’m mostly thinking of mobile or independent frontend apps (e.g. React or similar), as opposed to backend apps. If you have use-cases of what you would (like to) retrieve, and using which criteria (set of location ids, types…), I am very much interested.

Right now, the schema exposes content types as the main entry point:

{
  content {
    blogPosts {
      title
      body { html5 }
      image { 
        alternativeText
        variations(identifier: large) { uri }
      }
    }
  }
  media {
    images(query: {ParentLocationId: 1234}) {
      name
      image { uri }
    }
  }
  pages {
    landingPage(id: 235) {
      page {
        zones {
          blocks { }
        }
      }
    }
}     

Relations can be followed, and I have a prototype that cleanly exposes query results from a given content item (https://github.com/bdunogier/ezplatform-query-fieldtype).

If you were to use that API, what would you be looking for ?

Reminder: the package is at https://github.com/bdunogier/ezplatform-graphql-bundle. I strongly suggest you go with the dev branch, but master will work as well.


#2

Hey Bertrand,

In 99% cases we need to access locations under given parent location ID with basic attributes such as $name or $title, $publicationDate, $author, $intro, $image (with specified variation) and $meta such as $locationId, $contentId, etc… So in the first response you should get most of this things you need without a need to preform extra requests to the backend. I assume given query can get params for which field values you want to get returned in the body of response. So, yes, locations would be my preferred way to work with and filter based on the content type.


#3

Thank you for your feedback Lukasz.

The currently schema exposes first and foremost content types groups and content types. The root has the content types groups, and below, the content types, with two fields for each:

  • the plural version (ex: “articles”) returns lists of the content type. An extra “query” argument can be passed to filter results.
  • the singular version (ex: “blogPost”) returns one item of that type. It acceps as arguments id, locationId and remoteId.

The returned items are typed according to the content structure of the instance (the schema is generated). Subfields are the field definitions from the content type, and are queried depending on the field type; some field types, like landing page, have a very deep integration, while other are much more simple.

Examples (with the ee-demo content):

{
  content {
    places(query: {Text: "new york"}) {
      name
      location { 
        latitude
        longitude
        address 
      }
    }
  }
  pages {
    landingPage(locationId: 2) {
      name
      page {
        zones {
          blocks {
            ... on EmbedPageBlock {
              contentId {
                __typename
                ... on BlogPostContent {
                  title
                  tags {
                    text
                  }
                }
              }
            }
          }
        }
      }
    }
  }  
}

While developing this, it became clear that the better the modelled content was, the better the resulting API. The idea behind my search for feedback is that I think we can avoid most ID hardcoding. For instance, a well designed page object will give you access to other items, by means of blocks with embed content.

There are ways to expose those. An example would be an endpoint that returns a navigation structure, where containers from that structure can be queried for subitems.