Next.js + Apollo Server SSR

[notsaved]

Hello everyone,

I have a question regarding Apollo Server integration with Next.js. I have a Next.js application with Apollo server running in the server part (same server).

Next.js way of handling SSR is to request the data in getServerSideProps/getStaticProps and pass the result to the client. Being on the server it’s encouraged that you avoid making unnecessary HTTP requests and instead directly call the functionality that’s available on the server (directly query the database or what have you).

My problem is that I wish to use the graphql pipeline but skip making the HTTP request and directly query the “system”. I have noticed that apollo server exposes executeOperation which does exactly what I need but the docs recommend using it for integration testing and doesn’t mention using it in any other way.

My solution would look something like this:

export const getStaticProps: GetStaticProps = async (context) => {
    const data = await apolloServer.executeOperation(QUERY HERE, context)
    return {
	props: data
    }
}

This code snippet is simplified to showcase the main idea.

Finally my question is: Could this work? Is there any downside to my method? Does anyone have a solution for this problem? Should I just give up and make an HTTP request even if it’s server to server on the same address?

[JeffAuriemma]

Hi @notsaved welcome to the forum! I found a couple posts that might help set some context for executeOperation:

`runHttpQuery` alternative for non HTTP Frameworks? (ApolloServer RSocket Integration)

Hi! We’re actually reworking the whole API right now as part of Apollo Server 4, which you can follow along on the version-4 branch or the milestone or the roadmap. As part of this we’re getting rid of the old standalone functions like runHttpQuery which date back to Apollo Server 1 when there wasn’t even an ApolloServer object at all. ApolloServer should end up with two main entry points: one which is “execute this HTTP request” and one which is “execute this parsed operation”. The latter wi…

Can apolloServer.executeOperation be used in production?

Thank you for your awesome product! We are really enjoying it a lot! We have a particular production use case that forces us to run some logic after Apollo returns a response, but before the response is sent to the client. My question is can executeOperation be used reliably in production to achieve the is, although it shows only as a testing tool in your docs? Are there limitations? caveats, pitfalls I need to be aware of? Thanks in advance!

Sveltekit + Apollo: Recommended approach for integration

Hi @eric-naguras. We are successfully using the executeOperation approach, which works great. Currently, we have our project running on Heroku. The plan is to move some of it to Cloudflare, and we even did a POC. But please notice that the Cloudflare workers runtime is not a true Node.js environment, and thus many packages will not be able to run there. The error messages are also not always super helpful when building - but now you are warned Would love to do some knowledge s…

Based on these threads I don’t think there are any red flags that should stop you from using executeOperation in production. Maybe @glasser or @trevor.scheer might have some additional thoughts?

[notsaved]

Thanks a lot for the reply, I tried to search before asking but not very well apparently. That was exactly what I was looking for! Cheers

[trevor.scheer]

At a quick glance, I think my recommendation would be to use the executeHTTPGraphQLRequest method and just fudge the HTTP bits that it expects in the parameters (you’ll need to correctly specify some headers to bypass csrf prevention, for example). I think this gives you the best of both worlds - not sending an actual HTTP request while calling into Apollo Server in a more comprehensive manner.

Some code paths that you’d be skipping by calling into executeOperation directly include:

• some of the early plugin lifecycle methods won’t be called
• batched queries
• incremental delivery / @defer implementation

If you know none of those things are interesting to you then executeOperation is probably fine