从服务器端通知客户端的最佳实践？

Question

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.

Answer 1

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.

Answer 2

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).