I'm making a blog in which the home page shows all the blog posts each linking to the post's separate page. I am using sinatra as the framework and mongo as the backend. The url's that I generate are something like this:
http://blogera.io/prakhar/post/4fb8c0562767621088000002/hello-world
The long number being the ObjectID of the post as stored in mongo. On reaching the url I'll extract the object id, query the db and display the post. Is there a better way to do this? The url's dont look very good and it might be bad for SEO as well?
Any thoughts / suggestions would be great. Thanks!
I would use a number as identifier, not MongoDB's internal _id value of a document. That would make your URLs a lot cleaner, such as:
http://blogera.io/prakhar/post/1/hello-world
In this case, you would query MongoDB for the blog post with that numerical identifier.
It's also better in case you decide to change database in the future. You rarely wish to change the structure of your URLs. If you do, you would have these long identifiers in your URLs that just stem from your use of MongoDB in the past. That just doesn't make sense.
Related
I'd like to build a semi-automated site where pages would be created based on information on the database.
The site would be a vocabulary-like site where there will be thousands of words with their associated meaning, phonetics, and sentence examples along with other useful information.
Since a CMS like WordPress wouldn't work in that sense, what is the best solution for a system like this?
thanks,
I am currently watching a how-to create an instagram clone for Swift and want to understand the data model for the comments.
What is the purpose of using a model for the comments like:
post-comment (key = post-id) and comments
over something like this, where every comment has the post-id in it?
Without knowing what exactly they're building, and the types of queries they need to support for the app, one can only guess that this post-comments collection satisfies the need for a query to find out which comments are a part of which posts, while still allowing queries that search all posts or all comments. You should find the part of the tutorial that queries this collection to find out what it's trying to do.
This tutorial might be kind of old, because this sort of thing would be a little bit easier to express today using collection group queries.
I am working on an application which will have users.. who create posts.. and other users can like/comment on any post.
I am trying to figure out a best way to design db tables for this. I have read the anypics tutorial on parse.com site. They keep all comments and likes in a table called "Activity". (which makes sense) being able to query any type of activity (like/comment) from a separate table without having to touch "posts" table.
My question is- in this scenario how do I fetch all posts that current user created along with likes and comments on each those posts?
Anypic app by parse makes a separate request to fetch number of likes on each post (which I think is not ideal.) I am new to nosql data stores.. so if someone could help me out with suggestion on how to structure data that would be great.
Also, how bad is it to store all likes/comments as an array in the post itself? I think this won't scale but I might be wrong.
Thanks
In terms of Parse, I would use an afterSave Cloud Function to update the Post anytime a like/comment is added.
Have a look at the documentation here, in the most simple case you just create an afterSave for the Activity class that increments the like/comment count.
In a more advanced scenario you might want to handle update/delete too. E.g. if someone can change their 'like' to 'not like' you would need to look at the before/after value and increase/decrease the counter as needed.
I am a fan of storing extra 'redundant' data, and no-sql/document-db systems work well for that. This is based on the idea that writes are done infrequently compared to the number of reads, so doing some extra work during/after the write has less impact and makes the app work more smoothly.
I'm bulding a small web application using mongodb and just thought if it's a good practice to show mongoIds publicly, in urls for example.
Now I'm using the following url structure for user profiles: http://example.com/user/MONGOID
Does this have any security flaws or is it discouraged in some other way?
The answer depends on many of things...
Using an ID in a URL is generally a bad idea. According to OWASP, it ranks #4 in the top 10 web security vulnerabitiy list. But using it will not ruin your project.
To prevent the security vulnerability, you must either :
Use it only on data that is public (like StackOverflow profiles)
Have some code intercept the request and validate that the user has the rights to see the resource (a profile, a page, a document, etc.)
Using _id It also ties your public URL to the back-end. You will need some conversion if you change database technology. Or maybe you will need to run some changes that will result in the object being destroyed and created again, but with a different _id, like merging databases or something. You don't want your URL to change because of that.
Another thing is that _id does not have a good spatial distribution. It does not make a good sharding key. Being derived from a time stamp, all _id are close together, linear if you will. They will tend to go in the same shard (Mongo will spread them later, but you want a key that has high cardinality).
So I prefer to pay now, and use a id field that is private to the application from the start. You can store it in the _id field if you want, but consider adding another key to your document, index it, and use that in your URLs.
No it does not have security implications.
All the person would be able to do is to guess the Id of some user or to try to go through all Ids to get all users of the system.
Take stackoverflow as an example. They have the same pattern as you: http://stackoverflow.com/users/352959 this is 352959 is you and there is nothing bad with it. The only thing that whenever you will enter this in your browser you will be redirected to http://stackoverflow.com/users/352959/king-julien.
I can try to iterate through these numbers and the next guy is http://stackoverflow.com/users/352960 but all I can found is that this is some john. And surely http://stackoverflow.com/users/1 is the creator of the resource.
I've been told that it's bad to expose database internals but I've started noticing lots of relatively high profile sites doing it, e.g. Chartboost and ServerDensity both expose the MongoDB document _id field in their URLs.
Can someone shed some light as to why that's bad to do? The only thing I can think of is that it's bad for SEO because they're not human readable URLs, but is this even true?
By "exposing database internals" I understand stuff like exposing the database server to the internet or letting user run arbitrary queries. This stuff is unquestionably bad. Or, if you somehow expose your database schema, a malicious user can use this to his advantage.
Using object ids in urls is fine. Humans do not memorize urls anyway, and search engines don't care if link to a post is made of post slug or post id.
Even stackoverflow show its database ID-s in URL. It could be surrogate key or natural, anyway you have to identify resource somehow. Basically, every single site use some kind of identification in URL, usually PK. Why do you think they use MongoDb ? It could be even relation database with GUID instead of Long PK
Even if you show someone database schema, nothing will happen, until you are protected from sql-injection.