To view this content, buy the book! 😃🙏
Or sign in if you’ve already purchased.
Background: HTTP, Server
There are also GraphQL libraries in these languages:
This chapter is split into six parts:
In Building, we build a GraphQL server from scratch, including authentication and authorization, query and mutation resolvers that talk to a database, error handling, and subscriptions. In Testing, we test it in different ways. In Production, we deploy our server and update it with things that are helpful to have in production, like error reporting, analytics, and security against attack. In More data sources, we connect our server to other databases and a REST API. In Extended topics, we learn about various new server-side topics and go into more depth on previous topics like the schema, subscriptions, and auth.
There are three main reasons why we might decide our server should be a GraphQL server:
For coders, #1 and #2 are often the most compelling, because it improves our quality of life 😄. For companies, #3 is often the most compelling, since they save time and money: they get a single, flexible API that covers all their business data, which means that instead of having to create new endpoints or entire APIs for new features or apps, they can just use their existing GraphQL API (and in some cases add fields and resolvers).
Actually, the first choice we have is whether to build it or generate it 😄. There are services that can save us a lot of time by generating a production-ready GraphQL backend for us. We’ll go over the pros/cons and how to set one up in the Hasura section, and another option is AWS AppSync.
If we do decide to build our own server, there are two situations we might be in:
There are two main architectures:
Microservices are in vogue and the word “monolith” is often used with a scornful tone, but in most cases, it’s better to have a monolith. Martin Fowler, one of the leaders in software design, wrote:
So my primary guideline would be don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services.
While there are a lot of huge tech companies that use microservices and are better off for it, they’re better off because they’re huge—not because microservices are a general good practice.
If we have an existing monolith, it often makes sense to add a GraphQL endpoint to that server instead of putting a GraphQL server in front of the monolith. For example, if we have an Express monolith that has a lot of thin REST routes that call model functions that contain the business logic and data fetching, then it would be easy to add a /graphql route with apollo-server-express and implement resolvers that call the same model functions as the REST routes. Or if all of our logic was in the routes themselves, and we didn't need to continue supporting the REST API, we could move the code we needed over to resolvers and Apollo data sources.
When we’re adding a GraphQL layer in front of an existing backend, whether it’s a microservices or monolith backend, we can make the choice between continuing to develop the existing backend or gradually moving logic to the GraphQL layer. If we’re doing microservices and want to keep that architecture, then it’s easy to keep implementing services (in whatever language(s) we implement services) and either extend the GraphQL schema and resolvers or use schema federation.
The server we’ll be creating in this chapter is a greenfield monolith, so it will talk directly to the database. However, most of the concepts will carry over to the microservice model. The largest difference will be either:
We’ll go over both of these options later in the chapter.