I'm currently working on a microservices architecture. Thoses microservices will be integrated in web-portal which will be the entry point. I'd need to use an api gateway(edge-server) but i'm wondering if it's better to create a separate microservice dedicated to api gateway or use the web-portal microservice as api gateway.
What do you think would be a better choice?
Thanks in advance
An api gateway should be the only way your miroservices should be accessed.
So the microservices should use each other through the api service as well.
I would not like my microservices to call the webportal as an api service.
Another point is, that you can't scale the api service (which is a bottle neck by design) independet of the ui.
So my suggestion is: Create the api gateway as a separate microservice.
Related
Is it recommended to invoke REST-API through microservice instead of direct REST endpoint calling? any pros & cons on that? is it a kind of duplication (redundancy).?
for example, We are using API Management Gateway. There are so many REST API's which are providing for UI/API related functions. but if our client trying to use those APIs through their microservices then it would be a kind of duplicate scenario, or not.?
You don't need to have microservices if it is not needed. You should start by reading more about microservices. It really depends on your project. There should be no difference in calling an endpoint whether you have a monolith architecture or a microservice. My advice would be to read more about microservices.
I hope you will find a way with the challenge you are facing.
From your question what I can understand is , you are trying to ask if you can use same api which can be called from UI as well as your client will call it from their microservice.
If this is so , then there are generally no pros and cons as such. It all depends on how your architecture is designed.
If you are using same api for both i.e. UI as well as you are exposing to your client , then probably your api design is very flexible, but at the same time are you handling security properly ?
In other case say you are using different apis, then yes it would be a redundancy lets say if input/output params are same in both cases.
So you really need to understand the design first.
I am developing a bookstore application based on microservices architecture with Spring and Netflix OSS.
I made a shopping service, with all the stuff necessary to buy a book. But I need to integrate with two services.
One service is a shipping service, this is an internal service. Connected through a Feign client.
The other service is an inventory service, this is an external service. Connected through an external library. This is a problem because it's more difficult to mock.
In order to connect with this services from shopping service, I thought that the adapter pattern was a good idea. I made another service, a shopping adapter service, that is used to connect with the other two services. And with this architecture, I can test the shopping service mocking the adapter service.
But now I think that is a bit awkward solution.
Do you know which is the best architecture to connect with external or internal services?
First, is it correct that’s what I understand?
Compound Service --(use)--> shipping service
----------------------------(use)--> inventory service ( this project uses external
library )
If it is right, I think it is not difficult to mock.
Create an inventory microservice project for wrapping external library.
Because compound service doesn`t need to care what we need to use a certain library for inventory. Your Inventory microservice project just exposes endpoint for using inventory service.
In the microservices world, services are first class citizens. Microservices expose service endpoints as APIs and abstract all their realization details. The internal implementation logic, architecture, and technologies, including programming language, database, quality of services mechanisms, and more, are completely hidden behind the service API.
Then, You can mock Inventory service at your compound service test code.
#Configuration
class MessageHandlerTestConfiguration {
#Bean
public InventoryClient inventoryClient() {
return Mockito.mock(InventoryClient.class);
}
I don't think creating another microservice which you should maintain and monitor and keep resilient and high available etc. just to have a kind of facade or adapter is a good idea. This statement may be proved wrong for some very special cases but generally if you don't have a context to maintain then it is not a good idea to create a new microservice.
What I could recommend would be directly calling shipping service by paying attention to anti corruption layer pattern which keeps your actual domain's service code clean from other microservice's domain entities.
You can find some more information about anti corruption layer here https://softwareengineering.stackexchange.com/questions/184464/what-is-an-anti-corruption-layer-and-how-is-it-used
I am learning about microservices and I don't understand what the real difference
between creating a REST API and creating microservices?
I’m working in Go, but my question applies over all languages.
The Microservices approach is about breaking your system ("pile of code") into many small services, each typically has its own:
Clear business-related responsibility
Running process
Database
Code version control (e.g. git) repository
API (the protocol how other services / clients will contact the Microservice)
UI
The services themselves are kept small so as your system grow, there are more services - rather than larger services.
Microservices can use REST, RPC, or any other method to communicate with one another, so REST or an API is really orthogonal to the topic of microservices...
Reference: What is an API? In English, please.
API = Application Programming Interface
Microservices = an architecture
In short
Microservice should expose a well-defined API.
Microservice is the way you may want to architect your solution
API is what your consumers see.
You can expose API without microservices in the backend (in fact, most non-training scenarios don't require microservices).
You may want to read http://samnewman.io/books/building_microservices/ before you decide on using microservices (unless this is for training purposes).
Microservice is well defined when you are following SOC - seperation of Concern on the entity/domain level ,where each entity / domain are independent of any other service.
for example user service will only be responsible for storing, updating and deleting user related informations.
Microservice backend and frontend microservice can further be splitted in 2 parts
frontend microservice which exposes rest endpoint just like Web API
backend microservice which actually perform all the operations.
Rest API is more of endpoints exposed to outer world and can be used with microservices as well, as explained above.
The majority of the answers is based on the old-school understanding of API as a programmatic interface. Nowadays, this meaning is melted and start confusing people becuase some developers started (for simplicit or by mistake) interpred the API of an application as the application per se. In such case, it is impossible to distinguish between the modern API and Microservices. Nonetheless, we can say that an API-application can comprise many Microservices, the most of which interact within the application via Microservice's APIs while others may expose their APIs as Applications's APIs. Also, a Microservice (as a service) may not include other Microservices (services), but may orchestrate a composition of Microservices via API-bases invocations. Applications may contain Microservices but, in the best practices, may not contain other Applications.
Microservices
A microservice architecture is about slicing an application logic into small pieces or "components" that can act between them and/or be exposed through an API.
API
A (web) application need to design the business logic with all set of object entities (model) and possible operations on them.
An (Application Programming Interface][https://en.wikipedia.org/wiki/Application_programming_interface) is a way of making the requests to an application by exposing specific entry-points that are in charge of invoking the appropriate application operations.
ReST(ful) APIs
("ReST" as in Representational State Transfer) are APIs complying with at least these 5 constraints:
User-interface is distinct from data storage and manipulation (Client-Server architecture)
No client context is stored on the server ("stateless")
Server responses must, implicitly or explicitly, define themselves as cacheable or not
Client does not have to be aware of the layers between him and the server
Response/request messages must be: be self-descriptive; allow to identify a resource; use representations allowing to manipulate the resources; announce available actions and resources ("Uniform interface").
"The real difference"
So, while these notions are obviously related, they are clearly distinct concepts:
Being ReSTful or not, an API exposes operations provided by a server that might (but not necessarily) be shelled into smaller components (microservices).
Also, while a typical web (ReST)API uses the HTTP protocol between the client and the server, components within a microservice architecture might communicate using other protocol(s) (e.g. WAMP, AMQP, JSON-RPC, XML-RPC, SOAP, ...)
In layman's term, if you have a web API server and you split them into several independent mini servers, use a proxy-server and load-balancer to clusterize them, and (optionally, give each a separate database entity), that is a microservice architecture.
I was reading about this GRPC Gateway and wondering if using only the REST endpoint generated by it makes a service more reliable and efficient in any way.
If I'm sending JSON over HTTP first, I lose all the RPC/pb lightweight and async capabilities, right?
What is the point for using this lib, aside from the flexibility to choose one or another service layer?
Your understanding is correct. The main purpose of the project is to keep an avenue for the clients that may not be able to use gRPC, but have the ability to connect to an HTTP/JSON server supported without additional manual work.
I am building an application using microservice architecture. It has five Rest API and one UI(single page application) microservices.
Could anyone advise me which is the best option to do the data aggregation?
Make UI application as a static web application and do all API requests from the front end (from the browser using javascript framework) and all data aggregation do in front end itself and render?
Make UI application as a dynamic web application and do all API request and data aggregation in web application backend?
It sounds like the pattern you are looking for is API Gateway. Sometimes also called "Edge" or "EdgeService". It can be used to as a single entrypoint to your cluster and to aggregate service call results. Other use cases include central authentication and/or authorization as well as routing, monitoring and resiliency.
Some people only route external calls through a gateway, others route also internal calls through the gateway.
Here some technologies to look into:
Zuul from the Netflix stack. You have write a filter for aggregation. See this document.
Amazon API gateway - If you are running on AWS. You would typically use your own lambda service for aggregation.
Kong. Doesn't have native aggregation support, but you can forward to a separate aggregation service that you provide.