I would like to know if it's possible to create a spring boot microservice between an old java 1.8 monolithic API and a Spring Boot Backend (React for the front but it doesn't matter).
Here is the idea:
RestController inside the monolithic API ---> Microservice (Springboot) ---> Back API (Springboot)
For the use case:
Click on the button of API A
Binding data to the RestController of the API B
Send the same data to an API C
I don't think it's possible through a RestController due to the Cross Origin but it could be great to find a solution.
What do you think?
TL;DR Assuming these are all synchronous remoting calls I think this should not pose too many problems, apart from maybe latency if that's an issue and possibly authentication.
The RestController in your Monolith A can call the REST API implemented by your Microservice B as long as it can reach that endpoint, and knows how to map/aggregate the data for it. The Microservice B can in turn call your Back API C.
I assume the calls will all be blocking, meaning each thread processing a request will be paused until a response is received. This means that the call to A will have to wait until B and C are all done with their processing and have sent their responses. This can add up (especially if these are all network hops to different servers). If this is a temporary set up to apply the strangler pattern to part of the monolith then the latency might not be an issue for the period in which calls are still routed through the monolith.
Cross origin resource sharing (CORS) is only a concern when retrieving content from a browser window as far as I know. In the described situation this should not be an issue. Any client calling Monolith A will not be aware of the components behind it. If one or more oof the three components are not under your control, or not managed/authenticated in the same way then you might run into some authentication challenges. For instance, the Microservice might require a JWT token which the Monolight might not yet provide. This would mean some tinkering to get the components to become friends in this respect.
Strangler pattern
Related
In my current situation, the frontend client is making an api call to a backend endpoint (java) at a 15 second interval to see if a resource exists. The resource will be created through some business logic. Once the resource exists, client will get the data from api and process it.
However, it seems that it is a costly performance and not scalable to call an api every 15 seconds. I was wondering the best practice for this - the client waiting for a resource to exist to execute some logic.
Is there a way / best practice to send/push data from the server to the client rather than the other way around as well as being unidirectional (server -> client)..
Thank you in advance.
In order to solve this properly you will need to implement WebSocket.
The Request from the client will be a GET and the server will approve it with 200 status code to confirm.
Then ,when the server will done process your request , it will broadcast the data via the websocket directly to your web application.
Is there a way / best practice to send/push data from the server to the client rather than the other way around as well as being unidirectional (server -> client)..
What you've just described here is known as the observer pattern. The whole idea of it is to have a list of observers attached to observables and push notifications each time the state of observable changes.
You could implement this pattern in your Java back-end by exposing a subscription endpoint in which you'd specify what you want to observe, along with what URI to call back in case there's a state change, or some other mechanism for pushing server notifications. However, you might have to solve another problem which is having your "client" act as a server, permanently or temporarily, for these notifications, if you want to avoid periodic API queries.
Obviously, you want to have an 'unsubscribe' endpoint to free resources. You might have to consider what to do if the client unexpectedly loses connection or is not engaging for some other reason (some time-to-live for subscription sounds like a good idea here).
On most of the resources on google, I see one of the major advantage of graphql is said to be its ability to be as aggregator service but I did not find any concrete example how it is different from other http endpoints(or Rest endpoints) ?
My understanding is that in case of GraphQL, there will be single http endpoint for everything. Then graphql server will determine which particular
data fetcher will be called. That is provided in very configurable way.
But in case of other MVC based architecture or rest based architecture, end points are separate for each request and then the flow start.
So in a way graphql provides the single entry point(or we can say address) for each request then graphql take care of further branching, but in other above
mentioned architecture there are separate addresses(or endpoints) for resources/request. Is it because of this reason we say graphql can work as aggregator service or is it something else ?
The GraphQL's main advantage is to provide to the client ability to query everything (objects) it needed and display it to user without discussing/creating specification for every request/response in the application. And in some cases clients need different responses for the same request (eg views might look differently for web and mobile clients).
I believe you can create multiple GraphQL endpoint in your application based on context of your domain, but it might be misleading in most cases.
I am a jr.dev and have worked with Spring Boot in different projects, mainly for creating server/client where client sends some stuff to a server, the server then calls external API's to reflect changes on the clients side.
In the future I will be involved in creating a backend for a administration portal. On this portal, there might be up to ~100 users making changes at the same time. With the aformentioned server/client systems, updates were infrequent so performance was not prioritized, however, if 100 users are on this administration portal at the same time the user experience may be poor.
Structure of what I am building:
Client (browser) CRUD -> my backend -> 1-3 external API calls to locally hosted services.
And this is where my lack of Spring's Resttemplate is lacking. If 10 users make a request roughly at the same time, the RESTcontroller will try to execute the corresponding code for the 10 requests at the same time, BUT since the code is using Resttemplate to do external API calls, will each RESTcontroller "thread" have to wait for their turn because Resttemplate is synchronous? - In turn making the last RESTcontroller request having to wait for possibly 10-30 Resttemplate calls to the external API, which take roughly 30ms each.
Is there a better way to handle it? So that each request to the restcontroller can contact the external API without having to wait for another thread to free up Resttemplate?
I might be talking gibberish, I find it's very hard to google specific questions about Spring/RESTcontroller/Resttemplate's structure, whether they are asynchronous/synchronous etc..
I am presently working on an application which has an external dependency on micro-services, there are around 25 microservices, which are administrated via a eureka instance, every microservice has around 3-4 controllers.
This is an external dependency for me and blocks my work if it goes down, also I am unaware of the code ad logics for these microservices.
Currently, I am looking for a solution which can act as a simulator for these services in there absence, some application which can intercept and log, all the request and response to/from the external services, and in absence of these services it can match the last response to a requests from log and provide that response.
you should check mockito or any other mock framework
just record and serialize the result e.g. with xstream and respond with the deserialized xstream result and modify it slightly by your needs.
This is the quickest solution for mocking remote services.
I'd like to synchronize the state to all the clients interested in particular entity changes. So I'd like to achieve something like:
exposing CRUD API on entity (via HTTP/REST and websockets)
and routing the response (of the modifying calls) to websockets topic
So technically, I'd be interested in ideas to mix spring-data-rest with spring websockets implementation to achieve something like spring-data-websocket.
There are a two solutions coming to my mind, and in fact both would be:
spring-data-rest to expose my entities via REST/HTTP API
websocket controllers (used for the modification calls on entities)
The websocket controllers would look like this:
#Controller
public class EntityAWebSocketController {
#MessageMapping("/EntityA/update")
#SendTo("/topic/EntityA/update")
public EntityA update(EntityA entityA) throws Exception {
// persist,....
return entityA;
}
}
Scenario 1: Websocket API called from REST/HTTP API
Rules:
client request is always REST/HTTP API
response is REST/HTTP API for all the operations
moreover for modifying operations the websocket message comes as well
Technically, could be achieved, by:
calling the websocket controllers from the spring-rest-data events (namely in the AfterCreateEvent, AfterSaveEvent, AfterLinkSaveEvent, AfterDeleteEvent)
Still the solution seems quite sick to me, as I'd need to go for:
client A --HTTP request--> Server (spring-data-rest controller)
Server (AfterXXXEvent in the spring-data-rest controller) --websocket message--> Spring websocket controller
Spring websocket controller --websocket message via topic--> all Clients interested in the topic
Server (spring-data-rest controller) --HTTP response--> client A
Scenario 2: Websocket API independent from REST API
Rules:
client request is REST/HTTP API for non-modifying operations only
response is REST/HTTP API for non-modifying operations only
client sends websocket message for all the modifying operations
websocket message is sent to client for all the modifying operations only
Well, if no other ideas come up, I'd go for the later one, but still, it would be great if I could have somehow generated C(R)UD methods exposed via websockets as well, something like spring-data-websockets and handle only the routes in my implementation.
As I feel like I'd have to manually expose (via *WebSocketControllers) all the CUD methods for all my entities. And I might be too lazy for that.
Ideas?
Scenario 2 talks about, in the last step, a single client.But I thought your requirement was for a topic since you wanted multiple clients.
If I wanted to complete 2 for your stated requirement, then you might want to maintain a list of clients and implement your own queue or use a ForkJoinPool to message all your clients listening in on your WebSockets. Having said that, A topic is definitely more elegant here but overall looks too complicated with different interfaces
For all messages from client to server, just go with a simple wire protocol and use a collection to parameterize, it could be
RParam1.......
At the server, you need a controller to map these to different requests(and operations). Somehow does not look like too much work.
Hope this helps.
The same architecture has bugged my mind for a while now and it will be a long story if I want to mention all the drawbacks and advantages of it so let me jump into the implementation.
The second scenario is valid, but as you mentioned its better to perform the crud actions on same websocket session. This shall remove the need for HTTP handshakes on every request, and reduces the body size of messages, therefore you will have better latency. Meanwhile, you already have a persisting connection to a server, so why not make good use out of it?
I searched around for a while and after 6 years from your question, I still couldn't find any websocket protocols that can make this happen, so I decided to work on that by myself cause I needed it for another dummy project.
Another advantage of such protocol could be that it doesn't require much changes to your already written controllers. So it should be able to support Spring Framework (for example) annotations and make websocket endpoints out of it.
The hard part about implementing such protocol in another framework like spring is that as its not nice to create ServletRequest and ServletResponse and convert them to your own websocket protocol, you loose some advantages. For example, any http filter you have written in your application till that moment, will be meaningless because its not really easy to pass your websocket messages through those filters.
About the protocol itself: I decided everything to be passed through json format, alongside a unique id for each request so we can map callbacks on client side to the request id. And of course there is a filter chain to add your filters to it.
Another hard to deal thing here is Spring Security as that too works like http filters in some cases. In my own lib I could finally handle annotations like #PreAuthorize but if you are using antMatchers in your HTTP Security Config, it would be a problem.
Therefore, creating websocket adapter to call http controllers will have many drawbacks.
You can check out the project here: Rest Over Websocket. Its written for Spring Boot.