Question about vanilla authentication logic + session + state
Answered
Egyptian Mau posted this in #help-forum
Egyptian MauOP
Hello folks, I'm a newbie on nextjs and on ssr so this might be a question where you'll just link to some documentation but I have already read the official documentation so please link something else if it is a triial question, thank you.
I'm trying to understand the request response cycle to implement a very basic bearer token authentication with an already existing api built with another backend solution. I do have this backend api up and running and I've written a client in typescript to consume this api. I have a vanilla nextjs app that I am developing and I am sending my obtain bearer token request from my login component and passing it to a server action to set as a cookie in the front end. From this moment on I need that token in the backend in the client, and the way I implemented the client is typescript classes so I need to init my client and init takes this very said token. I am planning on removing the init argument and just read the token from the cookies on constructor. My api client is initialized globally in the api module like so:
Can I keep initializing this globally like so and still read the cookie in the constructor and if cookie is defined pass it to the underlying fetch client, and expect everything to work?
I reckon this would only work properly if next js doesn't reuse the same thread for multiple requests. If the app handles one request, then dies and spins up a new application "instance" per request (not talking about the process, idk what is the underlying protocol is in node so I'm calling it an "instance") this should work.
Or do I need to move initializing logic to each and every component that uses the api client?
I'm trying to understand the request response cycle to implement a very basic bearer token authentication with an already existing api built with another backend solution. I do have this backend api up and running and I've written a client in typescript to consume this api. I have a vanilla nextjs app that I am developing and I am sending my obtain bearer token request from my login component and passing it to a server action to set as a cookie in the front end. From this moment on I need that token in the backend in the client, and the way I implemented the client is typescript classes so I need to init my client and init takes this very said token. I am planning on removing the init argument and just read the token from the cookies on constructor. My api client is initialized globally in the api module like so:
export const api = ServiceNameApi() Can I keep initializing this globally like so and still read the cookie in the constructor and if cookie is defined pass it to the underlying fetch client, and expect everything to work?
I reckon this would only work properly if next js doesn't reuse the same thread for multiple requests. If the app handles one request, then dies and spins up a new application "instance" per request (not talking about the process, idk what is the underlying protocol is in node so I'm calling it an "instance") this should work.
Or do I need to move initializing logic to each and every component that uses the api client?
Answered by Black carp
TL;DR - don't use singletons, you can instantiate a class at the top of a request and you can make it live for the duration of that request.
Singletons CAN bleed between requests of different users if the lambda is reused (if deployed there), or if the node server is running (when standalone).
At least this was my experience when I was trying to make some singleton services based off of dynamic configurations.
Singletons CAN bleed between requests of different users if the lambda is reused (if deployed there), or if the node server is running (when standalone).
At least this was my experience when I was trying to make some singleton services based off of dynamic configurations.
2 Replies
Black carp
TL;DR - don't use singletons, you can instantiate a class at the top of a request and you can make it live for the duration of that request.
Singletons CAN bleed between requests of different users if the lambda is reused (if deployed there), or if the node server is running (when standalone).
At least this was my experience when I was trying to make some singleton services based off of dynamic configurations.
Singletons CAN bleed between requests of different users if the lambda is reused (if deployed there), or if the node server is running (when standalone).
At least this was my experience when I was trying to make some singleton services based off of dynamic configurations.
Answer
Egyptian MauOP
Ah, I see. Thank you for the information, I'll keep this in mind for the entire structure of the project then.
Thank you so much.
Thank you so much.