I was curious how SSE works with microservices, if it's not interval based?
Suppose I create an SSE endpoint at the request controller, and have a microservice for handling notifications. A notification gets created at the microservice, how do I trigger the SSE endpoint based on that? how do i make it to listen to the microservice?
Related
I have two Ionic applications, and both use the same API served with node. What I need is that when one app sends a post request, the other app gets that post request and uses the information that comes from the request. How can I achieve this? I thought of listening for that particular post request, but I don't know if that's possible, or when the post request reaches the API, trigger some action in the server that sends the information to the other app. Is this possible?
You can use Firebase Cloud Messaging to implement this.
When one ionic application requests a service from your server by using HTTP Requests, the server will trigger the respective action and sends a push notification to your other app by using the Firebase cloud messaging service. Your 2nd app will capture this push notification by subscribing to a URL in Firebase.
For the server-side, You can use fcm-node module or Firebase NodeJS Module to implement this functionality. For the mobile app, you can use providers in ionic to subscribe to firebase cloud messages
A detailed guide on implementing push notifications can be found here
There's an external REST api that I'd like to use, but they don't offer a websocket api so I was thinking of making one myself using their REST api.
What I was thinking of doing is creating a websocket server, then making a GET request to the REST api every minute or so within that server, and then send the response to my frontend using websockets.
Is there any reason this wouldn't work, or is there a better way of accomplishing this?
I'm trying to build a microservice architecture. I've learned some benefits of API gateway like: load balancing, invoking multiple microservices and aggregating the results, cache management etc. So I decided to include it in my system.
My question is whether I should implement authorization in gateway layer or separately in each microservice endpoints ? For example authenticating user on gateway and passing user claims in decrypted form to be used in authorization logic to each service call ?
It seems like it make sense and saves processing time to authorize some aggregates before even calling each service. However, authorization logic is really a concern of individual service.
What is your advice ?
each microservices endpoint. implementing the authorization in API gateway will make your system rigid. If at any later stage you have to separate logic for authorization (say, internal user, external user, open api). This will be very difficult to incorporate.
Authorization should happen at each API level.
You can use API Gateway Pattern / API Gateway. Then you can also offload the authentication/authorization responsibility of the microservice. It will be easy for user or developer that is calling the services. API GW support External /Internal GW even. It may support Role base permissions. eg: WSO2 APIM.
You will get below advantages when you have API /MS GW:
An API Gateway is the single point of entry for any microservice call.
It can work as a proxy service to route a request to the concerned microservice.
It can aggregate the results to send back to the consumer.
This solution can create a fine-grained API for each specific type of client.
It can also convert the protocol request and respond.
We are currently working on a nodejs application which hosts API's (includes both get and post HTTP methods). These server API's in nodejs server are individually accessible or allowed to be called. Like /api/login (login api) is allowed to be called directly from clients.
Next, I want to introduce a service broker API which should be entry point to all API calls from client side. So, any client calling a specific API such as /api/login should go through service broker and then service broker should re-direct to requested API based on the specific service details as sent by clients.
Thereby, all clients should only be able to call only one API (i.e. broker service API - /broker/service). So, all requests from clients should first hit service broker API and then service broker should redirect to appropriate API's based on the input parameters passed to service broker from clients. Input parameters could contain the API URL and input data.
Currently, I'm able to connect directly to individual API's from clients. But, now I would like to introduce a new layer namely service broker and that broker service should decide which API the request should be redirected along with input data (sent from clients).
Note: Both broker service API and other functionality specific API's are hosted under same domain. So, there will not be any CORS issue. We are using "express" node module for handling HTTP API requests.
My initial question is whether this requirement can be achieved?
If yes, then can we perform internal redirection of API's in node server?
Can this be achieved with express node module?
Please help me in this regard.
If you really wanted to go this route, you could do something like this:
app.get('*', function(req, res){
the_route_passed = req.originalUrl;
//handle all of the routes here in your api function call.
});
What this will do is for every single route passed from the front-end will go through your function, and then you can grab the route that was passed req.originalUrl will be like /api/users/230 for user 230. Then you'll need to parse the route or however you want to do it and pass it through to your service broker.
This would be the best way to deal with not having to change anything on the front-end if you are already using Routing. The other way which might be better in the long run:
Send JSON on each request and configure it however you want, and then when you receive it you can figure out all the routing from the JSON request on each go. You'd have to rewrite all routes on the front-end to do this though which might be too much work.
Servicestack is awesome. I'm using it for my Xamarin projects (monotouch and monodroid).
Users login and authorised by ServiceStack. The session details are kept in memory i.e. userId, Ipaddress, etc.
But what would be the best way to add websocket functionality so I could push notifications to these users?
Or would it be better to just leave a regular websocket open on the client and have a small websocket server somehow read the session data (user Ipaddress) from ServiceStack in order to relay bespoke messages to client?
As an alternative to Web Sockets ServiceStack supports Server Sent Events for real-time event notifications. All the Chat Apps in the Live Demos utilizes Server Events for its real-time communication.
But it doesn't include any support for Web Sockets itself, although here's an example of using ServiceStack and SignalR in the same project.