I come across the URL - https://dzone.com/articles/quick-guide-to-microservices-with-kubernetes-sprin where both the controller and the service methods are exposed as REST API's
The confusion comes and it araises the question whether we need to expose controller methods as REST APIs or Service methods are APIS
if we made both of them as REST APIs then when we call a controller methods - 2 HTTP request might be sent and will cause performance issue.
Please advise.
The example that you're looking at is Feign, it is a declarative webservice client to make webservice calls easier between multiple microservices. Feign comes with GetMapping because its designed to work with other microservices.
In General, Controllers will have RequestMapping and handle the routing and service will do the work of running your business logic.
If we configure 2 RequestMapping it doesn't mean 2 HTTP calls will be made, only the ones with right url will be invoked and the other one will be a simple spring bean.
Related
which is better alternative for calling REST endpoint in springboot application, calling REST endpoints using WebClient or calling REST endpoints using RestTemplate ?
Spring’s documentation recommends using WebClient, but that’s only a valid recommendation for reactive apps. If you aren’t writing a reactive app, use OpenFeign instead. Like anything else in software, it fits well for some cases, but might complicate things for others. Choosing WebClient to implement the REST endpoint calls is strongly coupled to making your app reactive
RestTemplate gives many advantages if you are using it from within Springboot application, i.e. in your server side to another part of your own app - sort of like an internal call. Because the RestTemplate "knows" all your entities and beans and so if you need to send over or receive an object which is known within your springboot application RestTemplate can map them automatically which is a very nice advantage. If you sending a request to some third party api and do not pass or receive your known entities RestTemplate is still a valid option but it just becomes just another Http client. Its just simply there as part of Springboot provided tools. But in this case you may use any other client as well.
I have a spring application. It exposes an endpoint, which when hit, needs to make an call to some other API. So, where should I make this API call, inside my controller itself or should I do it in the service class?
Based on any Architectural style (DDD, Microservices, etc), we should follow separation of concerns.
Best practice would be to create a Rest Client class for the API you want to consume and make all rest calls inside that.
Then you create a Service class to call the method consuming the API, performing the operation, data filter, anything you want to do with data.
Next would be to inject your service class inside the controller and return the data you just consumed and did some operation on it.
It might not sound well in a small project/feature, but it is the best practice when things get complicated and grow.
I have an application which looks like this
Now, whenever a request is received at the gateway, Zuul filter AuthorizationInterceptor gets invoked which does authentication/authorization by making some calls with User Service. If the authorization succeeds then actual microservice is called.
Now the with the new requirement, I need to write some aggregated API which takes data from two services and combine the data. So I added #RestController on Gateway Proxy but before that rest controller gets invoked AuthorizationInterceptor is not getting invoked. How can I tell ZuulFilter to get invoked even when the request is locally served.
Is there any solution for this? Should this be architected in a different way?
I don't think it's a good idea to put this kind of logic into the gateway service.
What you are referring to is an aggregator service which can be after the gateway as the other two services but instead of storing data or doing some business logic, it just takes the data from the two other services and aggregates them. This way the AuthorizationInterceptor will be invoked on the gateway level as well.
Another hacky approach would be to create a custom ZuulFilter which handles an imaginary endpoint call and aggregates the data. This way your AuthorizationInterceptor will be called as well but it's not a good idea to put this kind of logic into your edge service.
We are writing a mostly single-page, client-side app, but server-side/DB endpoints are still required of course, so the natural choice is SpringMVC (since we are a Java / Spring shop).
But this got me thinking why we need the cluttered, very old design for this app:
- Controller layer
- Service layer
- DAO layer
This app is mostly just the client side making AJAX calls with JSON for DB retrieval/persistence. Do I really need to go thru the Controller layer to receive requests, then invoke a Service method, which in turn invokes a DAO method?
At the same time, I don't want to write a REST Service because it could result in overhead and we may not support all of the REST requirements... but is it the right choice here? If I understand correctly, I would still need a RESTController on the presentation layer?
My goal is to just directly hit a Service method or, maybe even more directly, a DAO method. Is that how modern apps are written?
You cannot hit a DAO unless you expose it through an API of some sort that can be invoked remotely by the UI application; as a consequence, you need to write a service.
A convenient way of exposing a service is to either:
Use Spring MVC and use the controllers as stateless endpoints that provide a JSON/Protobuffer/XML sort of payload that is then parsed by your API (with JSON being the simplest option of them all, perhaps) or
Use Spring Boot, which uses Spring MVC under the hood.
Hope this helps and good luck with your project.
I'd like to call methods of my DAOs by AJAX. I'm quite new in that so I would like to ask what is the best way to do that. Is it possible to publish my beans as web services and call them with e.g. jQuery? I think it is not possible :) I've also read about Direct Web Remoting but I don't know which way to go...
As I see, there are lot of experienced guys here so I think you can show me direction.. thanks in advance
Rather than exposing your DAO beans directly, you should create some Spring MVC controller beans, and call those from the client-side (using AJAX). Ideally, the controllers should not call the DAOs directly, but should instead call service beans (and the service beans should call the DAOs). One advantage of this approach is that you can define your service methods to be transactional, i.e. whenever a service method begins a transaction is started, and whenever a service method returns (without an exception) the transaction is committed. If the boundaries of your transactions are your DAO methods then it is not possible to wrap several database calls in a single transaction.
Of course there's no reason why you need to use Spring MVC - any web framework would suffice.
You have to expose your DAO's or beans by means of http. Typically you create a layer above the DAO layer to expose your services through HTTP, which are available to any AJAX framework such as jQuery. What jQuery and other frameworks ends up doing is using a special asynchronous request called XMLHttpRequest and then parse the server response (can be anything, pure HTML, JSON, XML, etc) and process it.
Here's a link I found that shows Spring & DWR with AJAX: Bram Smeets Blog.