How to create notifications

[Adamhumbug]

HI all,

I am building a php application and i am wanting to use notifications.

At the moment i am just wanting to understand the methodology behind this.

I dont necessarily have a use case for these notifications yet but i am going to base it off of the following:

A user submits something to the database, another user gets a notifications that this has happened.  I see the notifications being something appearing in the header bar (saying "you have a notification"...)

I know that i will need to use ajax for this and JS/JQ but i am not really sure where to start with this.

I have done some research and have come up a little blank.

My main question at the moment is how does the submission of data to the database trigger the notification?

As always and help here is appreciated.

Kind Regards

Adam

[gw1500se]

Search engines are you friend.

https://www.cloudways.com/blog/real-time-php-notification-system/

[Adamhumbug]

32 minutes ago, gw1500se said:

Search engines are you friend.

https://www.cloudways.com/blog/real-time-php-notification-system/

Yes i had a look at this example.

Am i correct in thinking that this only loads notifications on page load.  If that is correct, would this mean that i would have to run this code to look for new notifications on every page.  Also would i be correct in thinking that the notifications would not appear unless the users is navigating around pages.  Unless a page can reload, there will be no notifications?

[gw1500se]

Incorrect. The page waits for a response from the server in background.

[Adamhumbug]

On 5/3/2020 at 4:23 PM, gw1500se said:

Incorrect. The page waits for a response from the server in background.

Thanks, i will have a further look at this then.

[gizmola]

There's a few different ideas in play.  In the olden days, if you wanted to maintain a channel of communication between a (web) client and your server you could use polling.  This was essentially some javascript running in the client on a timer that would make a request to your server every so often.    The problem with this is that as the number of users goes up, so does the number of requests purely to poll the server for new messages.

The next evolutionary step was Long Polling.  The idea with Long Polling was, that the client would open an ajax connection to the server (with HTTP these are TCP socket connections) and hold it open listening for a response.  The server only responds with data if there is a notification.  At that point the client closes the connection and immediately opens a new one.  This was a good work around for systems where notifications are desired but are relatively infrequent.  With PHP it also has some significant overhead in traditional Apache/Mod_php environments, as a child process will be forked/allocated to each running PHP script.  This can tie up a lot of children with large allocations of memory, simply waiting on open ajax connections.  

The next innovation was Websockets.  The idea of websockets was to create a specification that does not work within HTTP,  but instead is intentionally designed for standalone persistent client/server communication.  This has become a well adopted technology at this point, as libraries and servers exist in javascript and all serverside languages.  The big advantage of websockets was that it was client agnostic in that you could build a serverside solution that will work for any type of client you might have.  So if your serverside app is basically a REST api used by mobile clients, you will probably choose websockets.  There are also numerous PaaS vendors out there like Pusher, who offload the serverside overhead of Websocket communication and operate as proxies for websocket communications.  Your client code can talk to Pusher who manages the socket connection to the clients, and you then write a serverside script that connects to Pusher and handles messages and sends responses to clients as needed.  Even if you run your own Websocket server, you will implement a similar architecture.

The latest innovation is the Web Push Protocol built right into various web browsers.  This was meant to address the lack of OS level notifications that exist in the mobile OS's which mobile app's can use to subscribe a user to serverside information.  Websites have long desired a way to re-engage or update users without their having to visit the site again.  Email has been the traditional method for that, but now browsers are allowing subscription opt-ins for a website, which you can use to send notifications to users.  Of course the main issue is that these notifications are specific to a browser AND the user must have the browser open to receive them.  With that said, sites have rushed to implement the technology, and as in the case of Websockets, scores of PaaS vendors have emerged to act as middlemen in implementing proxies.

There is an awful lot of setup and configuration involved with Web Push implementation.  A great way to understand and perhaps implement your own web push notifications would be to use a component library like web-push-php which has documentation and references you can use to learn what you will need.

 

[Adamhumbug]

Thanks all for this - opened the door a little for me