Properly implementing "Browser <-> Next backend <-> API server" flow using OAuth
Unanswered
Mini Lop posted this in #help-forum
Mini LopOP
Hi, I'm just getting into full-stack architecture and am somewhat confused about the OAuth based architecture (such as Google or GitHub) while having next server send API calls to a backend server. I'm not sure if it's a conventional architecture or whether I'm seriously overcomplicating. Does everything seem fine here? Is this how you're supposed to use next backend (I think it's called BFF? Where next takes care of sending requests and serving pages, but actual heavy lifting is done by a separate server)?
50 Replies
Mini LopOP
The api server here would just work via JWT and give next backend basically everything it asks for, and doesn't know about sessions
Sun bear
what do you mean by "stores session data" in the next bff?
Mini LopOP
Things like sessionId, associated userId (you would need to infer user ID using session to do anything meaningful with API server)
Sun bear
i may be missing something here but if you're already using JWTs on the client doesn't it already store a signed version of this info?
generally from what i know next.js and stateful servers arent the best match you either keep it on client or on db
@Sun bear i may be missing something here but if you're already using JWTs on the client doesn't it already store a signed version of this info?
Mini LopOP
I was under the impression JWT is for authenticating your BFF into the API server
Like I said the whole thing is a little confusing to me so far, it looks like you're not supposed to perform computation in the next backend, but in order for communication to happen between next bff and api server you either put them on the same domain and proxy (in order to avoid cors) or authenticate in some way
Sun bear
is there a reason you're using a BFF and an API server?
Mini LopOP
Seemed like a bad idea to do business logic in next backend
Sun bear
how come
Mini LopOP
I had an impression javascript ecosystem wasn't really the best choice for parallel processing of high amount of data (I'm planning to do operations on word documents), so I was considering something like Spring or Asp .net
Sun bear
ah i see
Mini LopOP
Though I'm seriously not up to date with modern tech, it's just that I currently work with both Spring and Asp at my current place, but we use a simple react SPA
The Next backend is what's confusing to me currently
Sun bear
well the idea is that javascript is 1 thread and can run i/o concurrently non blocking
but for compute that would block the thread unless you delve into workers
but i agree at that point using what you're used to with something like c# is better
here is a thought though, why use next's backend at all? this sounds like a job for a SPA
to get back to your original point, depending on how you're hosting this next server your authentication state might not persist
if you're planning on hosting on a serverless platform like vercel, netlify or cloudflare workers then the next server instance only lasts for the duration of the request
@Sun bear here is a thought though, why use next's backend at all? this sounds like a job for a SPA
Mini LopOP
The reason is that I wanted to better familiarize myself with SSR and it's pros and cons, as I already know the issues of SPA
I think it's a good learning experience in general
As for the hosting, I was planning to just serve it with nginx, not yet familiar with vercel either
Sun bear
that works as well
IMO what i would do is simply forward the authentication state to the API server and let it handle all backend
next serves as just the Thing That Renders
Mini LopOP
Wouldn't I need to mess with csrf in this case?
Sun bear
or, something else you can do is move all auth to the next server and have your api server just be The Thing That Processes Documents
Sun bear
it depends if the api server is public or not
where will you host the api server
same box?
Mini LopOP
Api server, as I plan it to be, will be in the same server as my next backend and only visible to it
Sun bear
then that makes things a lot easier
keep your next server handling auth, api server only needs to worry about documents since you can assume that only valid requests from the next server will ever reach it
Mini LopOP
So authenticating next backend into api server is kinda overkill?
Sun bear
Yes, the next server lives on the same box as the api server per your words
next is not shipped to the user browser
Mini LopOP
In retrospect, makes sense, yeah
Alright then, ty, I'll look into simplifying the whole thing
Sun bear
my much more crude drawing
Mini LopOP
Since api server will also be querying DB, wouldn't it be more straightforward to route all DB requests through it anyway?
Sun bear
good question and i'd lean into no
letting your next server talk to the db for things like auth lets you simplify things in SSR land
plus wouldnt it be more involved if everytime you wanted a job done, you ask the API server to do it, api responds with "done" and then you go to the DB to check and serve back to the client?
why not make the api server respond back with the data and then you can do whatever with it in next land
really its just a question of how much responsibility you want next to have
and since you're ssring pages the more next can do the richer the experience is
theyre on the same persistent box, makes things a lot easier
Mini LopOP
Honestly, yeah, I think js will be able to handle simply reading/writing/wrapping data, while the actually heavy stuff gets offloaded to a more performant system