Develop Reference

AJAX - How can I build a notification system, that is constantly getting updated, without slowing down my website too much?

I am a beginner to web development, and I am trying to do a notification system with AJAX and jQuery.
In my web application, I have a comment system where you can mention another user. After a comment mentioning a certain user has been written, a new entry on my notifications table will be added, containing the comment, the id of the user who commented and the id of the user(s) who will receive the comment. After the notification is stored in the database, I want the person that was mentioned to receive the notification.
To that effect, I decided to use AJAX. Using the setTimeout() method, I am sending an AJAX request to the database every 2 seconds, and with that, I can display the notifications visually to the user that is meant to receive them.
My only concern is that this will slow down the site once I connect it with a server.
So, I was looking for a way that would allow me to implement a notifications system without slowing the site too much, since the one that I am using currently doesn't seem very efficient.
I would appreciate any help.

How do I push mongodb data?

So I have developed a web app as a hobby on Handlebars, Express and Mongoose/MongoDB.
The app let's users create an account and then post advertisements for other users to see and respond to.
All the ads posted by users show up on the index page. So it is common view for all the users on this web app. I am relatively new to web development so to build such a simple app it took me a while but boy I learned a lot!
Now the issue I am facing is, when a user A posts an Ad while the user B is logged in and is currently on the index page (a page that lists all the ads posted) it won't show up for user B unless user B refreshes the page. Rightly so actually because only when the index page's route is hit it will query all the ads and refreshing is basically hitting the index route I get that. But I don't want it that way. I want it to show the new ad on user B's index and pretty much every user's index if there's new ad by any user.
So I did a little research/reading and I learned that I can do it by learning to work with triggers on mongodb and like create some kind of trigger that when a new ad is posted do something. I like the idea but failed to find resources to learn how to use such a thing.
The other option I was suggested was to use socket.io but that too I can't grasp how can I make an entire Ad document work as a socket. I am lost and implementing this feature of dynamically loading ads for all users will complete this hobby project of mine and will help me find a junior dev job in local community.
I request stackoverflow's community to guide me how do I go about doing this and what resources I can use to learn about it.

The socket.io seems to be the best solution for your case. What you will want to do with socket.io is every time a user posts an Ad you use socket.io to notify the rest of the users that there is an update.
If you don't want to send the entire document using the socket you can use the socket to notify the clients and on the client side every time you receive such a notice from the server you will either
a) Refresh the page(not suggested as it will make the user experience unpleasant) which is easier to implement
OR
b) You can use an Ajax request to get the new data from your server and update the fields on the fly(which makes for a better user experience).

Best Way You can come with using Short Polling concept from client side to ask for new data after 1 or 2 seconds (whatsoever count to need ) . Gmail for new inbox mails also uses sync method in a particular fashion . Just ask from server for new data
OR Second option to go through below
On Server Side
Serve index.html page to User A (which is logged in now).Some User B inserts data
Maintain a function or a cron job (checks the count of Total Ads ) Lets say after every 1 minute or so
If there is change in count from the previous total_count , update it and get new mlab documents and send it to function , Let's say push_new_ads which will be sync via socket.io to client
On Client Side
Sync your client_total_count with server_local_count push_new_ads using socket.io and If there is change in count , make a simple fetch api call to get data and appends it to previously fetched array
There is no such way to directly listen the changes in mongodb But you can trigger some changes from oplog using tailable cursors

Methods to introduce notifications on a webpage without page refresh

We have webpage where there is notification tab. The notifications are taken from a notification table if there are any for a particular user. This event is fired when the page is refreshed.
We now want to implement something where the notification should be displayed to the user instantly without refreshing the page.
I know about SIGNALR with sql dependency. But with sql dependency there comes database polling overhead.

You can have SignalR notify clients of database changes without polling the database.
Have a look at this tutorial about SignalR database notifications.\
It works the following way: Exactly after you update the database, you call the method to update clients along with the data.
Hope this helps. Best of luck!

