Next.js Discord

Discord Forum

How to address server-side API w/o specifying absolute URL?

Unanswered
Golden northern bumble bee posted this in #help-forum
Open in Discord
Golden northern bumble beeOP
Currently I have this:
export const getServerSideProps: GetServerSideProps = async () => {
  const res = await fetch("http://localhost:3000/api/hello");
  const data: Data = await res.json();

  return {
    props: {
      data,
    },
  };
};

but I can't use http://localhost:300 because it depends on where the app is deployed. How to write it correctly?

35 Replies

James4u
@Golden northern bumble bee That's not the correct usage.
Api route is for data fetching or data mutation from client side.
You should perform actions you do inside /api/hello in getServerSideProps() function.
James4u
can you tell me what you exactly do inside your api /api/hello?
Golden northern bumble beeOP
I'm gonna return some variables from .env
James4u
what??? return .env variables? and then you are gonna pass them to the client?
Golden northern bumble beeOP
yep. Like URLs to services that I use on the client-side.
Currently they're stored in our .env file and they have NEXT_PUBLIC_ prefixes to be accessible from client. But the problem with this approach is that we cannot have a single image for dev/staging and prod. Whenever we deploy we also have to rebuild only because of different .env variables.
So I came up with another idea: store variables w/o NEXT_PUBLIC prefix and fetch them via API
Asian black bear
https://nextjs-faq.com/fetch-api-in-getserversideprops
Golden northern bumble beeOP
This was I can switch .env while I deploy
James4u
It doesn't sound like a good approach
what's the URLs like that you need from client end?
But the problem with this approach is that we cannot have a single image for dev/staging and prod.
didn't understand fully about this
you don't want different apps for dev/staging and prod?
you only want single app for those three environemnts?
Golden northern bumble beeOP
Different instances - prod/dev/stage - use different backend services
Asian black bear
Sounds like you want this: https://github.com/expatfile/next-runtime-env
It makes environment variables more dynamic and doesn't bake them into the artifact
Making it possible to use the same artifact with different variables
James4u
yeah, exactly having an api to return .env variable doesn't makes sense?
@James4u you only want single app for those three environemnts?
Golden northern bumble beeOP
I want a single docker image that we deploy here and there. And I want to switch env vars in place, while deploy, not while building.
@James4u yeah, exactly having an api to return `.env` variable doesn't makes sense?
Asian black bear
It does in fringe and corporate use cases
@Asian black bear Sounds like you want this: https://github.com/expatfile/next-runtime-env
Golden northern bumble beeOP
Thanks, I'll have a look!
@Asian black bear It does in fringe and corporate use cases
James4u
does it? can you please explain a bit more? @Asian black bear
Golden northern bumble beeOP
Consider an app which requests a external (relative to NextJS itself) service.
While you develop it, you want a dev version of the service.
When you test it, you want a test version of the service.
And finally on production you're gonna use the production version of the service with production database.
Correspondingly, there will be 3 different backend URLs.
James4u
okay makes sense
Golden northern bumble beeOP
and 3 different front-end urls
James4u
so if you want to expose .env variables you can directly expose them in getServerSideProps
no need to hit your own api route
Golden northern bumble beeOP
Oh, wait.… Really? 🙂
I can access proces.env!
James4u
ofc~
Golden northern bumble beeOP
right from getServerSidePros
haha, how I missed it...
@James4u does it? can you please explain a bit more? <@141252432054190080>
Asian black bear
There are legitimate use cases where you want to build an artifact of your app without baked in URLs and deploy it using k8s. In those scenarios you have no guarantee what the URLs for the other services are. You could either use service discovery and perform some actual API requests to get the URLs or just use "dynamic" environment variables.