I wonder about the code with the heading “A Server Component with data fetching”.
It shows a HTTP request made to the company’s publicly visible API endpoint. But this request is being made from their own server (the one that is generating the HTML + JS from these React components).
Is the idea really that your front-end generator calls client APIs rather than internal ones (e.g. just making a database request)? That seems kind of wasteful, and also potentially confusing from a API design standpoint.
What makes you think that server-side JS could not call a private API with authentication?
If it's a "front-end generator", we are talking about gerating static HTML, CSS, JS though. This means all "secrets" have to be embedded in client code, or the API calls have to be made at build time, with the static result embedded into the output.
So I don't see your point really.
If your point is talking to a database "directly", using only a database client and no remote intermediary, you can do this in Node as well.
And presumably also in RSCs, since it's already possible in SSR.
It's a limiting, but saner approach for any larger app/company.
It's the same logic why in OOP you have private members/methods. As owner/maintainer of some component you want keep stable public api and be able to iterate on the internals.
Letting any client willy-nilly directly fetch from database is unsecure and unmaintainable in future.
> Letting any client willy-nilly directly fetch from database is unsecure and unmaintainable in future.
Surely you'd just want to be calling the internal API that the other endpoint is using behind the HTTP endpoint? If you're in the same process (big if, but nothing to suggest they aren't), there's not a lot of sense serialising out to a socket and back again rather than making a function call.
Sure, calling internal API is sensible. I am not saying it needs to be public API. But you probably can't avoid some serialization (be it REST, GQL, GRPC), the service that owns the data can be different than the one serving the html.
I am not saying everybody needs to do microservices but my experience with monolith is bad. You want at least "some" services and the html-serving service shouldn't usually own the data. User data belongs to user service, report/analytics data to analytics service etc.
Just from the security point of view, the stuff facing internet should have minimum rights to read/write anything. Definitely not direct function-calling or db access.
There’s a world of difference between an internal API and directly fetching from a database.
What concerns me here is mixing up internal APIs with client APIs that are callable from the outside. It just feels weird not to have this distinction when generating pages on the server.
It shows a HTTP request made to the company’s publicly visible API endpoint. But this request is being made from their own server (the one that is generating the HTML + JS from these React components).
Is the idea really that your front-end generator calls client APIs rather than internal ones (e.g. just making a database request)? That seems kind of wasteful, and also potentially confusing from a API design standpoint.