First i'm a node.js begginer. I have a chat app which i created with socket.io the concept is i make a single unique room after 2 users are paired. but want to know if is it necessary for me to delete the room after the 2 members leave or i just let it.
I don't even know if the rooms are taking storage and how much..
some one help me understand please.
Rooms are automatically created and deleted as users join and leave.
As for storage, socket.io doesn't use any storage during runtime, just memory. A single user or room shouldn't use any significant amount of memory.
Related
for my school project i have to recreate Secret Hitler game using socket.io/express/vuejs2.
And at the moment I'm stuck at the part where i should create lobby that other people should be able to join. I used rooms for the lobby, but then i realized that it's not what i need. What i though of is when person creates a lobby, a name will be assigned to that specific lobby so other user will be able to join that lobby by inserting the name of it or using the link which would look something like that http://mygame.com/?lobby=ABCD. But if i got socket.io rooms correctly, i wont be able to do that, because you can't create unique rooms. Or I'm just dumb and haven't figured that out yet.
So my question is how could i implement lobbies based on my idea using socket.io and expressjs? What documentation should i read?
Try this Tutorial
https://www.youtube.com/watch?v=DvlyzDZDEq4
I know it is a zoom app but it will give you a basic idea on how to create rooms with node.js
I am building a shopping cart system, but I am quite confused with how to build it properly when it comes to this two situation,
When User is not logged in
When User login
So in first situation I can use local storage to manage the data, and the second, I can use database to store the user's shopping cart , but here come the problem ,
if User add something when not log in , but he already has different items in their database shopping cart , I can just add them together or replace the local storage shopping cart with database one ?
As I said if I use two different strategy , before each shopping cart related function, I should add "if user is login " to decide it would send by API or just store the data in local storage , is it really a proper approach ?
If above is not the good approach , then how should I structure my project ?
I am not really familiar with real world web design , and I watch a few shopping cart tutorial , I don't think they cover enough ground for real production , maybe someone can provide a good real production example using React + NodeJS , I would be much appreciate !!
This sounds like a business decision. Get your product people and your UX people involved.
If you don't have those, there are multiple things you could do.
Add a date of creation to your shopping carts. You can then experiment with either prioritizing the latest one, or asking the user to choose between their last two
Merge them into one. This is very likely not what the user wants, especially if their older cart is older than, say, 24 hours.
Speaking of which, shopping carts should expire. Most ecommerce platforms I've worked with usually archive the shopping carts after some time (15-60 mins). During this time they keep the items in the cart as reserved so no two people end up competing for the same stock.
Expired carts can be stored so you can send an email to your user with a link that allows them to get back to their unfinished purchase.
So with that in mind, consider the following questions:
How relevant is each shopping cart to the user? Do you have a way of chosing the "most" relevant one?
Are you dealing with physical goods where you need to keep track of the stock? Then you probably need to "reserve" the appropriate amount of items for each cart, and you'd need to "expire" each cart
Do you ever want to present your users with a choice of two shopping carts? If yes, create an interface where they can do that. If no, consider prioritizing the latest cart and consider sending an email to the user reminding them about the earlier.
Your problem is with having too many options, not with having no choice, so you need to either get your peers involved, or start A/B testing. I think you'll only get subjective answers here.
i would like to ask if there is a best practice for firestore, when one develops a chat app, and what is the best practice to store messages for chat-rooms.
The assumption here is that every chatroom has its own document.
I started using an array to store the messages from the users. The problem with that approach is that there is no way to add, a insert(append) a new entry everytime a new message is submitted to the chat room. One has to save a new copy of the array with the new message appended. This seems like something that would scale really bad, unless the chat history is split in sub-arrays etc..
In the official documents, they suggest a structure, where one should store the messages of a specific chatroom as separate documents in a sub collection of that chatroom. I wonder if this approach is the best, and what would be some drawbacks, or if there is another preferred way to do this.
I would generally go with the approach of "Every chat room has a subcollection of messages. And every new message is a separate document in this subcollection." This has several advantages: It's easy to add or edit individual messages, and you can perform a number of different queries (like "Grab the 20 most recent messages")
The biggest drawback, I suppose, is that if you find that new users are frequently going to be entering your chat and will want to see the entire chat history of the room up until they joined, that would result in a large number of database reads. Realistically, though, I don't know how often that would happen in real life, and you could mitigate this by using pagination to grab your historical chat in batches.
To add to what Todd said:
In arrays you cannot store Timestamps - a big downside for your case, as you'll want the time the message was sent.
In a node application serving websockets where users subscribe to several topics published and gets new updates on the topics in a real-time manner, whats the best way to store the topic-subscriber map?
Live Topics : Topic1, Topic2, Topic3, Topic4
User1 subscribes to Topic1,Topic2,Topic4.
User2 subscribes to Topic2,Topic4.
So there shall be a map object as follows
Topic1=>[User1]
Topic2=>[User1,User2]
Topic4=>[User1,User2]
So that when there is an update on Topic1, the application shall pass the update on User1's websocket.
The question : Is it good enough to keep the topic-subscribers map as an application variable (javascript object)? Or is it better to employ REDIS to manage this?
I also want to store the information in this map to analyse for the trends like Topic interest over time by geography. Hence, this data shall be copied to the original DB in the background.
I believe I should not be querying the database to find the current subscribers everytime there is an update on a topic.
As with what I managed to find, REDIS is an in-memory datastore. And the javascript application variable will also live on the RAM.
Whats the best way to go about it?
Performance as in the quickest update to the subscriber is desired.
Personally I believe it is better to do this in Redis, but only because sooner or later you're going to need more than one node as your application scales. The moment you do that you're out of NodeJS-land and trying to find some way to coordinate this work across a cluster. Redis is very well suited to this task.
That said, perhaps you should look at the ActionHero framework. Its chat module does precisely what you're trying to do. With very little code you can have WebSocket clients connect to one or more nodes in a cluster (coordinated by Redis) and join zero or more chat rooms, then receive the messages sent to those rooms. It could save you some time.
I am creating a mock app with user creation/auth/friend in a node js learning exercise. Having spent my time mostly at the front end of things, I am a n00b as far as DBs are concerned. I want to create a user database where I want to keep track of user profiles and their connections/friends.
Primary objective is to load/store users connections in the database.
Fetch this information and give it to the user most efficiently in least number of queries.
I'd really appreciate some help with a DB structure I should be using that can accomplish this. I am using mongodb and node.
Off the top of my head: I can store the user's connections in an object in the "connections" field. But this will involve making a lot of queries to fetch connections' details like their "about me" information - which I can also store in the same object as well.
Confused. Would really appreciate some pointers.
Take a look at the Mongoose ORM. It has a populate method that grabs foreign documents. Lots of other great stuff too.
You could say
Users.find({}).populate('connections').exec(function(err,users) { ... });
Before popualte the users' array of connections was an array of IDs, after, its an array of user documents.