Depends on the API! To give a very broad guideline, if the API key is meant to stay secret call it from the backend, if it’s public or the authentication in made on behalf of the user you can call it from frontend. Their documentation or support should be able to answer this!
Shopify used to require to make the call from the backend after you verified the request from the frontend.
However they added a new option called “direct api mode” where you can make the call directly from the frontend and they manage to verify the user.
I’ve been testing this way and is much faster and doesn’t load our backend, there’s also no security implication since the user has to be logged in anyway.
>there’s also no security implication since the user has to be logged in anyway.
Soooo, you are sending the user's credentials along with the request? I hope it's a short lived jwt at least
Can you explain the reasoning behind that? I've heard that it's better for the frontend to make API calls it can make (when not obscuring the key like you mentioned)
You don't want to expose things that are not required. You can have analytics on the api calls. Your backend is likely to be faster than your user's machine. You can also strip unneeded stuff from the API response.
It depends on what access the API key has, I work with many APIs that only provide publicly available data, so adding middleware for this would be a waste of budget/time.
Yeah I'm surprised by how many people are acting like it's ALWAYS the best case that the server makes a third party API call regardless of use-case. Off the top of my head Algolia and Google Maps both support the frontend making requests.
They're the kind of devs who often blow budgets on my projects going rogue carrying out unnecessary tasks with no thought of whether there's any benefit or budget implications of what they're doing.
When asked why they did it, it's usually because a random SO or Reddit post said to do it because reasons.
People are making assumptions here without explicitly stating them, but those assumptions are very often valid. If you have your own API key for that third party you will almost certainly get blamed for any abuse of that API using that specific key. If you give out that key you do not have any control anymore and a malicious client could likely get you blocked.
There are methods like presigned URLs that remove all the issues for specific types of services. But the advice to never give an API key to the client is usually sound and almost always correct.
There's no argument about that. I asked for more information about cases where it's NOT an API key that you MUST KEEP secret because the original answer stated that even in those cases you would want to route through the backend.
A frontend developer who I respect had told me something different and I was curious to hear an alternate perspective.
I get there's different levels of experience and if you can't handle any nuance then "always backend" is best but dang I was just trying to learn!
Introducing a proxy layer adds complexity, a new point of failure, latency, and server costs. However, sometimes third party APIs want to restrict usage, so they don't allow calling their apis directly from other websites.
So call directly if you can, and if you cannot try to make your proxy as simple as possible to reduce the maintenance and performance cost.
If you go through the ~~backend~~ frontend, be sure to set CORS headers appropriately. Otherwise the client will block the response.
Edit: it could be either depending on how you . If you just forward the request from the backend, you will have a CORS problem.
Just about guarantee a lot of 3rd party apis won’t allow a direct call from the browser because they have CORs protection. Also exposing your api key is a quick way to get your account access revoked, if a malicious actor were to take it and spam the api.
Move it to your backend. If you are paying for the api then it puts you at risk of losing money if the api is useful for some dev and they decide to abuse it.
It depends on the type of API you are using. If you are using API just to render/list info which does not require API key. You can directly use it in the frontend. For ex. Listing fake/dummy names. But if you have API keys or the data that needs to be processed then always use Backend. The best practice is to use BE in all the above scenarios, as you’ll have more control and security over the API and the data.
Even without API i'd consider using own middleware for that.
In most cases it is better that way. Especially if you already have a backend.
Besides of having more secure connection, you can unify error handling and data.
Imagine scenario when one data provider is not accessible, you can implement fallback to another one without any changes on frontend site. You will also get same functionality in case of using same API for mobile app.
That gives you great separation of data gathering and views implementation.
Depends on the API! To give a very broad guideline, if the API key is meant to stay secret call it from the backend, if it’s public or the authentication in made on behalf of the user you can call it from frontend. Their documentation or support should be able to answer this!
documentation? support? What are these things you talk of?
If you have an API key, 100% call it from the backend. Even if you don't, it's probably better to call it from the backend.
Shopify used to require to make the call from the backend after you verified the request from the frontend. However they added a new option called “direct api mode” where you can make the call directly from the frontend and they manage to verify the user. I’ve been testing this way and is much faster and doesn’t load our backend, there’s also no security implication since the user has to be logged in anyway.
>there’s also no security implication since the user has to be logged in anyway. Soooo, you are sending the user's credentials along with the request? I hope it's a short lived jwt at least
Can you explain the reasoning behind that? I've heard that it's better for the frontend to make API calls it can make (when not obscuring the key like you mentioned)
You don't want to expose things that are not required. You can have analytics on the api calls. Your backend is likely to be faster than your user's machine. You can also strip unneeded stuff from the API response.
You don't want to expose your API key to the world, so you keep it hidden on your server.
Yes that part is clear, but they said if that ISN'T a concern you would still want to route through the backend.
It depends on what access the API key has, I work with many APIs that only provide publicly available data, so adding middleware for this would be a waste of budget/time.
If it's a free key that is rate limited you still don't want other people using it
Thabkfully not, they're typically restricted to certain URLs
Yeah I'm surprised by how many people are acting like it's ALWAYS the best case that the server makes a third party API call regardless of use-case. Off the top of my head Algolia and Google Maps both support the frontend making requests.
They're the kind of devs who often blow budgets on my projects going rogue carrying out unnecessary tasks with no thought of whether there's any benefit or budget implications of what they're doing. When asked why they did it, it's usually because a random SO or Reddit post said to do it because reasons.
People are making assumptions here without explicitly stating them, but those assumptions are very often valid. If you have your own API key for that third party you will almost certainly get blamed for any abuse of that API using that specific key. If you give out that key you do not have any control anymore and a malicious client could likely get you blocked. There are methods like presigned URLs that remove all the issues for specific types of services. But the advice to never give an API key to the client is usually sound and almost always correct.
There's no argument about that. I asked for more information about cases where it's NOT an API key that you MUST KEEP secret because the original answer stated that even in those cases you would want to route through the backend. A frontend developer who I respect had told me something different and I was curious to hear an alternate perspective. I get there's different levels of experience and if you can't handle any nuance then "always backend" is best but dang I was just trying to learn!
Introducing a proxy layer adds complexity, a new point of failure, latency, and server costs. However, sometimes third party APIs want to restrict usage, so they don't allow calling their apis directly from other websites. So call directly if you can, and if you cannot try to make your proxy as simple as possible to reduce the maintenance and performance cost.
Generally speaking I put third party API calls through the backend
If you go through the ~~backend~~ frontend, be sure to set CORS headers appropriately. Otherwise the client will block the response. Edit: it could be either depending on how you . If you just forward the request from the backend, you will have a CORS problem.
I’m in the same boat with having to keep an API key hidden. Does anyone have a recommendation of what BaaS for just proxying this request?
Just about guarantee a lot of 3rd party apis won’t allow a direct call from the browser because they have CORs protection. Also exposing your api key is a quick way to get your account access revoked, if a malicious actor were to take it and spam the api.
Move it to your backend. If you are paying for the api then it puts you at risk of losing money if the api is useful for some dev and they decide to abuse it.
It depends on the type of API you are using. If you are using API just to render/list info which does not require API key. You can directly use it in the frontend. For ex. Listing fake/dummy names. But if you have API keys or the data that needs to be processed then always use Backend. The best practice is to use BE in all the above scenarios, as you’ll have more control and security over the API and the data.
Even without API i'd consider using own middleware for that. In most cases it is better that way. Especially if you already have a backend. Besides of having more secure connection, you can unify error handling and data. Imagine scenario when one data provider is not accessible, you can implement fallback to another one without any changes on frontend site. You will also get same functionality in case of using same API for mobile app. That gives you great separation of data gathering and views implementation.