Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
Basically my application will allow you to publish news while it will handle a system of likes and dislikes
I will use the mongodb database.
Basically I will have a collection that will contain news and an attribute called likes, and another called dislikes. Both will store an array and this array will be filled with json objects with the users who have registered a like or dislike respectively.
when a user makes a request to the news list I will return the news and two attributes like: true / false, dislike: true / false according to the user making the request.
is this the best way? how does facebook do it?
Thanks a lot
As a general rule of thumb:
If you don't need the usernames of the users liking the posts, just store the like and dislike counts as integers in an object.
If you need the usernames, store all the users who liked and the users who dislike in separate arrays.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I have a firebase database and I want to create a search bar that will filter results from the database objects.
But I do not know how to go about it.
I have looked everywhere to find a good example but none of those I find are related to firebase.
otherwise is there an alternative way I can do this?
structure of the real-time database on firebase
any help and suggestions would be great.
Firebase is not really good for searching. The firebase team recommends using a third party solution like algolia.
However if you don't want to go through that you can just retrieve all the data in the collection or path you want to search, and add searching logic in your client
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Problem summary:
We are developing an App and want to give our users an easily memorable ID to share items in a fast fashion.
Problem detailed:
We are currently uniquily identifying items by the automatically generated ID's from MongoDB. Unique ID's in MongoDB are long and hard to remember. We would like to give our users easily memorable ID's to easily share items with other users.
For example an element in the App needs to be worked on, telling a colleague to go to ourapp.com/a7wefweg43tr is a pain in the ass, what we would like is to in addition to the unique id to technically identify the element within the app a more human readable / memorable unique id for sharability. (Very similar to what Jira is offering (AA-0001, etc.)
Are there best practices on how to implement this / any JS libraries that would do the job ?
If you can have a central service that you would call out to to generate unique IDs, do that and in this service implement any pattern for ID generation you like. MongoDB IDs are designed to be generated by non-communicating clients in a manner that is as collision-free as possible.
human-readable and technical unique are on the opposite end of the same road ... why not let the creator of the ticket type in a human-designed short-tag, check if already existing and provide a slightly extended version if already used. like account-creation in online-games.
if no context between item and id is needed ... put in a dictionary of common-words, create a new random tripple of these words, check if already existing, repeat if already used. easy to memorize and tell by phone. like the military spelling alpha-zulu-tango
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am a coding beginner and I need help deciding on the way I will store data for the website I am building. I have a section on my website where I will be listing items. Each item will have several properties. I was thinking between javascript objects or storing the item and the item's properties in a database. What are some situations where I should use a database, js objects, or view files? Any advantages of each type? Also how about when you are trying to sort the items?
You should store data in your database Only When you need !
If you don't have any logic process on this data in your server, there is no need for storing in database, So just store in your View files.
Also if you don't need this items in your javascript code so don't store them in js file ! just write them wherever you need.
EDIT :
If you have some operations like sort, order and etc :
If your data will have many changes and process it's better to store in database.
If your data will not have many changes and is some constants, so just stroe them in a javascript object.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am building a single page app.
The app has a list of 7000 ports stored in a MongoDB database.
I need to be able to search for those ports with autocomplete on the search.
Should I Ajax the autocomplete results ?
OR
Should I retrieve the whole collection of ports, store it in a variable, plug my autocomplete on this array ?
What's the best practice ?
What's the smartest performance wise ?
Because you said the list can grow I would not load the whole list into your app. This could lead to performance issues if your list becomes too big.
I would solve this problem in this way:
Make a route on your webservice, which returns lets say the top 10-20 results matching your search.
On input send a GET request to your endpoint.
To improve performance you could cache the list in an in-memory database like Redis to avoid slow database-access on every request.
Best practice and smartest performance wise is to:
Send the search string to an API resource, example:
/autocomplete?search=portname1
Retrieve the autocomplete results and visualize them
You can use existing JS libraries for autocomplete (avoid discovering the hot water)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am using express,react and mysql. I want to create like/dislike system for the comments. I googled it and most people recommended to disable the button after single click. But I don't want that. Even the user refreshes the tab or access his profile from another device. When he sees that comment again, he should see that he already liked that comment and he should not be able to like it again. I am thinking of storing all the likes and dislikes in the mysql database for each user. Does it decreases the number of queries to database and affect the performance? What is the proper solution?
If you want to show the users who liked/disliked a post (or a comment), you will have to insert a new row along with the user-id for each like/dislike. And regarding the multiple-likes problem, you will have to check whether or not there is a row with the same user-id and comment-ids as the ones you are getting from the post request, if so, just ignore the request and tell the user something like "cannot like more than once", otherwise insert a new row.
Another thing to consider is, what do you plan to do in cases where a user likes a comment and immediately unlikes it ? If you are sending real-time notifications, then the target will get a false notification (that is, if you don't tackle this problem). That was something I hadn't considered and there simply was no way (but i am sure there is a trick).