3 ms·
They're popular because, for better or worse, Microservices are popular. If you want to serve Microservices from a common host name as if they were a single ap
by BjoernKW 8y ago
They're popular because, for better or worse, Microservices are popular.
If you want to serve Microservices from a common host name as if they were a single application, e.g. for public users of an API, you need some sort of mapping between internal and external URLs.
Service discovery is another approach but that's probably only applicable to internal service usage.
- aequitas 8y agoThey where popular way before microservices, only less dynamic. Mostly from an operational perspective they give a single entry point which can be better secured and monitored. It also allows to easily decouple unstable backends from your user so even though functionality is broken (404), the user experience doesn't have to suffer (serve stale cache, respond with a proper branded error page which helps the user forward (instead of a cryptic app specific error page).
- fulafel 8y agoHow about just returning the service url along with the API auth token. This would enable load balancing and failover too.
- BjoernKW 8y agoYes, but that'd require a more complex process on the client. At least you'd have to send an additional request, e.g. instead of just calling https://someserviceprovider.com/serviceA https://someserviceprovider.com/serviceA you'd first have to call https://someserviceprovider.com/serviceA https://someserviceprovider.com/serviceA which for example would return { "url": "https://someserviceprovider.com:8081" https://someserviceprovider.com:8081", "auth_token": "..." } and only then could you call the actual service under https://someserviceprovider.com:8081 https://someserviceprovider.com:8081