Presentation: Parallelizing Product Development with GraphQL

Track: JavaScript and Beyond: The Future of the Frontend

Location: Windsor, 5th flr.

Duration: 11:50am - 12:40pm

Day of week: Tuesday

Level: Intermediate

Share this on:

What You’ll Learn

  1. Hear about GraphQL and the Schema Definition Language.
  2. Learn how to use GraphQL and SDL to separate back-end from front-end development so they can proceed independently.
  3. Find out what are some of the limitations GraphQL has.


In this talk we will cover how to drive API development forward with the data model as the source of truth using the GraphQL Schema Definition Language. In typical REST approaches, UI development is often blocked on APIs and API development is hampered by not knowing how clients are using the API. With a GraphQL approach the data model is the shared point of communication separating the implementation details of the endpoint from the implementation details of clients. Takeaways from this talk will include practical knowledge of Prisma, Apollo, GraphiQL, and more. The audience will also walk away knowing how to define a new GraphQL API, generate fake data, and communicate API evolution through directives. Whether building a new product, breaking up a monolith, or just plain prototyping GraphQL makes it easier to communicate and verify changes by focusing on data modeling rather than software abstraction.


What are you doing these days? 


I work at Honeycomb, improving people's access to observervability. I work on product and anything related to the product. I'll go visit customers and help them do integrations, or I will change the UI or change the way that we're doing the data fetching. Things like that.


What's the motivation for the talk?


A number of times in my career which has been very consulting heavy I've been asked to do some rewrite or very large refactor. Specifically there's one case that I can think of. We had to rewrite Docker from two separate Django applications that didn't have APIs into a universal React application. And GraphQL is a tool that can be used as a solution to a social problem which is you have these REST APIs that need to be built before the front-end is built, but you can use the GraphQL Schema Definition language to do the data model first, and the implementation of the back-end can proceed in parallel with the front-end.

So you can use the Schema Definition Language as your data model first, and in parallel you can do the back-end in Go or in JavaScript. You can do the front-end in various technologies. But they are all schema definition language first which separates the social problem of which one do we need to do first and how we communicate between them.


What's the main focus of your talk?


It's focused on the Schema Definition Language. There are a number of tools that I will bring up, that are mostly Node-based, that use the schema to build your resolvers. I'm not going to go into resolver implementation but I will go into how the schema lets you separate the resolver implementation from the front-end data fetching implementation.


Are there limitations on what you can do with GraphQL that you'll talk about?


Yes, there are some limitations. If you have a real-time application, subscriptions and GraphQL were not well understood yet. If you try to go down a real-time GraphQL API you might run into a lot more problems than somebody else, and you have to become an expert in GraphQL subscriptions and the underlying implementations.


Is that part of the talk?


I'll touch on it but it won't be a big part of it.


Who's the main persona for the talk?


The main persona are these people who need to either take a set of APIs they have right now and move them from a monolith to microservice, or they need to develop a new product with a new set of APIs. In either of those cases you can put GraphQL as the boundary between the front-end and the back-end.


What do you want someone to walk away with from the talk?


I want people to walk away from this talk with an understanding of GraphQL not only as a useful piece of technology, but also as a solution to this social problem. How do we do this iterative development of our data model?

Speaker: Chris Biscardi

Product Engineer @Honeycomb

Chris is a product engineer currently working at Honeycomb on Observability tools. Before Honeycomb, he spent most of his time independently consulting; taking breaks to build the UI team at Docker and the Design Systems team at Dropbox. In his spare time, Chris builds tools for maintainers at


Find Chris Biscardi at

Last Year's Tracks

Monday, 5 March

Tuesday, 6 March

Wednesday, 7 March