When (Not) To Create A GraphQL Server

Rate this content
Bookmark

Every (frontend) developer is asking for a GraphQL API but often lacks the backend knowledge to create a performant server. There are many different flavors in creating the perfect GraphQL server, ranging from schema-first to code-first or even auto generated solutions. Let me show you the pros and cons of each solution so, after this talk, you'll know which solution would best fit your team.

This talk has been presented at GraphQL Galaxy 2021, check out the latest edition of this Tech Conference.

FAQ

The speaker is Roy, a software engineer and public speaker.

The main challenge is making a GraphQL server that is scalable.

To optimize client requests, wrap microservices, and provide autonomy to users.

The two main patterns are code-first and SDL-first (schema-first) GraphQL servers.

In a code-first GraphQL server, you start by writing resolvers which generate a schema and create a server based on them.

In an SDL-first GraphQL server, you write your schema first and then create resolvers based on this schema.

The downside is the lack of separation of concern, as the schema is generated from the resolvers, giving less control over the final schema.

StepZen is a tool that allows you to create a GraphQL API automatically from a schema, connecting various data sources and deploying serverless.

You can connect databases (SQL, Postgres), REST APIs, other GraphQL APIs, and third-party or SaaS APIs.

You can find more information on graphql.stepzen.com.

Roy Derks
Roy Derks
8 min
09 Dec, 2021

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Building a scalable GraphQL server can be challenging. There are multiple reasons to build a GraphQL server, such as optimizing client requests and wrapping microservices. The SDL first GraphQL server allows you to write your schema separately from your resolvers, giving you full control. You can create a GraphQL API automatically from a schema, simplifying the process and eliminating the need for manual deployments. The schema can link data sources and third-party APIs, allowing for easy integration and customization.

1. Introduction to GraphQL Server

Short description:

Building a scalable GraphQL server can be challenging. There are multiple reasons to build a GraphQL server, such as optimizing client requests and wrapping microservices. There are different ways and patterns to create a GraphQL server, with the code-first approach being one of them.

Hey, everyone. My name is Roy and welcome to my talk, when not to create a GraphQL server. So who's this for? So it's very easy to build a GraphQL server, but it's really hard to make a GraphQL server that's scalable. So scalability will sometime kick you in the ass whenever you start writing a GraphQL server. So there are many libraries to build a GraphQL API and there are many different patterns to build a GraphQL API and we'll be exploring them all in this talk. We'll also be showing a way to create a GraphQL server automatically based on your existing back ends.

Little bit about myself. So my name is Roy. I'm a software engineer and public speaker. You can find me on Twitter with the handle, AdGetHackTeam and I wrote a lot of books about react and also GraphQL, the latest one is full stack GraphQL.

So before diving into how to build a GraphQL server, also let's have a look at why you want to build a GraphQL server in the beginning. So there are many reasons to build a GraphQL server and I think the very first one is through optimizing client request. So you have a client, it's consuming an API, but somehow your REST API or maybe different sort of API calls aren't that efficient. You want to have that efficiency and you also want to give some autonomy to the user. So GraphQL isn't only there to solve the M plus one problem where you might be over and under fetching too many GraphQL, too many REST end points, but instead GraphQL also gives autonomy to the user. So as a client, you've more control about the types, about the data that's flowing into your application. Optimizing client request isn't the only way or the only reason to create a GraphQL server. It could also be to wrap your microservices, so GraphQL is perfectly fine to bring together multiple microservices that can be GraphQL microservices, but also microservices built with something else. And it's also very good in wrapping legacy services with that GraphQL data lane. So there are multiple reasons to build a GraphQL server and these are two perfectly fine reasons to build one.

There are multiple ways to create a GraphQL server. So as I mentioned in the beginning, there is no correct way. There are many different ways and many different patterns and libraries to help you with it. So the first pattern we have here is a code first GraphQL server. So with a code first GraphQL server, you always start by writing resolvers. And these resolvers, they usually use classes or if you're using TypeScript, they probably use a TypeScript type system in order to define the results returns of these resolvers. And based on that results, a code first GraphQL server will generate a schema based on the resolvers. And then, of course, create a server for you. And it is one major downside there's an upside, you can do everything programmatically. But the downside, it's very hard to have separation of concern.

2. Creating a GraphQL API from a Schema

Short description:

The SDL first GraphQL server allows you to write your schema separately from your resolvers, giving you full control. However, this approach requires writing both resolvers and schemas, which can be time-consuming. Alternatively, you can create a GraphQL API automatically from a schema using step 10. This simplifies the process by generating resolvers in the cloud and connecting to various data sources, such as databases, REST APIs, or other GraphQL APIs. The resulting serverless GraphQL API handles scalability and performance, eliminating the need for manual deployments.

So literally, there's no separation of concern, because your schema gets created from a resolvers, and resolvers is the only code you're out. So you don't have any control about how the schema actually will look like in the end. So there was a solution for this, which is SDL first GraphQL server, also known as schema first GraphQL server.

So the idea here is that you write your schema, you can either do it in GraphQL SDL, hence the SDL first server, or you can do it with some external libraries. So there is the GraphQL JS library, which lets you write schema first GraphQL servers, but not using SDL, but using their own methods instead. But the idea is simple, you create your schema, you create your resolvers based on this schema, and this will create a server for you. So you have a very nice separation of concern, you have your schemas separated from a resolvers, and you are in full control of everything. But this, of course, has the major downsides and writing both resolvers and schemas is a lot of work.

So luckily, there's a solution. You can also create your GraphQL API automatically from a schema. And this you can be done with step 10, an example. So let's have a look about how this works. So creating a graph API with step 10 is very straightforward. You just write your schema. You can define all the types that you have. And these types will be linked to a data source they're coming from. And this can be any back end as we'll see later on. And our CLI will then generate resolvers in the server automatically for you, right in the cloud. So it will be deployed serverless, you don't have to worry about any deployments or about scalability of your resolvers. So steps and you can connect any data source.

So it can be databases, either SQL or Postgres. It can be REST APIs, it can be GraphQL APIs, you can literally connect any other data source. And then based on this data source, a fully performance serverless GraphQL API will be created for you. So no longer do we have to worry about scalability, about performance, about deployments, it will all be done for you. And this uses just GraphQL schema design language. And here are two examples for MySQL Postgres on the left and REST on the right. As you can see, it's using custom directives in order to link to data source. So right from in your schema using just GraphQL schema design language, you can create connections with any back end or any data source. And next to Postgres than REST, you can also use any other GraphQL API as your data source, as we'll see in this example. So what we have here is a schema.