Apollo Server 4 is a lightweight, open-source, spec-compliant GraphQL server that’s compatible with any GraphQL client. It’s a great choice for building a production-ready, self-documenting GraphQL API that can use data from any source. You can use Apollo Server 4 as a subgraph in a federated Supergraph or as a stand-alone GraphQL server.
Apollo Server 4 introduces the
@apollo/server package which decouples plugins and frameworks from the core of Apollo Server. It offers a stable API for HTTP and serverless frameworks, enabling users to build Apollo Server integrations for their framework of choice. Apollo Server 4 also introduces a TypeScript-first development and documentation experience to help you build typesafe servers using a schema-first development process.
A dedicated API for HTTP and Serverless framework integrations
In previous versions of Apollo Server, there wasn’t a well-defined API layer between the “core” of Apollo Server and the individual framework integrations. Many features of Apollo Server were implemented as logic which had to be repeated in each integration, but often in slightly different, framework-specific ways. Improving any of these features often meant changing framework-specific code in 9 different packages.
For Apollo Server 4, we defined simple portable data structures for HTTP requests and responses, and we rewrote Apollo Server to act on these representations. Apollo Server now has a stable API for building framework integrations, which now usually consist of a dozen or so lines of code that convert between the request and response objects of the framework and Apollo Server. AS4 also has native support for serverless framework lifecycles, and serverless integrations now use a dedicated API during the server startup sequence to execute operations.
Using and contributing to integrations
The Apollo Server 4 core project ships with a core-maintained integration for the most popular Node web framework (Express) as well as a simple standalone web server for when you don’t need to configure much.
We’ve set up infrastructure to help our community build and maintain integrations, such as with AWS Lambda, Fastify, and Koa. Community members have also already built integrations with new environments such as H3 and Next.JS that were never before supported by Apollo Server. Because building integrations require less domain-specific implementation, framework experts and integration authors can build integrations for their framework of choice and add those integrations to our Apollo Server integrations GitHub organization.
Additionally, because integrations are now maintained independently from Apollo Server, it will be much easier to update your framework to take advantage of new features in your web framework of choice. We are always looking to add new framework integrations, so if you don’t see an integration you’d like to use, create an issue on GitHub. If you specialize in any of these frameworks and are interested in building or maintaining an AS4 integration, please reach out!
Simpler package structure and reduced bundle size
Apollo Server 3 was structured as a large number of distinct packages for each framework integration. For example, Express users used the
apollo-server-express package while Fastify users used the
apollo-server-fastify package. Other functionality involved depending on one of a wide array of smaller packages, and it was challenging to ensure you used a consistent version across these packages. Apollo Server 4 simplifies this situation by combining all of the core code into a single new
Unlike Apollo Server 3, the Apollo Server 4 package is also published in both CJS and ESM formats! The ECMAScript Module format improves upon the CommonJS (CJS) format pioneered by Node. Modern build tools can better optimize packages built as ESM, resulting in reduced bundle size. Smaller, optimized bundles allow serverless runtimes like AWS Lambda to start up faster.
Because AS4 is published in both formats, you get the improved efficiency of ESM if you use a newer build tool without losing compatibility with older build environments that only support CJS.To learn more about the difference between ESM and CJS and their interoperability, check out the Node.js documentation.
Avoid resolver type and schema mismatches
With the release of Apollo Server 4, we’ve updated all of our documentation to show a TypeScript-first approach and recommend Typescript as the default way to build with Apollo Server.
When using Apollo Server 3, there was no way to specify the type of your context value when setting up your server. This led to typing inconsistencies because there was no compile-time check ensuring the type returned by your context function matched the value in your plugins and resolvers.
Apollo Server 4 enables you to write code that can statically check that your resolver types match their schema types, using a schema-first approach. To do this, Apollo Server documents the use of the
graphql-code-generator package with typescript-resolvers to ensure server implementations are type-safe. To get started or learn more about generating types from your schema, check out our documentation.
Getting started with Apollo Server 4
We’re excited for you to start using Apollo Server 4 and all of its new features!
If you’re starting from scratch, our getting started docs will walk you through setting up Apollo Server for the first time, or if you’re already using Apollo Server 3, our migration guide will help you upgrade. We would love your feedback on Apollo Server 4 and its framework integrations! You can do so by reaching out on our community forum or GitHub.
Stay in our orbit!
Become an Apollo insider and get first access to new features, best practices, and community events. Oh, and no junk mail. Ever.
Make this article better!
Was this post helpful? Have suggestions? Consider so we can improve it for future readers ✨.