Single external service and the main entrypoint of all requests into the system.In case there are several requests to be made they can be done in parallel using goroutines, the data can then be joined together and processed to build a response object that contains only the data needed. It implements the external API and translates external requests to one or more internal API requests. It maintains multiple gRPC clients with connections open to each of the microservices. The API Gateway is implemented as a standalone microservice that has no state. There are many references to this challenge, namely Backend for Frontend/API Gateway. Ultimately, the API defined by this service should become our “public API”, therefore it should be simple to generate API clients from itĪs we worked on this, we kept thinking: Surely someone must have come across this issue before.The service should be scalable and be able to handle a lot of traffic and have no state of its own.It should be easy to join/filter related data in an efficient manner.A single gateway for all requests - with all the security logic (authz/authn) centralized.We started researching the best and most elegant way to solve this, with the following requirements in mind: The API Gateway (AKA: Backend for Frontend) Besides the many network requests, the consolidation logic running on the client side is less efficient than running on a backend microservices (memory footprint, network latency between user browser and backend). But quickly we’ve had our web application making 10s of gRPC requests which slowed the site load down significantly. Initially we started by implementing this logic in the web application. Here, we’re faced with a dilemma: what service should implement the ListItemsGroupedByUsers() rpc call? Should it be the Web Application? Should the users service implement it?Īs is usually the case, the answer to this question is, “well it depends” - and there could be several solutions for it. In fact in many cases the JOIN logic could be more complex. Suppose you have the following logical data model:Īs you can imagine, this is a very common use case. Let’s unpack a DataConsolidation example to examine this further. TL DR: Fewer services exposed externally is more secure. But because microservices are not supposed to access data they don’t own, you have to use API calls to achieve that and you will need some application logic to process and merge that data. In relational databases speak, there will come a time when you want to JOIN over data that is managed by different microservices. The product will eventually require that you query and display this data. Data Consolidation - With microservices you may have relational data scattered across different services. In fact, we want to have 1 or 2 microservices that are internet facing and everything else to be internal.Ģ. Ultimately we wanted to minimize the attack surface and have as little as possible endpoints externally accessible. Mistakenly a developer could return sensitive data via an external endpoint, or someone could forget to add authz/authn middleware to one of the external endpoints, which could then cause a compromise. Do I need to reimplement this endpoint for internal use if I want to return some internal data?Ī wrong answer to any one of these questions could lead to potential security issues.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |