Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Dynamic Schema Generation for Changing Data Models

Dynamic Schema Generation for Changing Data Models

Designing *one* API is hard. Aiming to find the perfect sweet spot, a lot of decisions are to be made, so every API consumer gets what they need.
In our case the API surface changes between every single of our customers. Learn about design decisions & trade-offs when designing a *thousand* APIs at once.

Avatar for Stephan Schneider

Stephan Schneider

September 05, 2018
Tweet

More Decks by Stephan Schneider

Other Decks in Technology

Transcript

  1. THERE ARE WELL-THOUGHT GRAPHQL APIS OUT THERE https://youtu.be/2It9NofBWYg - Leanne

    Shapton (Shopify) https://youtu.be/wPPFhcqGcvk - Kyle Daigle (GitHub)
  2. SHIFT OF RESPONSIBILITY historically we decided how the API looks

    like now we only explain how the API is derived
  3. OTHER OPTION Let the user describe the schema they want

    in SDL doubled effort when changing the shape hard for us to understand the user intention without new syntax
  4. at best, no changes to the models are needed the

    same internal data query adapter is used we can break with expectations where necessary
  5. In the example before, everything is obvious: the type name

    should be Restaurant. But what about:
  6. different name and ID name can be changed, ID cannot

    (auto-generated IDs can be invalid, starting with a number) Is it Category or FoodCategoryCuisine?
  7. fields like sys are colocated in the same namespace no

    fields indirection field IDs can be changed
  8. USEFUL ERROR MESSAGES { errors: [{ message: "Schema generation failed.

    The type generated from the content type 'blog' contains a field with id 'sys' which is reserved.", extensions: { contentful: { code: 'RESERVED_FIELD_NAME', details: { contentTypeId: 'blog', fieldId: 'sys' }, requestId: 'xxx' } } }] }