When (Not) To Create A GraphQL Server

Hello 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 sometimes 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 backends. A 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 at gethackteam and I wrote a lot of books, definitely 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 to optimize a 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 or under fetching too many graphql, too many REST endpoints, but instead graphql also gives autonomy to the user. So as a client, you have more control about the types, about the data that's flowing into your application. But optimizing client requests 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 three perfectly fine reasons to build one. But 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.

There are many reasons to build a graphql server and I think the very first one is to optimize a 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 or under fetching too many graphql, too many REST endpoints, but instead graphql also gives autonomy to the user. So as a client, you have more control about the types, about the data that's flowing into your application.

But optimizing client requests 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 three perfectly fine reasons to build one. But 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, you'll probably use a typescript type system in order to define the result returns of these resolvers. And based on that result, a code-first graphql server will generate its schema based on the resolvers. And then of course, create a server for you. And it has one major downside. It has an upside. You can do everything programmatically, but the downside, it's very hard to have a separation of concern. So there literally is no separation of concern because your schema gets created from the resolvers and resolvers is the only code to write. 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 schema separated from your resolvers, and you're in full control of everything. But this, of course, has the major downside that 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 can be done with StepZen, an example. So let's have a look about how this works. So creating a graphql api with StepZen 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 backend, as we'll see later on. And RCLI will then generate resolvers and 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 StepZen, 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 you 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 backend or any data source. And next to Postgres and 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. And in the schema, we'll be linking the data sources for you. As you can see, we can just run StepZen Start. It will automatically create a server for us. So it's deploying to StepZen, which will mean it will be deployed in the cloud, and then an endpoint becomes available. And then, of course, we can also add more types here like a language. And this language can be linked to the country. So a country can have a language.

For this, we'll be using another custom directive, and we'll link it to an existing query. So to get country language, we'll also be a REST api call that connects the information for a country. And then as soon as we start saving this, it will automatically be redeployed again. So you will always have the latest version of your schema on StepZen. You can also do this with third-party or SaaS APIs. So quite recently, we launched a new product called StepZen graphql Studio. So you can find it on graphql.stepzen.com. And this is an interactive IDE right in your browser where you can play with third-party APIs such as Dev.to, GitHub, or Twitter. You can link them all together either separately or by finding some combinations we made for you. And directly from the browser, you can create your own api by selecting some schemas, running some queries, and also deploy it on the cloud. So if you would scan this QR code or to go to graphql.stepzen.com, you can already find this right there for you. So that's mostly it. We had a short time to cover everything. My name was Roy. You can find me on Twitter using adcathackteam. You can find StepZen on stepzen.com. And you can also find our product, graphql Studio, on graphql.stepzen.com. Thank you, and I hope to see you around.