I have a Spring boot 1.4.3 project. Recently I have come up with a requirement where I have to send logs from server to my web application and print the logs on the web page. I am aware of WebSockets but I was looking for better solutions and I came across, Reactive Programming and gRPC.
Spring is supporting Reactive Programming in Spring version 5, but I am quite confused between gRPC and Reactive Programming. gRPC features Bi-Directional streaming which is built on top of Netty and provides the same facility as pushing data from the server to clients like Reactive Programming. So which one should I use, If you can clear me on this confusion it would be really great.
Also, If I move to Spring Boot 2 which supports Spring Version 5, the project will be running on Netty. My confusion is, do I have to run my application on different containers like for normal REST endpoints on Jetty server and for Reactive API on netty server or Spring will handle this for me out of the box by handling reactive requests on netty and remaining general REST API on the jetty server, because as far as I know Netty is not a Servlet Container.
One key feature of reactive programming is back pressure, and back pressure that's implemented in a non-blocking manner. At the time of writing, gRPC doesn't support this.
There's also much more to reactive programming than the communication between a client and a server. To be truly reactive, you need to be reactive from end to end. This includes reactive access to your data store, etc. As far as I know, this isn't something that's tackled by gRPC.
You shouldn't try to mix the use of a traditional Servlet-based web framework (such as Spring MVC) with use of WebFlux (Spring's reactive web framework). You should either write a 100% reactive web application or a 100% Servlet-based web application.
Related
I have several apps developed using spring boot. Some apps call another apps, that in time call other apps, it is getting hard to manage and scale. I need to be able to distribute them in a network and also combine the apps in different 'flows' with minimun changes to the apps.
Ideally I would like to wrap the apps and abstract them into components that have N inputs and M outputs. At boot time I would use some configuration to wire the inputs and outputs to real kafka topic queues.
For instance, input A to an app can come from several kafka topic queues, and the output B from the same app can go to other set of kafka topic queues.
I would like to be able to change the queues without having to recompile the apps, also no extra network hops to send/receive from/to multiple queues, this should in the same process and multi threaded.
Does anybody knows if something similar exists already? Can spring integration do this? Apache Camel? Or am I better off writing it myself?
See Spring for Apache Kafka. There is also a spring-integration-kafka extension that sits on top of spring-kafka.
The Spring for Apache Kafka (spring-kafka) project applies core Spring concepts to the development of Kafka-based messaging solutions. It provides a "template" as a high-level abstraction for sending messages. It also provides support for Message-driven POJOs with #KafkaListener annotations and a "listener container". These libraries promote the use of dependency injection and declarative. In all of these cases, you will see similarities to the JMS support in the Spring Framework and RabbitMQ support in Spring AMQP.
I am trying to build a new application with spring boot microservice framework. I have tried some demo. The existing demo is too simple, doesn't introduce how to call another service from one service. Should still going through http, or should going through RPC? If going RPC, which RPC framework support?
The way of integrating among services depends on numerous factors, like synchronicity/asynchronicity, load that will be generated, etc. The most popular (I guess) way of integration is REST-based one. Because you tagged your question with spring I would recommend using declarative REST client - Feign that is very well described here. You can use message brokers as well, which are also very well abstracted by Spring Cloud Stream - you can read more here. I think that more in depth discussion should be based on your needs.
If another micro-services are exposing the REST API , then you can simple use jersey client
or httpclient to call them.
I have two spring boot apps running in the same local network and they need to communicate with each other. An obvious answer is to leverage REST API and make http calls, but I would like to use Spring Integration project for this purpose.
That said, I have several architectural questions regarding that:
Should I setup a standalone messaging framework (e.g. Rabbit MQ) or embedded should also work (e.g. messaging will be embedded to one of the two apps).
If standalone, what messaging framework should I choose: ActiveMQ, RabbitMQ or something else?
Welcome to the Messaging Microservices world!
You go right way, but forget the embedded middleware if you are going to production. Especially when your application will be distributed geographically.
So, right you need some Message Broker and that should be definitely external one.
It's really your choice which one is better for your purpose. For example you can even take into account Apache Kafka or Redis.
If we talk here about Spring Integration it might be better for you to consider to use our new product - Spring Cloud Stream.
With that you just have your applications as Spring Boot Microservices which are able to connect to the external middleware transparently for the application. You just deal with message channels in the application!
I have a Spring web application and an standalone application written on C#. Only Spring application has an access to DB, so I want to implement data exchange between Java and C#. The data isn't large (100KB / Min or so). Application will be placed on the same machine. What is the best way to integrate a communication? Does Spring Framework has a module to work with?
Spring certainly does have a module for doing this, it's called Spring Integration. You can define inbound and outbound channels/gateways and before the data comes in or out do any transformation on it needed to get it in the right format. Pretty standard functionality for doing enterprise integration.
Alternatively if that's too heavy weight you could expose a RESTful webservice in the spring application using the #RestController annotation and call that api from C# application. Another alternative would be to expose a spring-ws Web service in the spring application and write a Soap client that calls it in the C# application.
I have my web application written in Spring MVC. It is quite simple app for registering some activities and generating reports after some time. Now I have it done fully in Spring. The only entry point is HTTP webapp request. I'd like to add other entry points to allow user to trigger application via JMS queue, FTP files and SOAP-based web service.
I know I can do this all using Spring own features somehow, but I wonder if it is desirable to involve Apache Camel into all that stuff?
I think about leaving web application as it is (communicating directly with services), only add some Camel magic to spring context and expose several endpoints from Camel and then after messages processing and transformations call existing services.
I think about using Camel to be able to use some asynchronous processing and threads/scalability features. Is it the right way to go?
I will recommend you to use Apache Camel. I have used it for a similar purpose. The solution is an appropriate one from a 'Separation of Concerns' point. Camel implement Enterprise Integration Patters and is a better solution for integrating various protocols and interfaces. Your application should deal with functionality only and as designed should just expose a servlet to get requests and process it.
Handling of interfaces and protocols are well structured in Camel and its easy to maintain and configure in the long run.