I have struggled to find many resources on this online. I am developing an application that multiple users will be using at the same time. This means that one user may edit the database after another user has loaded the data from database. This means that this second user will not have an up to date view of the current state of the database. What is the best way to subscribe to database changes and deal with them. I am using a MEAN stack.
If you are trying to develop a real time system where changes are reflected instantly upon changes in database, you need to make use of web sockets. Since you are using Node.js as backend, see Socket.io
A good resource for implementation can be found here
However, if you plan on implementing web sockets, you will have to make significant changes to both your Node.js and Angular code.
Another method (which I would not recommend) is to make periodic api calls for those views which you want to reflect real time changes. You can make use of setInterval for this
Related
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.
I'm trying to build a simple live chat for my website, I already have everything set up, meaning databases, login and log out system, forms, displaying the database values in chat form.
The only thing I'm missing is implementing the live refresh function so users don't have to manually refresh the site to see new messages.
I'm a little lost, could you give me some guidance?
I'm guessing I have to add a specific javascript call whenever a message is sent, or the "send" button is pressed to be more specific, then that would call back a function to refresh the chat for every participant. Not sure where to start or which code to use.
Essentially, you have 2 ways to implement this.
Using a polling technique with ajax request which will grant you a greater compatibility, but you will have to much more work to implement it. I don't really consider it for most cases nowadays, because it could be very inefficient.
Using a socket mechanism, you can use web sockets for a out of the box solution, most browsers have support for it nowadays For third party libraries you can use socket.io which can fall back to web socket yet it grants a little bit for features out of the box, like channels, which you would benefit from. Lastly, for a third party service, you can use firebase/firestore which they have a realtime database, so whenever a change happens, you get notified.
I would recommend using either the web socket approach (native) or using a wrapper/library like socket.io. If you go with Socket.io, there are a lot of tutorials out there that build chats with that library, so you can get a working sample really fast.
I'm using VueJS and MongoDB to create a virtual pet.
We're saving the user data using localStorage.
I'm wondering what the mechanism would be, to make the virtual pet evolve (ie. life gauge going down) when the user is not on the web app.
Would I need to save the date when the user leaves the app ?
Yes, you should save the time when the user leaves the app.
When they return (so, whenever you fetch data from the database), compare the saved time to the current time and apply whatever operations need to happen based on the difference.
Alternatively, you could have a server always running and deal with scheduled jobs and the like to keep it all updated in realtime, but lazy evaluation that only happens when the user requests the data should suffice for this case.
I have built a web application using AngularJS (front-end) and PHP/MySQL (back-end).
I was wondering if there is a way to "watch" the MySQL database (without Node.js), so if one user adds some data to it, the changes are synced to other users too.
E.g. I know Firebase does that, but it's object oriented database and I am unable to do the advanced queries there like I do with SQL.
I was thinking to use $interval and $http and do ajax requests, so that way I could detect changes in the database. Well, that's possible, but it'll then do thousands of http requests to the server everyday and plus interpret php on each request.
I believe nothing is impossible, I just need an idea to do this, which I don't have, so that's why I am asking for a help here.
If you want a form of "real-time communication" you'll likely have to incorporate some form of long-polling from the client. Unless you use web sockets, but that's a big post about a bunch of different things. You're right to be concerned about bandwidth and demand on the DB though. So here's my suggestion:
If you don't have experience with web sockets then log your events in a separate table/view and use the pub/sub method to subscribe entities to an event, and broadcast that event to the table. Then long-poll against the watcher view to see when changes may have occurred. If one did occur then you query for the exact value.
Another option would be to use some query system with "deciders" that hold messages. Take a look at Amazon's SQS platform for a better explanation of how this could work. Basically you have a queue that holds messages and a decider chooses where to store the message using some hash or sorting method (to reduce run time). When the client requests an update, the decider finds any messages that would apply based on the hash/sort and returns them. Then you just have to decide how and when to destruct the messages.
The second option would require a lot more tinkering though, so it's really about your preference. I think what you'll find the difficulty to be is that most solutions have to deal with the fact that the message has to be delivered 1 or More times and you'll need to track when someone received the message and if it can now be deleted from the queue/event table or if you still need to wait. Otherwise you'll consume a lot of memory.
Progressing along with my isomorphic javascript crusade, I put Meteor on a hold while I played a bit more with the MEAN stack. To ward off any further procastination, I've decided to finish my original prototype community application. Now, my biggest issue with Meteor isn't reactivity, it's session/common data.
I know Meteor's native session system is based off of the reactive concept, and cookies don't "exist" because Meteor operates on "the wire". Though let's say I were building an application on the LAMP or mean STACK, and I was creating a user interface. I'd use cookies/sessions to control user activity. If Meteor operates off of reactivity, how do I maintain persistence?
I have searched through atmosphere for packages that fit my criteria, and I ran into a couple of packages that store "presistent sessions". Though these interfaces operate off of the client, not the server; hence my code would be exposed client, therefor setting the application up for exploitaton.
All that being stated, I know Meteor has it's standard user interface. What I'm trying to do here is understand Meteor, and gain experience for future endevours.
Meteor has a built-in login system that keeps track of the logged-in user, which is one of the main reasons people use cookies. If you want to store other data on the client in a persistent way, you can use the HTML5 localStorage API.
I think what you're referring to is that something like PHP lets you store data in a "SESSION" variable that is actually stored on the server, but persisted between different requests from the same client.
If this is what you are looking for, there are several approaches that will give you similar functionality:
Store data associated with a particular user, and use the userId that Meteor gives you to only publish it for that user (using Meteor.publish)
Have a randomly generated client ID that is stored in localStorage, and pass that in when calling subscriptions or methods to authenticate as that client. This will work in the case where the user is not logged in, and will give you a very similar result to cookies/session in PHP. You will still store the actual data in the database on the server, but you will know which data is associated with a particular client by the unique ID.
It's true that Meteor's Session variable is named in a way that can be confusing if you are coming from PHP where SESSION means something totally different.
Does this answer your question?