I would like to get the domain name that vercel uses to set one of my env variable that is used during my fetch call this is my current domain name variable I donèt know why it is not resolving correctly any idea why?
#how to get the domain name that vercel uses when deploying for setting up an env variable
severe harbor
empty canyonBOT
rugged cloak
I think it can help you they had the same problem as you : https://github.com/vercel/next.js/discussions/16429#discussioncomment-1302156
From what he said you should have the url like thisjs NEXT_PUBLIC_URL=https://$NEXT_PUBLIC_VERCEL_URL
onyx prawn
If you think you "need the domain" for fetching you're own API you're doing something wrong, because you do not. fetch('/api/foo') will automatically use the domain as the base URL wherever you deploy.
severe harbor
If you think you "need the domain" for fetching you're own API you're doing some...
in some place of my code the fetch method is unable to create the correct url. it throws an invalid url error if the url is not complete :/
onyx prawn
Then you are doing something wrong. Are you attempting to fetch your own server from within server-side code? If so, you shouldn't do that either.
onyx prawn
It makes no sense to order via the drive-through while you're already sitting inside of McDonald's.
severe harbor
i don't like server action
onyx prawn
Just call the functions, that you endpoint would use, directly instead of fetching your own endpoint from server-side code.
severe harbor
or calling directly the function
onyx prawn
But it's wrong and not idiomatic. Additionally, you're introducing another unnecessary roundtrip. Please read this, and in particular the final sections: https://nextjs-faq.com/fetch-api-in-rsc
severe harbor
interesting, who is the author of this blog
onyx prawn
It's a collaborative effort of a few experienced community members.
severe harbor
really cool ill pin it thank you. Using api routes made my code more organized everything in one place, this is what I liked from it. Ill try this approach inshAllah.
also what i liked with fetch is the caching control i had with it
onyx prawn
Public API routes are only for two use-cases: purely client-side fetching and 3rd parties accessing your public API. Everything else can be done directly using server components (which is the the whole point of them) and server actions for mutations.
severe harbor
since now i don't use fetch, i will have to use the unstable_cache if i am correct
onyx prawn
Yeah, it's more granular in case you require caching and will be replaced with something even more convenient in the future.
onyx prawn
Yes, it has probably been one of the most stable things of the app router. You just need to read thoroughly how it's used because there are some minor details that are easy to mistake.