英文:
Best practice to notify client from serverside?
问题
在我的当前情况下，前端客户端以15秒的间隔向后端端点（Java）发出API调用，以查看资源是否存在。资源将通过一些业务逻辑创建。一旦资源存在，客户端将从API获取数据并处理它。
然而，似乎每15秒调用一次API的性能成本很高，而且不可伸缩。我想知道这方面的最佳做法 - 客户端等待资源存在以执行某些逻辑。
是否有一种从服务器向客户端发送/推送数据的方法/最佳做法，而不是反过来，同时保持单向传输（服务器 -> 客户端）..
提前谢谢。
英文:
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.
答案1
得分: 4
为了正确解决这个问题，您需要实现WebSocket。
客户端的请求将是GET请求，服务器将以状态码200来确认批准它。
然后，当服务器完成处理您的请求时，它将通过WebSocket直接向您的Web应用程序广播数据。
英文:
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.
答案2
得分: 2
你刚才描述的是所谓的观察者模式。其整体思想是将一系列观察者附加到可观察对象上，并在可观察对象状态更改时推送通知。
你可以在你的Java后端中实现这种模式，通过公开一个订阅端点，在其中指定你想要观察的内容，以及在状态更改时回调的URI或其他推送服务器通知的机制。然而，如果你想避免定期的API查询，你可能需要解决另一个问题，即让你的“客户端”充当服务器，无论是永久还是临时。
显然，你需要一个“取消订阅”端点来释放资源。你可能需要考虑的是，如果客户端意外断开连接或因某些原因未参与（在这里设置订阅的生存时间似乎是个不错的主意）。
英文:
> 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).
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论