[breaking] Consider dropping built-in integration with Express v4 and replacing it with Express v5 (or having no built-in integrations other than startStandaloneServer)

[joergbaier]

@apollo/server has express v4 as a dependency. After several years, express is moving forward with releasing v5 (currently published as next tag). Having support for v5 here would unblock and encourage people to upgrade.

https://www.npmjs.com/package/express?activeTab=versions
https://github.com/expressjs/express/releases/tag/v5.0.0

At this time, I have not checked for breaking changes in this repo, but wanted to open this issue to get things rolling. Any changes could be published under the next tag as well.

[joergbaier]

Typing updates for @types/express & @types/express-serve-static-core
DefinitelyTyped/DefinitelyTyped#70563

[RobinTail]

Breaking changes are listed in the migration guide, which is not yet up to date. Besides the listed changes there is also Node.js min supported version: 18.
The primary feature is proper handling of asynchronous handlers.

[glasser]

I think it would be a good start if community members wanted to publish Express 5 integrations separately (perhaps under the @as-integrations npm org / apollo-server-integrations GitHub org)! While we could add a @apollo/server/express5 directory directly to Apollo Server, it might be challenging to do so in a way that uses different dependencies for two different parts of the same npm module, so getting this in core might be more likely a thing for the next major version of AS, which is not currently scheduled.

[RobinTail]

I made types. Enjoy :)

[P4sca1]

I am using express5 beta with apollo server 4 for the past year without any problems.
After upgrading @types/express and @types/express-serve-static-core to v5, I needed to override the version in apollo server to avoid type mismatches. e.g. for pnpm:

{
        "pnpm": {
                "overrides": {
                        "@types/express": "5.0.0",
                        "@types/express-serve-static-core": "5.0.0"
                }
        }
}

[AndKiel]

I tried upgrading to express v5 and it looks like apollo-server is incompatible. This check:

apollo-server/packages/server/src/express4/index.ts

Line 47 in 597f6e1

if (!req.body) {

is invalid because of the following breaking change:

The req.body property returns undefined when the body has not been parsed. In Express 4, it returns {} by default.

EDIT: I mainly wrote this comment because the one above said that the upgrade to beta worked without any problems.

[glasser]

I don't think it should be a big surprise that the code in the express4 directory does not work with Express 5.

The main interface for Apollo Server is the generic interface that works with any web server if you write a short adapter. Apollo Server does ship with one "first party" binding for the most popular and stable web framework, Express v4. But it's an explicit goal of the AS4 rewrite that it is not the job of Apollo Server itself to provide bindings to every web framework out there. That's how things worked in AS3 — the core project needed to have direct integrations to all supported web frameworks and there was no extensibility. In AS4 we provide a built-in integration with the most popular framework (Express v4) and community packages can provide integrations (typically about a page of code) with other frameworks.

It is likely that at some point in the future, Express v5 may be the most popular and stable web framework, but for today, that's still Express v4. So as mentioned above in #7928 (comment) I'd encourage folks on the cutting edge to put together a community package for @as-integrations/express5.

Perhaps Apollo Server v5 would incorporate that as its default and shift Express v4 to "community/external". But for now I would assume the place to start is with an integration.

[cupofjoakim]

Apollo Server does ship with one "first party" binding for the most popular and stable web framework, Express v4.
...
It is likely that at some point in the future, Express v5 may be the most popular and stable web framework, but for today, that's still Express v4.

@glasser Is this the perspective of apollo for node versions too? To only support them once it's the most popular version? Express 4 and 5 are not different frameworks, they are just different versions.

Does this mean you're closed for contributions of an express 5 adapter too?

[glasser]

A library that runs on 0 versions of the runtime is not useful. So we will continue to track versions of the runtime that we support. (Of course, we have other issues like "we are overdue to bumping our major version number and dropping old Node version support" too...)

A library that has zero built-directly-into-the-core-package implementations of the interface it exports is still useful. Express 4 is an outlier here in that it is very slightly easier to use than all of the other frameworks.

The versions of Express have different API, so building against them require linking in multiple versions of the same library or its DefinitelyTyped libraries. This makes the build more complex and hard to evaluate.

We went through all of this previously with Fastify v2 to v3. It's a lot easier to ship entirely separate adapter packages for different incompatible versions of a framework than to try to make one package that magically works with multiple versions.

The users of Fastify, Hapi, Koa, Next.js, and h3 are fine installing an integration package. It will work fine for Express v5 too. And now that we know that Express is a moving target rather than something that hasn't made an incompatible change in a decade, it probably makes sense to put it in on equal footing with all the other web frameworks and make the next major version of @apollo/server a low-dependency pure implementation of its interface instead of anointing a single version of a single framework as special.

[trevor-scheer]

@cupofjoakim (or anyone else interested), I'd be happy to add an express repo to the integrations org if someone is looking to implement and maintain the integration.