It all started during one of my routine code reviews at work. I was reviewing a piece of functionality that had recently been implemented. The task...
For further actions, you may consider blocking this person and/or reporting abuse
I think you need to consider the overall architecture. It sounds to me like the API server is unnecessary and might actually be a bottleneck that will affect scaling and performance.
Depending on the architecture, you may have an event-driven paradigm or some other need that necessitates communication between micro services. This does not have to be REST based. You might look at using queues, messaging platforms like Kafka or gRPC.
The bottom line here is that your technical needs should drive the design.
@phototrip_8f65aa1941692af Thank you for sharing your thoughts and for adding such valuable insights! The use case I described in the blog was meant to illustrate one approach and just differentiating their use and not suggesting, but you’re absolutely right.
Your suggestion to explore event-driven paradigms, queues, or messaging platforms like Kafka or gRPC for inter-service communication is spot on. These tools can indeed enhance scalability and performance, especially in systems with high concurrency or complex workflows.
Thanks again for contributing to the discussion! If you have any recommended resources or examples for designing such architectures, I’d love to hear about them. 😊
Wait you created and named API server for microservice just to merge data/response from multiple microservice right?
But what if you have to get Order or User data? I guess you hit their own url (redirect API gateway).
Then I think you API server is just a another microservice you just complicate it by putting API Service (since this is used for some combine data case only)
To get specific user data or order data ,
For straightforward, service-specific operations (like fetching order details or user information), the API Gateway can directly route requests to the respective microservices. The API Server comes into play only when there’s a need for:
Yes, the primary role of the API Server in this setup is to handle orchestration and aggregation for use cases where multiple microservices are involved. This approach abstracts the complexity for the client, providing a single, unified API endpoint. While this might seem like an added layer, it simplifies client-side interactions, especially for cases requiring combined or dependent data.
In observing that the API Server can be seen as another microservice. However, its purpose is slightly different:
It acts as a middleware layer to manage cross-service interactions.
This design can improve modularity and simplify clients by offloading orchestration and verification logic to a centralized service.
In systems without an API Server, clients or the API Gateway might need to handle these responsibilities, increasing complexity in those layers.
i) What if you have to update some data that makes changes to multiple services, so you use API Server in this case as well?
Or have to update data on some service what need to check/verify from other service, you use API server here as well?
This is another key use case for the API Server:
Great question! In scenarios where updating data involves changes across multiple services:
The API Server helps keep microservices loosely coupled by centralizing coordination.
Thank you, easy to read and understand. Looking for more.
You're welcome! @chetan_more_bb6c32cfcb360 I'm glad you found it helpful.
Instead of a single API server or gateway, use a domain and map the path using base path mapping.
Have each path map to it's own API gateway for maximum decopling and seperste the http layer from the service layer.
What are API Gateways usually made with? Are they web servers like nginx or are they runtime services like Nodejs or Java?
Makes me wonder if API Server and Gateway could be merged
@deadreyo Firstly, API Gateways can be built using different technologies depending on the requirements of the system.
It’s technically possible to merge an API Gateway and an API Server, especially if you have a small or simple system. However, in most cases, keeping them separate is beneficial due to their distinct roles.
In small-scale applications or monolithic architectures, merging the API Server and Gateway could reduce the number of components to manage.
Can web servers manage the authentication and token verification? I assumed no and that a runtime is required for these, due to needing to do complex computations or using a library (for JWT for example), or query the database to verify the token's body is valid.
It was thorough and detail, at least for me as a final year student trying to understand how things work in with complex business functionality and microservices.
Thanks!
Thank you for the kind words! @vedesh_padal