Best Pattern for Surfacing ENV Variables to Client Components in Next 14
Answered
bigviking posted this in #help-forum
I'm using Next14 with Apollo/GraphQL. I want to use react hooks like useSuspenseQuery in some client components and have set up the ApolloWrapper following this guide here: https://github.com/apollographql/apollo-client-nextjs
Railway is the platform I chose to host the application. Railway provides a dynamic PORT at build time to the server, as well as a private URL to network with the NextJs server environment.
I want to surface those variables to the ApolloWrapper however those variables are in a separate environment to the client, and unavailable to the wrapper in production.
Some notes:
- I've used Server Actions to wrap GraphQL queries that use getClient.query() and and imported them into client components, thats not the solution I'm after.
- I don't want to hard-code and expose the env variables in next.config.mjs to have them picked up by client components.
I'd like to use the dynamic PORT that Railway creates at build time and combine that with the Railway private domain env variable RAILWAY_PRIVATE_DOMAIN that Railway also provides and send that to ApolloWrapper.
http://${process.env.RAILWAY_PRIVATE_DOMAIN}:${process.env.PORT}/api/graphql
Is there a best practise to save and retreive from the database? Is there an easy way to configure this in Next to expose these to client components?
Thanks!
Railway is the platform I chose to host the application. Railway provides a dynamic PORT at build time to the server, as well as a private URL to network with the NextJs server environment.
I want to surface those variables to the ApolloWrapper however those variables are in a separate environment to the client, and unavailable to the wrapper in production.
Some notes:
- I've used Server Actions to wrap GraphQL queries that use getClient.query() and and imported them into client components, thats not the solution I'm after.
- I don't want to hard-code and expose the env variables in next.config.mjs to have them picked up by client components.
I'd like to use the dynamic PORT that Railway creates at build time and combine that with the Railway private domain env variable RAILWAY_PRIVATE_DOMAIN that Railway also provides and send that to ApolloWrapper.
http://${process.env.RAILWAY_PRIVATE_DOMAIN}:${process.env.PORT}/api/graphql
Is there a best practise to save and retreive from the database? Is there an easy way to configure this in Next to expose these to client components?
Thanks!
Answered by Giant Angora
Without some encryption scheme they will be visible for anyone visiting the site.
Why not just create one general purpose server action that takes in any query parameters from the client, performs the query to the private endpoint and returns the result?
Why not just create one general purpose server action that takes in any query parameters from the client, performs the query to the private endpoint and returns the result?
9 Replies
Giant Angora
If you do not want to expose the env variables they should not be passed into client components?
Giant Angora
Without some encryption scheme they will be visible for anyone visiting the site.
Why not just create one general purpose server action that takes in any query parameters from the client, performs the query to the private endpoint and returns the result?
Why not just create one general purpose server action that takes in any query parameters from the client, performs the query to the private endpoint and returns the result?
Answer
Giant Angora
Alternatively you could just create a forwarding route handler to call from the client.
@Giant Angora Without some encryption scheme they will be visible for anyone visiting the site.
Why not just create one general purpose server action that takes in any query parameters from the client, performs the query to the private endpoint and returns the result?
Because I want to use hooks like useSuspenseQuery.
@bigviking Because I want to use hooks like useSuspenseQuery.
create a custom domain in your project?
I think I’ve got it sorted a little better. I’m going to try and stick with a pattern where I wrap the queries in server actions. Can still use Suspense and loading.ts to handle the loading state changes.
That way im no longer messing around with exposing stuff to client components
I could tell it’s a bad pattern as I was trying to finagle it
Closest solution was your recommendation. Thank you