GraphQL Conference 2021
Last week I attended (virtually) the GraphQL Conference 2021 (https://graphqlconf.org/). I didn’t get to attend the full event, but I thought I’d go over sessions I did get to attend before other meetings cut me short:
Keynote Panel:
There are consistent GQL patterns emerging in caching, error handling, refetches, deprecated decoration/tags, and schema federation. Tools are emerging to coordinate these standards (Apollo Studio, typescript integrations, plugins). Scott: when I worked GraphQL on an external analytics /BI project, we had to consider all of these without mature existing patterns in place. Each was a real challenge and a potential delay to product delivery.
It’s (still) gaining steam, Apollo just received $130 million in Series D funding they intend to spend on new devs. Scott: a friend of mine got a cold offer just today and ask me if I had referred him (I hadn’t).
Per Laurie Barth from Netflix, GraphQL moves a lot of decisions from the application to the client, but it also moves a lot of problems from the application to the client. Scott: understandability, exploration, optimization of calls, much more.
It’s a different mindset. Have to optimize for client-side development (per my note on that last bullet).
Sean Grove – GraphQL as a Generalized Next-Gen API Client:
Federation of Soap, OpenAPI, AsyncAPI, and GraphQL via an API Catalog: one graph queries.
Proponent of spending time reading your API.
Roy Derks – Headless
Headless Schema Stitching: https://github.com/royderks/saleor-strapi-stitching
https://github.com/gmac/schema-stitching-handbook
Scott: At this point, it’s fairly obvious federation is paramount for many presenters/companies using GraphQL.
Colby Fayock – Wordpress and GraphQL
Less interesting for me personally, but a good walkthrough of the basics around how a GraphQL interface gets rid of a lot of the all-or-none pattern that can cripple REST interfaces that are chatty (as was the case for WordPress pre-version 4.7).
Tanmai Gopal
Concept of batch and dedup in the GraphQL resolvers.
More succinctly, you get better gains federating the data instead of the services. Avoid overlap, repeat…optimize. Per below, your data structure may need to be tailored in some ways to your GraphQL schema and the resolvers/logic may need some unusual optimization as well to avoid waste.
Min Chen and Karthik Balasubramanian – Automated Schema Generation from ER-Based Service Modeling
Linkedin optimizations to use declarative ER-based service modeling to create the schema.
Combination of GET/FINDER and extensions to get performant arrays (basically on tables before joins happen) where GraphQL might otherwise trigger a deep lookup before resolving.
My last job our GraphQL schema was auto-generated by the code with some decorators. We didn’t get as far as flattening the ids to increase performance, but we didn’t lockstep schema changes against code initially – code moved and schema followed automatically. Did mean we had to move code around and regenerate when we considered (and updated) the “usuability” of the schema structure for external clients. Per the speakers and per my own experience, data source structure is crucial and may have to complement your GraphQL implementation for performance and usability.
They did have to address gaps in the GraphQL definition language and their implementation.
Uri Golshtein – GQL to the Next Level:
I was excited about this one. I have a FHIR-GQL presentation of his queued up to watch this week.
Works for Envelop – create plugins for GraphQL (https://the-guild.dev/blog/introducing-envelop)
Of the opinion most schemas are too opinionated and the more you can generalize and let tools handle it, the better. Scott: it’s interesting, because sometimes “opinionated” makes it much easier for the client to understand. There’s a balance. If the client doesn’t use it because it’s non-intuitive, then it has little value even if it’s less opinionated.
Solve the hard problems once, use anywhere.
Frameworks for frameworks.
No comments:
Post a Comment