I followed "Subscriptions in Apollo Server" and "API Reference: expressMiddleware" but my app won't show graphql IDE

[kasir-barati]

Hi I followed the steps written in the doc and IDK why but for some reason I keep getting this unbelievably short and confusing error message in the browser:

req.body is not set; this probably means you forgot to set up the json middleware before the Apollo Server middleware.

Any idea?

Here is my code: https://github.com/kasir-barati/graphql/blob/main/apps/server-statistics/src/main.ts

BTW I am using ExpressJS v5 + Nx and I do not believe that they are the culprit.

Docs I am following:

• https://www.apollographql.com/docs/apollo-server/data/subscriptions#enabling-subscriptions
• https://www.apollographql.com/docs/apollo-server/api/express-middleware
• https://www.apollographql.com/docs/apollo-server/security/cors#specifying-origins

[kasir-barati]

BTW in the link I shared to my repo you can see that I have done it exactly as the doc says and yet it is not working: https://github.com/kasir-barati/graphql/blob/323ad5f75353b7dc148402f97dc7d2430923b7ce/apps/server-statistics/src/main.ts#L55

[kasir-barati]

Wow man, The problem was really express v5.

[glasser]

Makes sense: after all, the line you wrote said:

import { expressMiddleware } from '@apollo/server/express4';

which indicates the one web framework that Apollo Server has built-in support for is Express v4. Apollo Server 4's main design goal is that we provide first-party support for at most one web framework (today, Express v4), which is a change from the unmaintainable AS v2/v3 approach where we provided first-party support for many web frameworks. We encourage the community to publish an Express v5 integration package (it's likely about a page of code, probably very similar to the built-in Express v4 integration). A future major version of AS may switch which web framework we have first-party support for, though certainly we'd want to see Express v5 have more than 1% of the downloads of Express v4 before we consider that as our choice.

[wesleytodd]

Hey @glasser, I was linked here by @kasir-barati in an issue on our side. I am a bit surprised at this answer though, so wanted to make sure I understand it.

we'd want to see Express v5 have more than 1% of the downloads of Express v4 before we consider that as our choice.

This implies to me that you would drop support for express@^4 at some point? Does this mean each of your AS majors will only support one major of express?

In this case, the error is for sure because of one of our breaking changes which makes this line no longer correct (as called out further on in the comment):

https://github.com/apollographql/apollo-server/blob/main/packages/server/src/express4/index.ts#L48

I am wondering why you would not just refactor this to easily support both majors? Your coupling to express is rather minimal, and we would happily work to make sure that you have the things you need to smooth the integration. I just want to make sure this is not being made more complicated at the cost of folks not upgrading to v5 because apollo does not yet support it when it easily could.

[glasser]

Apollo Server v4 is a GraphQL server that exposes an abstract API that lets you write a few dozen lines of code to integrate it with any JS web framework. The intention is for each such integration to be written and maintained by dedicated users of that particular web framework.

This is a shift from older versions of AS, which had no abstract API and instead had built-in integrations with many web frameworks. Maintaining this software required AS developers to be intimately familiar with many different web frameworks and it was very hard to shift it to new major versions of those frameworks.

Supporting a broad set of community-maintained integrations is the main approach we take these days.

For convenience, we happen to ship a first-party-maintained integration with today's most popular web framework (which is Express v4) directly inside the core @apollo/server package. But that's really just a convenience! It's possible that we might even drop that from a future major version and only have the abstract API (and the "standalone server" which is only implemented in terms of the core Node HTTP server's TypeScript types, though it does happen to use Express internally for convenience).

We are absolutely not going to try to complicate our build and test system by requiring us to build and test the core package against multiple versions of dependencies, their TypeScript definitions, etc. We look forward to community members maintaining an Express v5 integration just like our Next.js and Koa and Hapi etc integrations (https://www.apollographql.com/docs/apollo-server/integrations/integration-index).

Again, these integrations are very short. They mostly just consist of converting how requests and responses are represented. The complexity of supporting "we have to make sure that this code typechecks against two distinct versions of Express" is actually more than the complexity of maintaining Express v4 and v5 integrations as separate npm modules.

[wesleytodd]

Thanks for the context, FWIW I am quite familiar with the setup here as I helped build out our integration at Netflix for AS, help maintain our restify bindings, and have been present in the work as Jenn (your former colleague) worked to migrate from v3 to v4.

My point here was not about understanding how AS works or it's intent, my point was that your code could easily be made to support both express 4 and 5 with a small change. I am sorry to hear you are not interested in that work, but I understand and agree that if you are not intending to maintain those bindings that it would be better for the community to. I doubt Express will be directly picking that up (I am but one TC member though, so maybe someone else would be interested in that), but you might consider just the one small patch to enable users to use your currently bundled binding to express in both our supported major lines.