Description: Darrell has recently spent a lot of time in and around the extensible GraphQL validation system. What started as a simple rule to fill a gap in the default rule set, soon turned into a plethora of custom rules to validate every detail of schema business logic in the Neo4j GraphQL Library. He will walk through some basic rules, and demonstrate how the system has been used to implement more complex logic.
05:50 - 06:00 PM (10 mins): Unify Data Sources at the Edge
Description: Curious about how a consumer-grade social application’s data architecture has been designed? Taz will review the end-to-end GraphQL architecture used at Guild. Everything from Relay to Persisted Operations cached on Cloudflare Workers to efficient Postgres schema resolution. The session is intended to be half show-and-tell and half open discussion with the audience.
06:10 - 06:30 PM (20 mins): Improving the GraphQL developer experience on
, we have made great strides in stabilizing development cycles in our GraphQL gateway. We'll discuss the issues we used to have, how we used community tools to fix them, and where we're looking to go from here.
Description: So you spent all this time building and deploying your GraphQL API but your users are reporting slow queries and crashes. Before you can pinpoint those issues you first need to know how many requests you are getting, what each query was, and what’s going on in your resolvers. Join Dan where you will learn what observability is, how you can install it onto your GraphQL API, and how you can use it to improve your user's experience.
06:40 - 7:00 PM (20 mins): GraphQL without Relay is not worth it
Description: GraphQL has helped the industry realize the benefit of having typed APIs. But does that mean that if we switch over to a typed API like gRPC or OpenAPI then GraphQL is overkill? In this session, I want to discuss how GraphQL with Relay is critical to UI development and how GraphQL without Relay leads us to reinvent the wheel on state management and API libraries again and again. And also as a corollary, how using GraphQL without Relay might not really be worth it!
07:00 - 7:10 PM (10 mins): GraphQL and caching, when to make it more RESTful
Description: We currently worked with an API that had to scale to serve multiple regions and millions of users. Introducing caching for such numbers is a common and battle-tested way to reduce costs. With services like Stellate, this is no longer impossible even when using GraphQL.
That is great news, however, also poses some challenges. We need to pay attention to how structure our types so we can fully utilize caching.
How to rethink some GraphQL schema designs so we can have the best of the data-driven paradigm of GQL and have amazing caching capabilities at the same time?