Communication with the backend
Answered
Northeast Congo Lion posted this in #help-forum
Northeast Congo LionOP
Hi, I recently started developing a next.js app. I already have a backend developed with Strapi. So my next frontend will communicate with it via API endpoints (not direct connection to DB as with Prisma for example). I have doubts on how to organise REST actions on frontend.
So far I've been executing all the GET requests inside server components, but PUT/POST can be executed only inside client components.
My question is: is it better PUT/POST directly inside a client component, or to call a special route of my next app where I have implemented this PUT/POST request.
Which way is safer and/or faster?
I'm using next app directory.
(Also is you have some good resources or github repos of next or next+strapi projects with good architecture, it will help me a lot to understand how to organize my project. Thank you 🙌 )
So far I've been executing all the GET requests inside server components, but PUT/POST can be executed only inside client components.
My question is: is it better PUT/POST directly inside a client component, or to call a special route of my next app where I have implemented this PUT/POST request.
Which way is safer and/or faster?
I'm using next app directory.
(Also is you have some good resources or github repos of next or next+strapi projects with good architecture, it will help me a lot to understand how to organize my project. Thank you 🙌 )
Answered by Eric Burel
so yeah it would be more natural to send the requests from the client directly
13 Replies
Depend whehter the API has been designed to talk to a client or not
in the case of Strapi, I think it's a fit for client-side data fetching so that's ok to run mutations from there
Cases where you need a server action/ an additional endpoint is for APIs that are designed to communicate with servers
for instance Stripe is made to be called by an API (perhaps they have more stuffs now but you see what I mean)
a rule of thumb is to check how you authenticate to the API
if they ask for an API key, it means you have to run your calls server side
because you cannot send the API key to your client app
if the security is based on the domain name, for instance you have to whitelist some valid domain, then it means it has be designed to be called client-side
@Eric Burel a rule of thumb is to check how you authenticate to the API
Northeast Congo LionOP
In Strapi they have public and authenticated types of API access (basically I can make some rotes public, some protected, some mixed so the response differ depending if user is authenticated or no).
To access protected rotes it's necessary to use 'Bearer ' + jwt in headers (client gets this jwt from strapi backend once after login)
I store jwt in next-auth session
I had concerns if it's safe to store the jwt this way, and run mutations from client with it. But now I think in regular React apps it is the only way to communicate with server, so it should be safe I believe
Thanks for your explanation
To access protected rotes it's necessary to use 'Bearer ' + jwt in headers (client gets this jwt from strapi backend once after login)
I store jwt in next-auth session
I had concerns if it's safe to store the jwt this way, and run mutations from client with it. But now I think in regular React apps it is the only way to communicate with server, so it should be safe I believe
Thanks for your explanation
@Northeast Congo Lion In Strapi they have public and authenticated types of API access (basically I can make some rotes public, some protected, some mixed so the response differ depending if user is authenticated or no).
To access protected rotes it's necessary to use 'Bearer ' + jwt in headers (client gets this jwt from strapi backend once after login)
I store jwt in next-auth session
I had concerns if it's safe to store the jwt this way, and run mutations from client with it. But now I think in regular React apps it is the only way to communicate with server, so it should be safe I believe
Thanks for your explanation
If this JWT is specific to the end user then yeah it's meant to be stored client-side
relying on what your auth lib proposes is a good idea since you'll get the same level of security as other user crendentials
so yeah it would be more natural to send the requests from the client directly
Answer
Northeast Congo LionOP
Thank you