I basically have a smaller software that is using the Microservice architecture. I am currently using RabbitMQ to do the communication between UI and services and that works great.
However I am thinking about creating a new microservice, a API Gateway, that basically takes the RabbitMQ logic from the UI and encapsulate into a service, which would become the entry point to all the other services.
The benefit is that I would encapsulate the logic that give access to the services and also being able to add authentication in the API Gateway.
However I would need to use HTTP request to interact with the API as I am moving the messaging logic from the UI. Could there be any major drawbacks in this approach?
I have being able to find examples about RabbitMQ and examples about API Gateways but never those two together, I might just be overthinking it a bit.
Related
In our application, we adopted a microservices architecture pattern. I am bt familiar with microservices architecture but I have a few doubts:
API Gateway: Userful to have a single point of entry to connect with all microservices and on top of that we can enable other features like routing, aggregates, load balancing, etc. for this we are using Ocelot API gateway.
Aggregator: There are many scenarios where, we need to call multiple services, fetch the data and combine them into an API response.
I would like to know, should we use API Gateway and Aggregator?
Also, I checked Ocelot documentation and Ocelot does provide the Aggregate feature but only for GET calls. but in our API implementation, we have a POST call to fetch the data.
also, Just wanted to confirm, that we have ActiveMQ in place for asynchronous communication between services mostly when we have transactional data.
so, should this transactional communication also be taken care of by the Aggregator service or from the API gateway?
I would really like to understand if my reasoning is correct here.
Thank you in advance!
Several articles about Event Driven Architectures recommend an event broker (for example Kafka via topics) to integrate backend services and in addition RESTful interfaces for these backend services (here an example from Guido Schmutz: Building event-driven (Micro)Services with Apache Kafka, 2019, p. 19).
The RESTful interfaces provide access for GUI and external services. These GUI and external services access the RESTful services via an API Gateway. So each backend service has two interface types: a RESTful interface and a channel interface (event broker).
My question is: what are the advantages of providing RESTful API in addition / in parallel to the integration of backend services via an event broker? The reason for this question is that the event broker could provide the same capabilities (synchronous request response).
You're correct, the event broker could provide the same capability: one of the purposes of an API Gateway is to perform 'protocol translation'.
The advantage of using a RESTful API for your 'frontline' microservices depends significantly on your specific situation. Interestingly, there is nothing stopping you from providing a RESTful API via an event broker (REST is explicitly protocol agnostic). However, if by RESTful you mean over HTTP, then there may be benefits to using this protocol. As an example, if you intend for your microservices to be consumed by 'other' clients, then (despite the rise in event-driven architecture) HTTP is still objectively the most ubiquitous protocol in existence.
This is very subjective, but 'request-response' is an afterthought for event-based frameworks. If you want to follow that model, you might be best served using frameworks and technologies that are designed for it.
As you mentioned, you can of course provide a RESTful API in parallel. If this is appropriate really depends on your use-cases.
My two cents: use whatever architecture is easiest and makes the most sense for you behind your API Gateway. The Gateway provides abstraction, so if the approach you take doesn't work out, you can change with little impact.
Im developing a web application using expressjs and wanted to leverage the latest technology and architecture i.e kafka, microservices etc - The frontend is React and is calling the backend microservices to retrieve data.
My current architecture, consists of multiple services serving as rest api endpoints in the backend such as user service, account service, company service etc
All these services work well and fine, but having to introduce kafka into the mix, i now require to publish a 'new user' event when a client registers for an account -> the user service publishes this event but then now require the accounts service to consume it.
Should i be creating a new subscriber service individually consume this event, connecting to the same db as the account service (though doesn't this defeat the purpose of1 database per service microservice architecture)? or should the accounts service that is acting as a rest api endpoint also consume the kafka event (doesn't this also then complicate things when theres 20+ microservices, spending time checking what service is consuming what event)?
I'd like to know what the best approach is with this kind of situation.
In general, the microservices will have rest apis for providing any business/CRUD capabilities and the Kafka broker will mostly be used for achieving eventual consistency and also for triggering any actions(by dedicated Kafka consumers) asynchronously.
Now to your particular question -
Should i be creating a new subscriber service individually consume this event, connecting to the same db as the account service (though doesn't this defeat the purpose of1 database per service microservice architecture)?
The microservices will have their own data stores which may require to be consistent/in-sync with data stores belonging to other microservices. You can created dedicated Kafka topics for relevant events, for e.g. "User_Resource" could be a Kafka topic where you could publish all the events(CRUD) related to User resource. These topics can be subscribed by other microservices and the consumers will have logic to handle these events ( update account service database, trigger notifications to other down-streams etc.). This will also create clean separation between CRUD and business services.
or should the accounts service that is acting as a rest api endpoint also consume the kafka event (doesn't this also then complicate things when theres 20+ microservices, spending time checking what service is consuming what event)?
A service which exposes a rest endpoint can also act as a Kafka producer/consumer. If your application is built using Spring boot and spring cloud framework, you can use spring-cloud-stream to handle Kafka interactions in simplest way. The services need not to be bothered about the state of other services as they are supposed to be independent.
I create my API rest with Django, but I don't understand how convert an API to micro services, I don't understand the real difference between these.
I see an API like a micro service, but I don't know convert an entire API in micro service, I need create micro web servers?
Please, I can't understand a micro services, and I need understand this.
A microservice exposes it's interface, what it can do, by means of an API. The API is the list of all endpoints that a microservice respond when it receives a command/query. The microservice contains the API and other internal+hidden things that it uses to respond to client's requests.
An API is all that the clients see when they look at the microservice, although the microservice is bigger than that. A microservice hides its internal structure, it's technology stack, it's database type (sql, nosql - it could be anything); a microservice could move from sql to nosql, from python to php, but keep it's API unchanged.
API - It a way of exposing functionality over web. Imagine you have developed some functionality in .Net but not you are developing some software in a different language. Would you develop the same functionality again? No. So, just expose it via web service.Web services are not tied to any one operating system or programming language. For example, an application developed in Java can communicate with the one developed in C#, Android, etc., and vice versa.
Microservice - They are used to break a complex software into small pieces of individually deployable, testable, loosely coupled sub-modules. Micro Services are designed to cope with failure and breakdowns of large applications. Since multiple unique services are communicating together, it may happen that a particular service fails, but the overall larger applications remain unaffected by the failure of a single module.
API Vs Microservice - Now that we have broken our complex software into loosely couple sub-modules. These sub-modules communicate with each other via an API. Therefore, Microservices and an API solve different problems but works together!
More Details:
The Difference between Web Services and Micro Services
RESTful API vs Microservice
a microservice is an autonomous RESTful service. It means, there is just one service on each server. In Spring Boot when you bootstrap your RESTful service, it will get an instance of tomcat(it's embedded tomcat) and run your service on it. So, if you have more than one service on a server, it is not a microservice, because these services are not autonomous.
I am working on one school project, And my task is to make a simple api gateway, which can placed between any of the 3rd party api and the end users, tha gateway can be used for defining usage limits of the api or to do some security analysis, I am totally new to this, I know the basic concept of API gateway, but don't know how do I implement it using JAVA.
Can anyone please give me some starting point where to start implementation of API gateway?
And what are the frameworks I should use and for what purpose?
Thanks,
Nixit Patel
In a nutshell, API gateway exposes public APIs, applies policies (authentication - typically via OAuth, throttling, adherence to the the defined API, caching, etc.) and then (if allowed) optionally applies transformation rules and forwards the call to the backend. Then, when the backend responds, gateway (after optionally applying transformation rules again) forwards the response to the original caller. Plus, there would typically be an API management solution around it providing subscriber portal, user management, analytics, etc.
So basically any web service framework would work as a quick DYI solution.
You can also use plugin model of an open-source load-balancer such as NGINX.
Or take an open-source API Gateway to learn from it - e.g. WSO2 API Manager (the easiest way to see it in action is the hosted version: WSO2 API Cloud)