How to think about SSG when API changes are part of the same PR

[brianlovin]

I'm currently rebuilding the api for my personal site. In doing so, I did the following (generally):

• created a new pages/api/graphql.ts route
• created a new pages/index.tsx page
• in the view, use getStaticProps to fetch from /api/graphql

I'm confused about how to think about the right way to deploy this. It seems that the getStaticProps would need to read data from an API route that doesn't exist yet, or is being simultaneously built. This caused me a lot of frustration as I basically had to comment out a ton of code, deploy the API Routes, then rebuild my client side data fetching.

Any suggestions on this would be great!

[timneutkens]

Check this answer:

#11210 (comment)

Basically don't do a literal fetch(), as you can access the underlying JS directly

[brianlovin]

But then after the initial deployment, this would be a bad thing to have in the code right? I'd be shipping the API to the client, if I'm understanding correctly.

[timneutkens]

Next.js tree shakes getStaticProps and getServerSideProps from the browser bundle

[brianlovin]

Oooooh, right right. Roger that, I'll refactor to call the functions directly instead of pinging the API.

[brianlovin]

@timneutkens the answer above was satisfactory for quite some time, but I'm bumping into some confusing behaviors when running a single GraphQL endpoint and doing new deployments.

Suppose I am writing a new query with a new resolver. When I deploy this, I have to supply a url endpoint for all GraphQL queries. Right now I just point it to my prod endpoint (/api/graphql). However, because prod doesn't have the code for the new resolver, the newly-written query will fail and SSG will fail as well.

It seems like I want something like:

• deploy only API pages
• alias API to production
• deploy new site with SSG + new queries

Does this issue make sense to you, or am I still missing something?

[Mistereo]

@brianlovin if your GraphQL server is based on graphql-js (eg: Apollo), you may be able to use it directly without the need for HTTP request.
Basically:

import { graphql } from 'graphql';
import schema from '../schema'; // GraphQLSchema, you can build using makeExecutableSchema for example

// In getStaticProps/getServerSideProps
let body = await graphql({
  schema,
  source: 'query { ... }',
  contextValue: ...,
  variableValues: ...,
});

This can be part of your server-side network layer implementation for Relay/Apollo/etc.

[brianlovin]

Oh nice, I'll give this a try soon. Some of my resolvers still use external http requests, but that might all resolve appropriately. Thanks for the tip.

[brianlovin]

This ended up taking a while longer to solve, but ultimate was able to by carefully reviewing https://github.com/zeit/next.js/blob/canary/examples/api-routes-apollo-server-and-client/apollo/client.js – that example is a bit outdated, and could use some love to account for the deprecation of getInitialProps, but I'm not sure I really understand it enough to make that change.

For future readers, the PR change to get this working is here: brianlovin/briOS@e553fa9