I have an angular web app on a GO backend that checks for a user's notifications every few seconds via http request. Most of the time there are no new notifications.

I have found that this frequent traffic is easily disrupted when there are concurrent long-running requests being made (to the same or different backends) and leads to high latency of the notification request, to the point where it times out. Depending on the other traffic on the page, this can lead to cascading timeouts of the notification requests and result in the user not seeing a notification for several minutes or not until they navigate away from the request heavy page.

The timeout is currently 30 seconds. In the dev environment, the request returns every time and only takes a few seconds. In the prod environment, around 60% of the requests exceed the 30sec timeout. Prod is provisioned better hardware and is typically much more performant than dev, but Prod also has a lot more data in general to handle. I don't believe increasing the timeout is a longterm solution.

I think changing to a push notification model would be ideal, which to my knowledge, would require rework of the GO backend to support. Are there any recommendations for how to implement this? Would this be a good use-case for a SignalR websocket?

Or is there a way I can leverage angular to manage this functionality for me without refactoring the backend? I took a brief look at Push API; would this be worth trialing?

CodePudding user response：

For a feature like getting notifications, there are a variety of ways you can update that.

1. As you mentioned, you can utilize polling, which performs a network request over and over again on a given schedule.
2. If you don't want to use polling but don't want a websocket or other realtime solution, you could do something like always performing a request when navigating to a new route, so it updates the notifications on route navigation. Less realtime, but not frequently pinging the backend.
3. You can utilize a websocket technology. (SignalR, Pusher, Pubnub, etc.) Instead of polling for updates, the client simply subscribes to a websocket channel and receives updates as they happen. (a form of push notifications)
4. You can utilize a real-time database such as Firebase, Supabase, or others, to keep the client always up to date with the state of the data.

What's the best option? Honestly it depends on your needs, but I typically utilize websockets for these kinds of usecases.

CodePudding user response：

Option with making http requests every time is not the worst. It is simple on server side (just a "GET" handler), do not require infrastructure in addition to memory cache and relational database. All you need is to carefully design polling handler (choose lightweight serializer, appropriate data structure and do not perform heavy operations, making it as simple as lookup the result from e.g. Redis). If you have microservices, you can make it as another service and load balance to it.

Otherwise, you can also check https://github.com/centrifugal/centrifugo and database with subscription support, like https://rethinkdb.com/ , then subscribe to database updates and push them via websocket. But in my opinion this is a thin ice that not everyone will be able to walk on