ApolloServer GraphQL Playground not necessarily turned off in production

[dthyresson]

While

redwood/packages/api/src/functions/graphql.ts

Line 90 in 895c2d0

export const createGraphQLHandler = ({

does turn off the playground if in dev mode, because it relies on process.env.NODE_ENV

process.env.NODE_ENV !== 'production'

and this may not be set in Netlify, the GraphQL playground could be exposed.

export const createGraphQLHandler = ({
  context,
  getCurrentUser,
  onException,
  cors,
  onHealthCheck,
  ...options
}: GraphQLHandlerOptions = {}) => {
  const isDevEnv = process.env.NODE_ENV !== 'production'
  const handler = new ApolloServer({
    // Turn off playground, introspection and debug in production.
    debug: isDevEnv,
    introspection: isDevEnv,
    playground: isDevEnv,

How to fix?

• make sure process.env.NODE_ENV is set? (edit: nope ...)
• be explicit and have GRAPHQL_PLAYGROUND_ENABLED env set only in dev and check that value for enabling the playground

Notes:

https://community.netlify.com/t/node-env-is-undefined-in-lambda-functions-no-matter-what-i-do/20667/2

Issue at hand is the Netlify Build vs Runtime environment. You will have to explicitly set NODE_ENV as a Netlify environment variable in their admin UI.

[dthyresson]

Turns out that

make sure process.env.NODE_ENV is set?

May not be an option.

Setting this caused my Netlify builds to fail.

9:32:54 AM: ❯ Context
9:32:54 AM:   production
9:32:54 AM: ​
9:32:54 AM: ────────────────────────────────────────────────────────────────
9:32:54 AM:   1. build.command from netlify.toml                            
9:32:54 AM: ────────────────────────────────────────────────────────────────
9:32:54 AM: ​
9:32:54 AM: $ yarn rw build && yarn rw db up --no-db-client --auto-approve
9:32:54 AM: yarn run v1.22.4
9:32:54 AM: error Command "rw" not found.

[Tobbe]

How about we change to const isDevEnv = process.env.NODE_ENV === 'development'?

[peterp]

@Tobbe Super reasonable solution, ship it!

@dthyresson I do believe that Netlify's runtime boots up Lambda functions as production. We could add a Redwood schema and service that shares this information.

[dthyresson]

@peterp > I do believe that Netlify's runtime boots up Lambda functions as production.

If it does, then it isn't there:

I asked in the Netlify community some time ago:

https://community.netlify.com/t/are-envs-set-in-build-plugins-available-during-function-runtime/18842

And they responded:

At the moment, the only environment variables available in Netlify Functions at runtime are the ones specified in the Netlify app UI. Environment variables set in netlify.toml or set inside a Build plugin with process.env.name = value are not available there unfortunately.

So, I take that to mean that NODE_ENV is undefined when running a lambda function -- and that is what we (and others) see.

We could add a Redwood schema and service that shares this information.

Sorry, I don't understand what you mean by: "Redwood schema and service that shares this information"

[dthyresson]

Oh, I was chatting with Tobbe and was looking at a different issue and just now realized this was the graphql issue -- so ..

"Redwood schema and service that shares this information"

Assume mean in https://github.com/redwoodjs/redwood/blob/main/packages/api/src/makeMergedSchema/rootSchema.ts:

 Query: {
    redwood: () => ({
      version: apiPackageJson.version as string,
      prismaVersion: () => prismaVersion.client,
      currentUser: (_args: any, context: GlobalContext) => {
        return context?.currentUser
      },
    }),

to add the current deployed environment here?

[Tobbe]

How about we change to const isDevEnv = process.env.NODE_ENV === 'development'?

Actually this wouldn't work yet, because NODE_ENV is undefined on localhost too. But I've fixed that in #1653 So when that lands I can PR this fix too