Case: Values are continuously updated in the database instead of API, socket is the best option,
but there is not much information related to socket io integration with fast-API(Python)
Related
My frontend kicks off an async process with an http POST.
By whatever means, (kafka, threading, database insert and another system monitoring the table), some process is completed after an unknown amount of time and finishes in some quantifiable way (you can make a http call and determine if its done or not).
Are there any design patterns/technologies for notifying the frontend without it having to make repeated requests to some service?
You can take a look on WebSockets, a bi-directional data channel that is generally used for real-time web applications.
The way you can use would be straight-forward: when you make the HTTP Post request and the async process is started on the backend, you also open a websocket connection with the front-end, for that particular request. When the async process is finished, the backend will notify the front-end through the websocket.
You can even use the same websocket connection to transport data for multiple requests (initiated by the same user), which is a kind of a multiplexing technique.
If you need the overall system to be scalable, you should think about having a cluster of VMs that manage the websocket connections (fully separated from the backend of your application).
We have a service which sends grpc requests under heavy load.
Normally, grpc send is considered to be an IO stage, which means it should use an IO thread pool.
We've noticed that the serialization time of the proto objects consumes rather a-lot of cpu, which is not suitable to use with an IO thread pool.
Is there some way to separate the serialization step from the IO step, e.g can we somehow do something like:
val bytes = myProto.toBytes()
myService.send(bytes)
We have no control over the .proto files and the server, but we can generate a client and a stub. We currently use scalapb but java might do fine as well.
Another option is to somehow translate the client calls to http2 calls, anyone ever tried that?
Any other suggestions on how to tackle this issue?
Thanks in advance.
gRPC itself separates protobuf encoding from transmission. Protobuf encoding and decoding is performed on application threads: the threads calling gRPC and the threads delivering callbacks (e.g., channelBuilder.executor()). Then the I/O is processed asynchronously using separate network threads (Netty event loops). Just interact with gRPC on threads that can handle the protobuf CPU cost.
A gRPC newbie question here.
We have a source system that exposes a bi directional gRPC stream. In order to scale our application, we wanted to process the stream data in parallel. Is it possible to have concurrent / multiple gRPC clients consuming from the stream without any conflicts in data processing / during acknowledgement process etc?
Thanks
Is this in the context of a single streaming call? In that case the answer is no. You have a single gRPC client receiving one response stream and it can use worker threads to hand off messages from the stream.
If you are thinking of multiple gRPC clients in an application talking to the same server (I don't see any advantage of doing that) each one will make a separate call and will receive a separate response stream.
Wanted to understand the fundamental reasons for push-notification like Google Cloud Messaging (earlier called Google Cloud to Device Messaging) being more battery friendly, for cloud <--> device communication ?
In my view, the alternative technologies involve "polling" (over TCP/IP) while keeping the connection in CONNECTED state, using keep-alives. Or is there something better ?
My limited undertanding of GCM is that, it also uses TCP/IP and keepalives, but the client never polls the server for status. Instead the server informs the client about an incoming message, and applications who subscribe to certain type of messages, are notified of the message asynchronously. Also, the common GCM connection, is shared between multiple applications, thus allowing the device electronics to sleep / hibernate at "coordinated" times, without multiple applications keeping the electronics more "ON" (electrically active) than they need to be. Is this the correct understanding ? Or is there more to it ?
Finally, how exactly does this compare to MQTT over TCP/IP with keepalives ? What are the reasons for MQTT being (apparently) less battery efficient than GCM ?
One of the main reasons it's efficient is it scales well. The android device keeps a single connection open to GCM servers to listen for notifications for ALL apps on the device, and then routes messages to the appropriate applications they are intended for. This is much more scalable and efficient than keeping a network connection open for every single application wanting to have some sort of push notifications.
The connection itself is likely a TCP connection that's left in an open state, even when the phone's goes idle. It can wake the device when data is received. I'd imagine there's some sort of heartbeat ping going on too that can have the connection be re-established if necessary.
The socket stuff is probably something you could do yourself, however like I said earlier the main reason for efficiency is the single connection for all apps. Very scalable.
I can see how a datastream/channel can be used to send commands to a device (e.g. an actuator). The device can periodically poll the channel for incoming commands, but if the device has no storage of its own how can it tell which commands it has already received/processed?
This all depends on your implementation and hardware choices. And the real answer to this question lays far beyond the scope of Xively. You say that the device has no storage of its own, but I assume it has some kind of volatile memory at the very least.
The best thing to do would be to store the timestamp of the last datapoint that was received and compare it to whatever current data you have. If the timestamp is greater than the one in memory then you know it is new data.
An alternative to HTTP polling would be to use a socket with some kind of publish/subscribe interface that will allow you to received only new data from the server. Xively offers this on it's TCP, WebSockets, and MQTT socket servers.