4 ms·
> 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 t
by regularfry 3y ago
> 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.
- morbicer 3y agoSure, 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.