Slowly but surely I adopt microservices approach. So I created some microservices always returning json.
But now I was thinking to convert a monolith into microservies. I noticed every endpoint returns a html page, namely a string interpreted by Thymeleaf as a html page.
So how can I transform that to microservice ? Should the service still return this html page ?
Microservices Architecture is an architectural style that structures an application as a collection of services. In other words, it's something like separating the big system we have into subsystems that connecting and calling each other.
So, each microservice has system internal calls (microservice calls another one) and external system calls (call from a user through his web browser). Microservices call each other using APIs. But when it comes to the external calls, it might respond with a JSON or HTML as you like as any normal system.
Related
To which part of the MVC pattern belongs an API? Am I right with the assumption that it belongs to the view?
I'm talking about an application which provides an API to access data from the model.
Then these are conceptually different things. You are offering an API on your server (let's assume REST based); the API here is your server and the software which runs on it. That software may internally be built using an MVC pattern. An API request is handled by a controller, a model, and the response is output by the view. An API request uses all three parts of MVC. "The API" is what your software looks like "from outside".
If you consider the server you are connecting to through the API as a data storage, the API is a layer between the data storage and the controller/view.
In MVC architecture, the model contains a data storage with a service that controller or view can access to obtain the data.
In this case, API is the service, so I would say it is part of the model.
I have a Typical SOA web application which has the following components as expected.
The Web Client - Sprinv MVC
SOAP Services - Spring
The Reference Data is centralized which is exposed thru its own SOAP Services.
The SOAP webservice responses have codes for elements(like CountryCode, CityCode etc).
I need the suggestions as to what should be the best approach to for ex display the Country Description instead of the country code (which needs another SOAP call to reference data and same with other codes) on the web page ?
Few options are like:
Write a custom tag library which would do the necessary calls and get the data.
Fetch all the ReferenceData descriptions and put it into some kind of HashMap, add it to the model to be consumed by the web page.
Any other better ways please advice.
Since it's reference data, no one expect it to change very often, right? Retrieve them once and serve them up using #ModelAttribute. See here.
Spring MVC is still server side, so it can handle very large data e.g. all the street addresses in US. You simply need to make sure you add some sort of filter if you don't want to serve the entire collection. And simply partial update these reference data with the latest on regular basis.
I'm working on a web application that need to expose Json API for external apps and I'm planning to do an API centric architecture.
So basicly, the app will juste contains view/controllers for the web interface. the controllers will use Route::dispatch to create a request to the api part of the site (another controller in a package, but in the same laravel installation), then parse the result, and create view accordingly.
So I'm wondering what are the drawbacks, performance wise, of using this sort of architecture?
If each controller is writing the logic to internally dispatch another request then I'd consider abstracting that away from the controller and in to your own dispatcher. I doubt there would be a huge performance overhead. The application (as far as I know) doesn't get booted twice so you don't have to worry about that.
The only thing you need to be aware of is the input for the main request being used. Something you should take into account inside your dispatcher. Refer to this answer for more information.
You can also read more on consuming your own API.
I'm trying to learn web development.
I understand (mostly) the concept of MVC, but I'm confused about why an MVC model is used on the server side...like Spring MVC. Isn't the server side the Model and Services, and then the client side Services, View, and Controller (AngularJS even makes that pattern explicit on the client side)?
I'm really struggling with how the MVC model fits into or facilitates server-side development.
MVC is a pattern used by much more than just web applications. Any app with a UI could use an MVC pattern.
The idea is that you have a View (html, or a window in your OS, or even a report or something), and you have a model that represents the dynamic parts of that view. Then you have a controller that is dedicated to processing input and doing the "business logic" to generate the model and apply it to the view.
So.. for example on the Server you might have this MVC pattern:
A controller receives the HTTP request and processes it.
It builds a model
The model is applied to a view to generate HTML and send it back as a response.
On the client it will be similar (but a bit different in Angular's case):
A controller is used to determine and manipulate the model.
The model is then bound to your view via directives. (Angular is really more of an MVVM pattern, but it's similar enough)
The view is similarly bound to your model via directives. (this is where the MVVM part comes in).
The idea here is that both the model and the view are kept up to date by directives.
The controller just contains "business logic" for manipulating the model.
Clear as mud?
No worries. Just know this: It's just a common pattern. It's not "server specific" or "client specific". It can be used anywhere by anything requiring data to be scrubbed into templated output.
EDIT: More thoughts.
In the case of a Web API that serves up JSON (or even XML) on the server, you're still using MVC in most cases. This is because what you're doing is:
Process the request in a controller.
Build up the model in the controller.
Render the model to a "view", which in this case is a view that serializes it out as JSON.
In the good ol' days of yore, the client side was only a display. The server was responsible for communicating with the model, applying business logic, generating a view, and sending the static, rendered content back to the client (browser).
As the web matured, some of those responsibilities migrated from the server to the client. Now, the server-side is often a thin layer like RESTful API that stores the "official" business logic (rather than convenience logic on the client) and stores the model. But for performance and user experience, the client now stores a copy of the model in its own model layer, communicating with the server and/or local storage as necessary, and having its own controllers and view logic to provide an awesome user experience.
So does MVC still apply on the server? Yes! It's just different. The server often generates the initial view from which the client-side application runs (taking localization or internationalization into account, for instance) and still houses the official model. But more importantly, the "view" in MVC just changed. Instead of the server-side view being HTML, it's now JSON or XML that the client application consumes instead of just renders.
So for functionality's sake, we still use MVC on the server. But for an awesome user experience, we use MVC on the client-side now too.
We are in the process of designing/creating restful web services that will be consumed client side using XHR calls from various web pages. These web pages will contain components that will be populated by the data retrieved from the web services.
My question is, is it best to design the return data of the web services to match specifically what the client side components will require for each page? Therefore, only one XHR call will be required to retrieve all the data necessary to populate a specific AJAX component or to update a specific page. Or is it more advisable to develop generic web services, that match for instance a database schema, and will require multiple XHR calls client side to retrieve all the data to populate an AJAX component? The second approach seems to lead to some messy coding to chain calls together to retrieved all the data required before updating an AJAX component.
Hopefully this makes sense.
You should always design services based on what they are to provide. Unless you need a service that retrieves rows from the database, don't create one. You may find you need a service that returns complete business entities - they may be in multiple tables.
Or, you may just need a service to provide data for UI controls. In that case, that's what you should do. You may later find that two operations are returning almost the same data, so you may refactor that into one operation that returns the data for both.
My general rule of thumb is to do what ever is the smallest to transmit over the ajax call. In theory, the more data that is sent to the client the slower the update process. This, of course, would necessarily mean specific services for specific pages.