When you need to send events from you application server (backend) there are various technologies that you can use.
Each technology has advantages and disadvantages and is made for different use cases.
Server-Sent Events and WebSockets
Server-Sent Events and WebSockets can be used to "push" events from the server to the client when a user is surfing a website.
Unlike Server-Sent Events, WebSockets is also bi-directional: this means that the client and the server can exchange multiple messages asynchronously on the same connection (similarly to a bare TCP connection).
However you cannot use Server-Sent Events and WebSockets to send a message to a client when the website is not open.
They are an evolution of polling / long polling that doesn't require to create another HTTP request when a message is received (instead the connection or request for streaming the events can remain open).
Push API and Web Push
The Push API and Web Push are two related technologies that are used together in order to send push messages to a client, even when the website is not open.
They are mainly used for delivering Web Push Notifications.
They also require the user consent: the browser will display a permission prompt asking to the user if he wants to receive notifications from the website. In case the user deny the consent, these technologies cannot be used.
Also note that the Push API and Web Push will not deliver a push message directly from your backend to the browser: instead, you need to send a POST request to the browser push service. Then there is a persistent connection between the browser and its own push service that will deliver the push message.
If you want to learn more about the Push API and Web Push technology you can check out the official documentation or read this short introduction.
If you are looking for a managed service for web push notifications, instead of building your solution from scratch, you can try Pushpad.