I want to introduce the new service in our company application which will ease some load of monolitic app. The specific of new service is that it will in scope of each request make a lot of http calls(simultaneously as well) and compose obtained data to make new calls. The question is: will I benefit from using Spring WebFlux here provided the rest of the services are synchronous(and backpressure I assume won't work)? Does it make sense at least in terms of resource consumption not to be blocking?
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 system (kind of aggregator) that integrates with hundreds of different SOAP services - most of them do the same business functionality, but each service having different data structure in SOAP request & very few having 2 API calls to complete one transaction.
The present service integration workflow is
create stubs from WSDL
map data to the generated stub api
setup a new endpoint to fire this api
I see this a repeated, unintelligent work & requires development effort for every new service integration.
Was there different approaches to integrate with lot many systems? Any libraries that can generate soap requests based on configurations, or I have to rely on some Java SOAP, Spring lirbaries to create custom SOAP xml request from my own configurations? I see Spring's WebServiceGatewaySupport for webservice client but requires stubs created from wsdl?
Is it wise to define soap request xml as templates for every service, generate xml with input data?
Other ways I thought was to develop each integrations as independent microservice layered under an API gateway that routes each requests to specific service. But this design approach will have hundreds of services running, consuming more resources (in case of Spring boot).
Generate stubs & deposit the jar to disk, load this jar with a classloader & use the stubs using reflection - not so simple, I believe.
Use of serverless looks promising but is not possible immediately.
I get that Feign is declarative and hence it abstracts out a lot of things for the developer. But, when should one choose one over the other? Though feign is declarative, it has serious problems with oAuth. What are some of the considerations in using RestTemplate over Feign
Feign allows you to abstract the mechanics of calling a REST service. Once you configure and annotate the Feign interface, you can call a REST service by making a simple Java function call. The actual implementation of making a REST call is handled at runtime by Feign. This means that the implementation can be configured without changing your business logic code.
By just changing the Feign configuration in Java or using properties you can add encoding/decoding, logging, and change the REST call implementation library. All this is done through configuration only, while the business logic that calls the service remains unchanged.
Since Feign uses standard Java interfaces, it's also easy to mock them during unit tests.
There are certain advantages.
1.URLs are not hardcoded.
2.you don't have to write unit test cases for feign as there is no code to test however you have to write integration tests.
3.we can use Eureka Client ID instead of the URL.
4.Feign handled the actual code.
5.Feign integrates with Ribbon and Eureka Automatically.
6.Feign provides a very easy way to call RESTful services.
One of the advantages of using Feign over RestTemplate is that, we do not need to write any implementation to call the other services. So there is no
need to write any unit test as there is no code to test in the first place. However, it is advised that we write Integration tests.
Using Feign-clients over rest-templates has number of advantages. I will list down those below.
The developer need not worry about the implementation. Just to create abstract Feign interface and few annotations - declarative
principle. (If you want customized configuration, then it will hold
some code)
With Spring Cloud Eureka, Ribbon client-side load-balancer will be equipped with Feign client.
No need to worry about the unit test, because there is no implementation from you to test. (Arguable)
Supports Feign annotations and JAX-RS annotations.
Highly compatible and easily configurable with Spring Cloud (Specially with Eureka server registry)
Allows Feign client configuration via #Configuration class or application properties.
Allows us to add interceptors. (Add interceptors via #Configuration or application properties. Alternatively can use
Spring Cloud provided interceptors as well. Example -
BasicAuthRequestInterceptor)
Hystrix support for fall-back mechanism.
Logging
Error handling
Feign is a good choice, If you are fascinated with JPA and the way how it resolves your queries, then Feign is the tool for you. Feign will handle your server requests perfectly fine.
RestTemplate is used for making the synchronous call. When using RestTemplate, the URL parameter is constructed programmatically, and data is sent across to the other service. In more complex scenarios, we will have to get to the details of the HTTP APIs provided by RestTemplate or even to APIs at a much lower level.
Feign is a Spring Cloud Netflix library for providing a higher level of abstraction over REST-based service calls. Spring Cloud Feign works on a declarative principle. When using Feign, we write declarative REST service interfaces at the client, and use those interfaces to program the client. The developer need not worry about the implementation ...
Advantages of using Feign over RestTemplate:
Declarative approach: Feign provides a more declarative approach to define and use REST API clients, which can make the code more readable and easier to maintain.
Integrated with Eureka: Feign is integrated with Netflix Eureka for service discovery, making it easier to build and consume APIs in a microservices architecture.
Better error handling: Feign provides better error handling, including support for custom error handling and retries.
Support for multiple encodings: Feign supports multiple encoding types, including JSON, XML, and form data, while RestTemplate only supports JSON and XML.
Disadvantages of using Feign over RestTemplate:
Limited flexibility: Feign provides a more opinionated approach to defining and using REST API clients, which may limit flexibility in certain situations.
Limited control over HTTP request and response: Feign abstracts away some of the low-level details of the HTTP request and response, which can make it harder to control and customize these details if needed.
Lack of official support: Feign is not an officially supported library from Spring, which may be a consideration for some developers or organizations.
We have developed a software proxy based on spring boot and zuul, that is meant to govern services within our integration layer. We do not own the systems consuming the various services, nor do we own the actual services themselves. The services are SOAP based webservices at present. We make use of pre, post , error and route filters. Validations are database driven, including which client is allowed to call what webservice. All service definitions reside in the database (request endpoint, request xsd, response xsd, which clients are allowed to invoke, etc.).
The aim now is to add hystrix commands to handle service failures, as well as a hystrix dashboard.
The standard way to use hystrix commands involves annotating service methods with javanica. Is there a way to dynamically declare/register hystrix commands for these webservices at runtime after reading the configurations from the database? The hystrix interception will need to happen based on the multiple webservice endpoints being invoked from a single point.
Hoping this is achievable ...if not, I would really appreciate any alternative proposals for how hystrix commands could be declared in this way.
Thanks!
You're saying that you are already using Spring Boot and Zuul. How are you mapping the routes? Through the url param? Then you'll have to enroll your own. But if you define the routes as ribbon services and pass the routes as ribbon servers as described in the documentation you will get Hystrix for free.
I'm trying to learn SI (Spring Integration) but i'm a bit confused on the real usage of this.
As first example i would like to interact with a WebService but i dont understand what could be the difference from
Invoke a WebService Using SI
Invoke a Webservice using RestTemplate
So, what is the benefit of using SI (in Webservice context, or in other context)?
Looking the web, i havent find an article that explain:
Usually you will do in this way....
With SI you can do better - in this another way - and the benefit are....
To be more explicit on what i have to realize, this is an example:
1) I have to write an application (Standalone application) that have to collect some data in the system periodically and then invoke a Web Service that will store it.
2) The Web Service receive the call from the "clients" and store in the database.
My webservice will use REST.
The reason because i've think to use SI is that the Standalone Application should interact with different system
Webservice in first instance
A Web Mail, if the webservice is not achievable
File system if Web mail is not achievable too
If you only need to pull some data in a simple way and push it onwards to a REST service this does not "justify" the use of Spring Integration. A simple Spring (Boot) application combined with a scheduler will be sufficient.
But if you want to use a more complex data source for which an endpoint is available, you need transformations, complex and flexible routing is a high priority or even Enterprise Integration Patterns (EIP) then Spring Integration is for you. Have a look at the Overview and decide if it mentions something you consider as valuable to you.
Perhaps you will create additional value by mixing in Spring Batch if you need to process a lot of data.
But as I understand your current demand starting with just a RESTTemplate should do for the moment. Starting small will not prevent you from switching to Spring Integration later on.
Have a look at the various tutorials and guides provided by the Spring Boot project. There is even an example for Spring Integration.