Stopping php-called mysql server from running if website is refreshed

I have a local website running that will query a mysql database via inputs given by a html form. The form values are sent to php via jQuery to call the query. Is there a way to send a command to the mysql server to kill the query if the website is refresh?
Currently if I refresh, the last mysql call will still run, so the website will be locked up until that query is finished.
Edit: To give a little more background information on the website, it is a local website that is solely running d3 visualizations based on a series of involved queries (lots of full text searches) on a large database (3 tables all in the 1 - 5 million record range). The "lockout" I'm referring to is not being able to abandon a query and try a more efficient query (i.e. something that will limit my results more).

Perhaps there is (it generally involves selecting the last process ID from the MySQL Processlist and issuing KILL QUERY on that process ID), but there are some problems that I think you should try to address first.
To begin, why in the world does one query "lock up" a website? I might be smelling a design flaw.
JavaScript could be used to make the browser "hit" the server on a refresh, but that's just adding another AJAX call and, presumably, another MySQL query (having to do with the processlist) and more PHP to write to handle the AJAX call, the processlist lookup, and the KILL QUERY query ...
I would recommend you try and make the server/MySQL query more efficient, so that you don't have to get a flying flip whether the browser is refreshed or not. As for browser security, you could probably use either PHP or JavaScript to enforce some sort of "flood limit" on repeated refreshing ....

How to handle this typical case of WebSocket usage?

I wrote a web page where there is a zone for user's comments.
Any authenticated users could post a comment.
As many users could post comments almost simultaneously, I want the comments list to be auto-refreshed.
Thus, I think about using WebSockets.
My thought are about a good/best practice for this use case:
Once a comment is posted, should WebSockets process read the current comments list on database and send a Json response containing all the new comments? This would allow the client to directly append the new comments on the DOM (JS).
Or should WebSocket just check the database (or queue if using a message queue (Redis, RabbitMQ etc..) for instance) and act just like: "Hey, I have new comments, click here if you want to see them !". This solution would only signal the presence of new comments, without bringing all those comments to the client. The workflow of retrieving the events would then involve by the client (by clicking on this sentence for instance) e.g using the traditional Ajax direction: client => server.
It is highly possible that a user posts a comment, then navigates to another page of the website. Therefore, a websocket response containing the whole new comments would be useless. A simple notification would then be possible, as most of known websites do for instance with the "+1" counter or more relevant to the "comments" scenario: "1 new comment available".
Which way should I choose?

I think to decide which data to push is mostly a matter of UI usability / user experience, as opposed to which technology is being used to interact with the server. We should avoid changing the UI with server pushed data in a way that would surprise the user in a negative way, for example having the comment feed constantly growing without any intervention from him.
But in the case of a realtime chart, it's probably better to push the data directly into the chart, that would be what the user expects.
In the case of the comment feed the reason why most sites go with the 'click to load' approach is because of user experience, so I think that is probably the best approach.

I use a combination of both....
In some pages the websocket communication contains the actual data--sort of like a stock ticker update.
And in other cases, the websocket communication just says -- all users viewing xyz data--refresh it. And then the browsers performs an ajax to obtain the new data and the grid is smartly refreshed in such a way that only the changed cells are modified on screen using innerHTML and the new rows are added and deleted rows are removed.
In cases like stackoverflow, it makes sense to show a message, "Got new stuff to show--want to see it?"
When I establish the websocket in the browser, I pass a page Id in the url and the cookies are passed too. So websocket server knows--the user cookie and the page which is being viewed.
Then in the database (or middle tier logic) communicates to the websocket server with messages such as: This message is for users viewing 'xyz' page: smartly refresh grid 'abc'. And the websocket server broadcasts the message.
Because the protocol allows you to pass anything you like, you have the ability to make it anyway you like.
My advise it to do what's best in each particular situation.