Pellentesque nec neque ex. Aliquam at quam vitae lacus convallis pulvinar. Mauris vitae ullamcorper lacus. Cras nisi dui, faucibus non dolor quis, volutpat euismod massa. Donec et pulvinar erat.
I don't really see the point of all this. You received a very common error with a simple to find cause and fixed it. Then you wrote a whole post about environment variables in which you overcomplicate the thing entirely.
Most developers that work with Next are expected to know some way to properly deal with environment variables with things like dotenv but let's assume they don't.
Why should a HTTP request to get a blog post know anything about the process environment?
Although poor choice of words, I know what you mean there and you are right. It makes sense to say that it shouldn't rely on process.env existing in that context. This is why we separate our application logic, especially with JavaScript. You can of course, write a fetchBlog function that takes one or more arguments.
Somewhere in your utils.js or something:
// with one argument like in your exampleexportconstfetchBlog=apiKey=>fetch(`https://www.example.com/api/blog?api_key=${apiKey}`)
// somewhere else where process.env is available and the logic isimport{fetchBlog}from'./utils.js'const{API_KEY}=process.envfetchBlog(API_KEY).then(...)
Often there is not just an API key. With multiple arguments you can do something like this and pass an object.
// with multiple argumentsconstfetchBlog=options=>fetch(`https://www.example.com/api/blog?api_key=${options.apiKey}&post=${options.postId}`)
You can still insist on throwing exceptions simply inside the fetchBlog function.
// this function still has no idea what goes on in process.envconstfetchBlog=asyncoptions=>{const{apiKey,postId}=optionsif(!apiKey)thrownewError(`Missing API key`)if(!postId)thrownewError(`Missing post id`)returnfetch(`https://www.example.com/api/blog?api_key=${apiKey}&post=${postId}`)}
Tadaa, no matter if apiKey or postId are undefined or the API endpoint itself returns an error because the key/post does not exist or some other reason, you receive proper feedback error message.
But even then, your post started with a typo case. It is useful to ask yourself if a real world situation exists where that could happen, especially if it is your own application. If your code design patterns and abstractions are correct then you will have dealt with the missing environment variable way before any HTTP request is made.
I think it is a bit early to tell people what will make them a better software engineer.
Hey @jochemstoel, I understand your point but I think verifying the necessary API_KEYs at the start of the application would prevent lot's of potential errors and we wouldn't make redundant api calls just to get an error.
This error also could happen during a crutial operation like a purchase or something... I think I'd prefer to check my API KEYS or TOKENS at the start of the application, at least this is what I took from this article.
Also, I understand the article title is a bit provocative but I wouldn't take these kind of things personally. I think author was just trying to get your attention, not to question your skills :D
Have a nice day 🖖
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I don't really see the point of all this. You received a very common error with a simple to find cause and fixed it. Then you wrote a whole post about environment variables in which you overcomplicate the thing entirely.
Most developers that work with Next are expected to know some way to properly deal with environment variables with things like dotenv but let's assume they don't.
Although poor choice of words, I know what you mean there and you are right. It makes sense to say that it shouldn't rely on process.env existing in that context. This is why we separate our application logic, especially with JavaScript. You can of course, write a fetchBlog function that takes one or more arguments.
Somewhere in your utils.js or something:
Often there is not just an API key. With multiple arguments you can do something like this and pass an object.
You can still insist on throwing exceptions simply inside the fetchBlog function.
Tadaa, no matter if apiKey or postId are undefined or the API endpoint itself returns an error because the key/post does not exist or some other reason, you receive proper feedback error message.
But even then, your post started with a typo case. It is useful to ask yourself if a real world situation exists where that could happen, especially if it is your own application. If your code design patterns and abstractions are correct then you will have dealt with the missing environment variable way before any HTTP request is made.
I think it is a bit early to tell people what will make them a better software engineer.
Hey @jochemstoel, I understand your point but I think verifying the necessary API_KEYs at the start of the application would prevent lot's of potential errors and we wouldn't make redundant api calls just to get an error.
This error also could happen during a crutial operation like a purchase or something... I think I'd prefer to check my API KEYS or TOKENS at the start of the application, at least this is what I took from this article.
Also, I understand the article title is a bit provocative but I wouldn't take these kind of things personally. I think author was just trying to get your attention, not to question your skills :D
Have a nice day 🖖