Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
today I started reading about Microservice architectures - and it seems to be very interesting!
But I have one doubt I need some explanation on:
Assume I want to create a blog and would build 4 microservices for that: User/login Service, Article Service, Comments Service and Reporting/analytics Service(not a realistic example, I know...).
The Reporting/Analytics service is purely backend - no issue here for my understanding.
But the three others involve some UI part - and as to my understanding this UI part should also be part of the microservice itself, right?
How would the UI integration work? Would I then have a 5th "front door" service that collects the user requests, forwards them to the other services which then answer with HTML/CSS and the front door service would then compose the individual responses into what is returned to the user?
Any chance, you have an example/use case for such a scenario?
Thanks and regards!
From my experience, in a microservices architecture, it is often useful to have a service that acts like an API gateway that front loads to the more domain specific microservices that does the work. The responsibility of the API gateway could be to aggregate results and return them to the front end but consolidating responses that are returned from the microservices would be coupling the knowledge of the two services and leaking some domain knowledge into the API gateway layer. The API gateway should probably be as thin as possible and should reach out to services to accomplish something.
The use case here that you're describing would be trying to authenticate the user before reaching out to the login service and then the article or comments service. Altogether the front end would still stay monolithic if they are a part of the same application.
If the application becomes big enough, the application would be separated by products but probably still rely on a core set of services. In that case, they would probably live in different UIs so that would make it less complex (kind of like microservices on the back end). Just as a side note, that a microservices architecture usually introduces a set of core services that can be utilized by different teams and therefore different applications that have different UIs. An example being an ecommerce application, that has customer service department editing orders for servicing customers and customers using an orders service to make purchases. In effect, these are two applications and they will have two different UIs. Hope this helps!
The other thing that I'd like to point out is that a microservices architecture is only great when the application becomes too large and complex. A microservices architecture requires more resources as it has some additional overhead. Start with a monolithic first :).
There are a couple of different approaches that you can take. If it makes sense each microservice can have its own pages that it can render. Then you only need a front end that can create the appropriate navigation for the involved services. The menu is built for the application, each service presents its own UI. This approach works well when you need to have the ability to include or exclude services from the application, for instance, based on licensing.
Alternately, each microservice can provide a set of HTML Fragments. Then you need a front end service to compose the pages and navigation. The fragments must all use the same vocabulary for CSS or whatever means you use to define the look and feel. This approach can lead to odd pages when HTML fragments are composed without one or more service that might be included.
Finally, a complete application UI can be built on top of the microservices. This can result in a "tighter" UI with a better flow. It also will typically take longer and be more difficult to change as new services are added.
What is the best? As with most cases in software development, it depends on what you are building. In the case of the Blog application, you described I suspect that each service could have its one full page UI. More commonly having a full UI is the approach I have seen. The HTML Fragment approach is more versatile but takes longer to develop initially. Once it is built though you will have more flexibility in how you deploy your application. This could be a real benefit for a Software Product company.
Hope that helps.
Related
I am new in Service Now platform, developing a custom app using the service portal and I am looking for some architectural advice from experts.
My storyline is my service is gonna serve different companies as per their requirements by easy codebase maintenance. for example, I am having a base app which has some concrete requirements that fit for all companies, but there will be some other features for company specific, like feature A for company A, feature B for company B and so on. So my initial plan was like classic software development that is to have a single codebase using git that will have multiple feature branches that will deploy to multiple instances. But sometimes some situation where I might need to merge the branches that is not possible now. My question here is there any alternative way to do that? Other possible scenarios here is should I go with a single instance with ACL based data separation? (but that not feels scalable to me cause the amount of the data will be huge after some time) or is that possible to apply regular SAAS architecture like multitenancy(single app with multiple databases) with some configuration wise feature separation?
Thanks in Advance.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 3 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Improve this question
We are on the initial stages of designing a micro service for my client from their standard monolith app that is sitting on 4 JBOSS servers in their own data center. Is micro service architecture target at only cloud based deployment? Can i deploy a micro service on premise production ready tomcat /JBOSS? Is that a good fit?
Sure you can.
Microservice architecture is a concept of having many small interracting components, where each of them performing well defined part of work, but good.
It's extention of the Linux way and the concept of decoupling components.
In your case you can split your service to several smaller services. Each one with own development and deployment cycles, each one with well defined API.
Is micro service architecture target at only cloud based deployment?
no it's is an architecture for application development. basic idea of micro services is separate complex application function to small functions to reduce complexity and get high performance.
there are few reasons you need to consider before moving micro services.
1.scale of you application.
if your application contain high number of complex functions its better go with micro services. and separate them and deploy separate, then easy to do changes and maintains.
2.performance of application
if some application function need high computing power. you can allocate separate hardware resources. if you implement it as micro services.
3.deploy and maintain
if you use micro services you can deploy and maintain service separate without effect other services.
4.data migration
if your databases contain high data table relation it will little bit difficult remove for function databases(each micro services need each DB) so as a first step keep DB as monolithic and separate function to services. then start to reactor DB
5.call each services
fronted end application keep clean and logic free. and wrap your micro services using API gate way and publish all the services as one service.
6.application security
each and every services running in separate no need to session tracking use JWT (oAuth2) API security.
7.multiple services & transnational
if you need to handle one business function but with more than one service you need to check each and every services function work correctly**(ex db operations ,rollbacks)** so need to developed transnational handler
implementing micro services
there is no specific technology stack for it but there are free more technology available
ex :
java spring boot for micro services (with inbuilt tom cat server )
zuul , eureka for API gate way
oAuth 2 and JWT for security
*Note
there is not fix way to implementation for micro services , use correct technology stack to get performance and implement small business function. and doesn't matter hosting in cloud or local servers.
strong text
There is definitely no limitations whether you deploy your microservices on local, physical servers or in the cloud. Both approaches are valid, but they impose different advantages and disadvantages.
With local/physical servers, you will have:
bigger operations overhead (it is better you have good DevOps in your team)
manual scaling (when you experience bigger traffic, you need to manually fire up new instances, or use some management tool for this)
manual fault detection - if a server goes down (this depends on your/company's server enviorenment) someone will need to fix this "manually"
it is cheaper (a friend is buying old server instances on Amazon and running their semi-microservice architecture on them, he calculated they achieve quite big savings this way)
With cloud infrastructure, you get some of the below advantages (in contrary to above disadvantages):
less operations overhead (the cloud will take care of most of operations)
flexible scaling (when your traffic goes up, cloud can automatically fire up new instances, when it goes down, it will shutdown instances)
error/fault handling - if there occurs a problem in the cloud, you do not need to worry
I did not mention all the advantages and disadvantages of given approaches, as it also depends on the project (will it receive different traffic on different times of day, does it need to keep data locally or can it be in a foreign country in a cloud, ...).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'd like to get peoples thoughts on a scenario I'm about to encounter.
I've been tasked with building a RESTful Web API Service that will be used by two client applications.
One client application will be a web application and the other client will be a mobile application.
They are two distinctly different applications that are targeting the same data-store. I imagine that a lot of the requests made by both client applications will be of shared interest.(They may want to receive slightly different messages back in terms of the model objects they request).
But ultimately there will be differences, and I don't want to expose parts of the service that are designed for an individual client app to all other clients.
I've been looking at Versioning with ASP.NET Web API, where i can create the same controllers multiple times and create custom constraints to controller selectors that switch out the controller depending on the version used in the URI.
Is this a good idea in my scenario, or should i really be building two API's, one for each specific client application?
First of all, if you want client A to access certain resources while client B shouldn't, you're going to implement authorization like OAuth2.
In the other hand, I doubt that the solution should be implementing 2 different APIs or overcomplicate the code of a single API to return the same response with some differences.
Furthermore, you can emit same DTO for both clients and map the generic DTO to a domain object or other DTO using AutoMapper in order to avoid the hassle to manually set properties from one object to the other.
Finally, you can also use an OData interface to your RESTful API to let the client decide which properties you want to return in your entities or perform other operations during the request and get just what you need in each case.
Conclusion/summary: you shouldn't adapt the REST API to your clients, but the clients should adapt themselves to how the API works. At the end of the day, you're returning JSON entities and you can map them to any class even if the structure is different using AutoMapper as I said in the first paragraph. You can even implement a custom serializer if needed. It will be less pain than duplicating the server code because some differences.
What would happen if you add a third client and says "I want also a different structure in returned entities", add even a fourth one! You're going to get crazy, aren't you?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
For people who follow the fairly new ASP.NET Web API, they know that it is a good framework for building well-designed and outwardly-facing HTTP services that can span across many different clients using standard XML or JSON content types.
I have been recently designing a large API to be used with both a web and mobile clients. I noticed that within the ASP.NET Web API template provided through Microsoft's NuGet packages for Web API, they take a very minimal approach into Views with a slightly pretty homepage.
This took me back in a way. Mainly because I would assume that the Web API is designed for exactly that, a Web API, and nothing else.
In other's opinions, is it standard to develop the web client (that interfaces with your API)
Inside the Web API project?
Or
Outside the Web API Project to separate the web client just as you would your mobile or desktop clients?
The second choice seems logical to me in ways of maintainability and code-cleanliness, but there may be other perspectives that could be beneficial when designing in ASP.NET Web API. What do you think?
Great to see you using Web API!
About your first issue, you're right that it conceptually makes sense to separate Web APIs from views. I'd recommend either using the "Empty" project type in the MVC new project dialog and then adding API controllers. Or adding the NuGet packages yourself to an empty web project. The packages shouldn't be adding any views to your project.
Concerning clients, I'd strongly recommend separating out a client library to a separate project for maintainability. It's fine to have common data types that you share between the client and the Web API though. In that case, it's a common pattern to move your models to a separate dll, and have both the client and the Web API reference the types in that library.
A couple reasons you'd want the client and the Web API to be separate (and there are many more):
If you distribute the library, you want to distribute the client code and not the Web API code
You want to create a clean contract between the client and the server and avoid having the client depend on the server implementation or vice versa.
I've been triying to migrate part of our soa architecture (Mule ESB) to microservices (Spring Boot stack), but I'm facing a problem related to large flows where we have several orchestations.
Basically We a have a flow which has an user id as input and the response is compounded of user account, creditcards data, stocks and loans.
In this flow we have, at the beginning, a splitter (allows to send concurrent requests) and we send requests to account backend, 3 different credicard partners, stock partner and loans partner, at the end there is an agregattor (wait to all responses and merge all of them) and finally a node for prepare the response (apply business logic).
During the migration we have developed an account microservice, loan microservice, stock microservie and creditcard microservices (1 for each partner). The problem here is the orchestation, We can't use and event model approach because we need to get all responses in a certain point. We considered the choreography approach too, but we don't want to add logic related ot how orchestrate calls to our microservices because that would be a stepback to heavy coupled services (N*N connections).
We are thinking on make a new microservice that will be used as an orchestrator, but we don't know if this will be a good solution for microservices concepts.
Note: The front end can't make the orchestrations because it is a closed product and we can't touch it.
Thanks in advance.
We are thinking on make a new microservice that will be used as an orchestrator, but we don't know if this will be a good solution for microservices concepts.
From all you described that sounds like the most reasonable thing to do. You describe this service as having its own business purpose which indicates to me the potential need for a dedicated service. And the fact that it requires input from other (more basic) services would not be unusual for a complex domain service. Also you already listed the alternative of aggregating on the front end as something that doesn't work in your domain.
Something to consider is just making sure that the development teams for the basic services treat their APIs as customer facing (with the customer being your other services). That means they have to do clean work in terms of versioning/deprecating/etc.
And the downstream services need to treat the consumed APIs like they would a 3rd party API. For example Google went so far to allow internal service consumption be charged real money to incentivize optimizing the implementation of dependent services.