3 ms·
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 co
by morbicer 3y ago
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.
- 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.
- pavlov 3y agoThere’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.