GraphQL - The Stack -
This blog is a part of a series on GraphQL where we will dive deep into GraphQL and its ecosystem one piece at a time
- Part 1: Diving Deep
- Part 2: The Usecase & Architecture
- Part 3: The Stack #1
- Part 4: The Stack #2
- Part 5: The Stack #3
- Part 6: The Workflow
In this series, we had looked at some interesting parts of the GraphQL stack so far with a range of tools, libraries and frameworks from the community. Let us continue the journey in this blog looking at more such tools and services which have created a great impact in the GraphQL ecosystem.
The evolution of GraphQL clients have been really amazing, and I would say, this is one of the great things about GraphQL given its powerful introspection capabilities, being self documenting and also providing ability to extend everything with extensions.
It all started with GraphiQL demonstrating all these back in the day, but then came Playground (which had recently merged with the GraphiQL team (opens in a new tab) to make things even more interesting), Altair (opens in a new tab) and even desktop/web/editor based clients like Insomnia (opens in a new tab), Postman (opens in a new tab), Hoppscotch (opens in a new tab), VSCode Rest Client (opens in a new tab) and the list goes on all proving that the developer experience with GraphQL can be made really better with just some sugar on top.
But, some reasons why thinking about the future of GraphiQL feels really great is cause of the upcoming support for Monaco mode (opens in a new tab) , support for plugins (opens in a new tab) and a lot of amazing features from Playground to now become as part of GraphiQL as part of the transition according to the blog linked above.
Also, embedding a GraphiQL editor is as simple as importing the HTML and related assets as specified in their README (opens in a new tab).
And while the user experience is made as simple as possible, there are a huge number of components which make it all happen behind the scenes as mentioned in the README and you can have a look at all of them in the monorepo here (opens in a new tab) and here (opens in a new tab).
Codemirror (opens in a new tab) used to be
the interface which used to provide the editor support for GraphiQL, Playground, Insomnia and other
editors in the ecosystem in
1.x which is now being succeeded by the
language service (opens in a new tab)
which takes care of providing a web/desktop IDE experience if you are using editors like VSCode,
Language Parser (opens in a new tab)
which takes care of parsing the GraphQL SDL and operations you write and convert them to GraphQL AST
(If you are curious about how the AST looks, like, you can try going to
ASTExplorer (opens in a new tab) select GraphQL, enter your operation and have a look at the
AST which is what the final representation will look like) and so on becoming a platform for not
just GraphiQL but the entire editor ecosystem.
Starting with GraphQL or GraphiQL may actually have a learning curve for beginners since it takes a different approach to dealing with data. And even after people settle down with GraphQL, some people do feel like life was better for them when they were using something as simple as REST or GRPC.
This is where tools like GraphiQL Explorer play a major role where all their queries and mutations can be constructed automatically just by checking all the fields you need from the schema.
This workflow feels intuitive since it is as simple as checking all the fields you need in your client. You can read about how Onegraph solves this problem here (opens in a new tab)
It is just a React component which you include with your GraphiQL instance and the rest is history.
The next beautiful tool I would talk about here is the GraphQL Voyager. In fact, this is the first tool I used when I was new to GraphQL few years back, and it drove me nuts seeing the potential of what GraphQL can do.
The reason this is great is because, this leverages the complete power of introspection from GraphQL. You get to see all the entities and how they are related, search through the schema and also browse the docs
Source: GraphQL Voyager
And today, GraphQL Editor (opens in a new tab) takes this one step further allowing you to view, edit, browse all the entities and hierarchy making it really a great tool for anyone who wants to quickly work through the schema.
One important thing which GraphQL Spec did not discuss is a way to transmit files over the wire when using GraphQL. This is where GraphQL Upload comes in. While not an official spec from GraphQL foundation, Jayden had done a great job to put together a multipart spec (opens in a new tab) to address exactly this problem.
GraphQL Upload is the library which provides a great implementation of this spec with an ability to work with various frameworks. One thing to remember is that, while GraphQL Upload definitely does the job and works well over a significant scale, you might want to stick to HTTP for higher production workloads because of the reasons outlined in this blog (opens in a new tab).
And if you are using something like a GraphQL Gateway with either federation or stitching, you might want to make sure that you don't overload the gateway transmitting files creating probable bottlenecks which can affect the rest of your requests. So, try striking a balance since GraphQL need not be a solution for every problem.
Subscriptions are a powerful part of GraphQL allowing you to track all the operations happening with the data in near-real time but this mandates the use of a protocol like websockets or use something like Server Sent Events (SSE).
While subscription-transport-ws (opens in a new tab) from Apollo initially started off this journey, it is not actively maintained and GraphQL WS by Denis definitely is a great replacement to that having no external dependencies and having the ability to work across many frameworks.
But do remember that, websocket might loose its lead in the future especially with the introduction of HTTP/2 and HTTP/3 as mentioned here (opens in a new tab) while definitely here to stay. But this wouldn't affect GraphQL in any way since its transport independent.
Also note that subscriptions are not the only way to do real time communications in GraphQL. There are also things like Live Queries with great libraries like this (opens in a new tab) from Laurin which you can use
While Schema Stitching was initially advocated by Apollo with introduction of many helper functions in GraphQL Tools, their direction did change soon (opens in a new tab) after hearing a lot of feedback from their customers and took their call to introduce Apollo Federation. You can read their reasoning in this blog (opens in a new tab) but this does not mean that stitching has lost its relevance (opens in a new tab) especially with the introduction of Type Merging.
Apollo Federation does a great job especially when you use it with the rest of the ecosystem from Apollo like the Apollo Studio (opens in a new tab). Apollo Stack does offer a lot of features (opens in a new tab) which might be relevant to working with a data graph in an organization starting from providing a registry where you can upload parts of the combined schema from all services, version control the changes to your schema validating breaking changes, providing metrics regarding all the clients consuming the schema, tracing of all operations, multiple variants to manage multiple environments, alerting across multiple channels, and a CLI to work with all of these.
And this can definitely help teams who want to maintain their own part of the schema.
Federation comes with its
own specification and directives (opens in a new tab)
as part of it which helps people to define all of the relations between multiple GraphQL entities so
that the Apollo Gateway (opens in a new tab) can
combine them all together without having to modify the GraphQL gateway and also functions like
__resolveReference which helps in resolving an entity with its reference as specified by the
The Apollo CLI (opens in a new tab) when combined with Federation does come with a lot of helpers to take care of things like pushing the schema, listing the services in the studio, doing codegen and so on though I am not currently sure why they are rewriting it again to Rust (opens in a new tab) apart from the reasons as suggested here (opens in a new tab).
Let's quickly look at how Apollo Studio lets you manage the schema
This is how you maintain multiple Data graphs in your organization across environments
Browse through the schema, its types, documentation and so on
Track the changelog of your schema over time
Browse through the SDL of your schema
Execute GraphQL operations against your schema
and does offer a lot more especially when you are a paying customer.
NOTE: Federation with Apollo Server does not support subscriptions yet (opens in a new tab), and you might want to stick with stitching if you are looking for subscriptions support or switch to some other server like Mercurius since it does allow subscriptions over federation (opens in a new tab).
Gatsby is a static site generator powered by React, GraphQL and a lot of plugins contributed by the community which helps you sites simply by pooling in data from multiple different sources in multiple different ways, and it really popularized the idea of doing this all via GraphQL. If you want to know why and how Gatsby uses GraphQL, you can give this a read (opens in a new tab). And while Gatsby does offer both Server Side Rendering (opens in a new tab) and Static Site Generation (opens in a new tab), I would say it all boils down to your use case (opens in a new tab).
While Gatsby did popularize the idea of using GraphQL for static sites, there are a lot of other static site generators out there like Eleventy (opens in a new tab), Jekyll (opens in a new tab), Hugo (opens in a new tab), etc. and I find myself personally aligning towards Eleventy because of quite a few reasons which may not be right for this blog. But if you are curious, you can read blogs like this (opens in a new tab) and this (opens in a new tab) which gives a comparison.
Opentelemetry is the new standard for instrumentation (especially after Open Tracing and Open Census merging (opens in a new tab) together) and this makes things really amazing for people since there were quite a few overlap before in between them which can now be avoided to bring about a powerful tracing standard.
Opentelemetry is not specific to any language or implementation, and you can find all the amazing projects from Open Telemetry hosted here (opens in a new tab)
Now, the exciting thing is that there is now a reference implementation to the same using GraphQL which you can find here (opens in a new tab) and also an example to help you out with the same here (opens in a new tab)
This when used with Jaeger (opens in a new tab), Zipkin (opens in a new tab) or Tempo (opens in a new tab) can provide you with Traces for your GraphQL operations which you can track across your resolvers. Do note that it is not advisable to be turned on for everything since it has a performance overhead.
This can give you a context on how your data and context flow irrespective of your architecture in your resolvers and functions.
Faker.js (opens in a new tab) has been a great project to quickly generate mock or sample data providing various types of entities inbuilt. For eg. you can generate random addresses, images, URLs and so on, helping you to quickly test out your application without relying on the server or the backend to hold data.
This has become even more amazing with GraphQL Faker since it allows you to use all the great things
which Faker provides you with directives. Just define what data you want a specific field to
generate by specifying the relevant directives and GraphQL Faker can actually generate all the data
for you using
Source: GraphQL Faker
If you are using
@graphql-tools you can also use
faker.js directly and combine it with
Mocking (opens in a new tab) to get similar results, but without the need to
change your SDL.
While there are a lot of other tools we can discuss, the GraphQL ecosystem is huge and this pretty much has no end. But I do presume that these are all the tools you mainly need to start your GraphQL journey and leverage the ecosystem in the best way possible.
But with this the GraphQL journey is still not over. We will continue the next blog discussing a few more interesting things as part of the GraphQL series.
Is there anything you would like to see me address in this series? Do let me know, and we can probably do that in an another post.
If you have any questions or are looking for help, feel free to reach out to me @techahoy (opens in a new tab) anytime.
And if this helped, do share this across with your friends, do hang around and follow us for more like this every week. See you all soon.
Join our newsletter
Want to hear from us when there's something new? Sign up and stay up to date!Recent issues of our newsletter
GraphQLConf 2023 Recap
Explore the highlights of GraphQLConf 2023. Learn about the latest trends in GraphQL, from gateway solutions to composite schemas and innovative projects.
State of GraphQL Gateways in 2023
A six-month journey of researching, benchmarking, exploring and comparing GraphQL gateways and the Federation spec in 2023.
Hive Summer Update 2023
Learn what is new on GraphQL Hive, we have shipped a lot of new exciting features and improvements.
The complete GraphQL Scalar Guide
Knowing how native and custom GraphQL Scalar works enables building flexible and extendable GraphQL schema.