Unlike most established concepts and technologies we use today, NoSQL does not have a decade long lustrous history. Even the term NoSQL database was known only to the most dedicated and most knowledgeable computer scientists before the advent of social network age. Success of NoSQL databases in mobile app development and web application projects changed all that. Now developers and analysts instead invest good amount of time to rule out using NoSQL databases for every new project before moving ahead with SQL options.
Here at Algoworks we have seen an increasing rise in the use of NoSQL databases in mobile and web applications in the recent years, out of which MongoDB is undoubtedly the most popular one.
In our previous posts we have talked about
- What is NoSQL and Benefits of Using it for App Development
- Which is a Better Database for App Development: SQL or NoSQL
- Choosing the Right NoSQL Database Type for App Development
- 6 Things You Should Know Before Using MongoDB
In our last post we delved deeper into learning why MongoDB is more famous than its counterparts and is loved by app developers. As promised, today we will be talking about our professional experience with MongoDB in terms of service offerings, implementation methodologies and client response for the same. Let’s start.
Our Experience
Now even before we continue, it must be noted that of the 40+ projects where we have used MongoDB, I have hand-picked few of those projects which proved to be an exceptional learning experience for us where some or the other kind of shortcomings of MongoDB did come into the picture to ensure you take something fruitful today.
So let’s begin.
A Navigation Utility Application
About the App:
The application was targeted at commuters who were interested in recording their journey. The application had navigation features that connected with Google Maps and a GPRS service to provide the users a turn-by-turn navigation service. However the best feature of the app was its capability to record and store videos while driving. The users can also share the stored videos on social media platforms.
Why MongoDB? An unexpected advantage
The inbuilt geospatial features of MongoDB were what sealed the deal. In addition to that we found one more unexpected use – upon analysis of requirements we found out that storing videos in YouTube was a better plan (if we wanted to share the videos on social media platforms that is). It turns out that YouTube API plays with data in JSON format which can be easily stored on MongoDB. So yes, MongoDB indeed was turning out a better option for us.
How we used it?
Along with each video which the app saved, it also saved location based metadata, i.e. where exactly the video was taken, what direction, how far was nearest landmark etc. Geospatial features of MongoDB were great for the task. But as we said, the video itself was being uploaded to a private YouTube account so the database was used only for metadata and other user specific information. The database also saved the basic user profile in document format.
A Social Network Based Job Searching App
About the App
The app helped users to find new jobs by matching user profile with ongoing openings. The app fetches job openings data from a partner web service and had features to allow companies post jobs in the app environment.
Why MongoDB?
Our client was not very comfortable with the idea of building fixed format user profiles like what was prevalent with Facebook and other social networks at that time. Therefore we chose document database to store schema-less profile information. MongoDB was used because of its commendable performance in query searches. In our previous post related to MongoDB we talked about a particular experiment we performed to test MongoDB’s performance. It was this app for which we did it. We were going to use a document NoSQL database and settled on MongoDB after testing its performance and its ability to scale up fast.
How we used it?
Once again location was important for finding job matches so we used the database’s location features. As you may have guessed we stored user profiles as documents. The app became popular very fast, so we had to cluster several servers to improve performance. Once again we found that MongoDB was easy to use in clustered environments and was very easy to use in load balancing. We also found that MongoDB was not great in storing connections. So we had to use GraphDB to store friends, friends of friends, and other social network relations.
Video Calling Social Network app
About the App
The app was new social network with robust inbuilt video calling features. The app also allowed users to record and save video conversations or share device’s videos.
Why MongoDB?
By now we were convinced about MongoDB’s performance in social network, especially in storing profile information so we once again went ahead with the database. For video calling features in the app we were using WebRTC. The WebRTC platform uses JSON heavily in signaling and messaging. So MongoDB was a good choice to complement WebRTC.
How we used it?
Except for the obvious use of saving profile information and saving conversation threads, we used MongoDB to store videos as well. But here’s where MongoDB became a headache to use. MongoDB cannot save documents bigger than 16MB. So we had to use a chunking script (GridFS) to split data into 16MB pieces, and then stitch them back every time they were requested by user. It reduced performance a bit but we were committed to the database by then so we went ahead anyways. The possible solution to this problem is to use a third party solution, like YouTube, to store videos (like we did in the above app). Also, as mentioned earlier, MongoDB alone was not easy to build a social network so we used a Neo4J graph NoSQL database to manage friends, friends of friends, and other relations.
Selfie Rating App
About the App
This was a photo sharing and social networking mobile app that gave its users a platform to share their photos, more specifically their selfies. The main USP of the app was its feature that broadcasted the photo to all users following the photo taker, and all those following the tags inserted in the photo. The users can also like or dislike the photo and the app had a feature that displays featured selfies based on the ratings.
Why MongoDB?
Apart from the above mentioned points of MongoDB’s performance in location based social networks, the database’s inbuilt features to handle Javascript Technologies was what made us use MongoDB. The whole backend of the app was built using NodeJS and ExpressJS, and the frontend had AngularJS features. We found that combining the JS technology with MongoDB was giving better performance than SQL counterparts so we went with it.
How we used it?
MongoDB was used to save profile information, and metadata associated with each selfie like location where the image was taken, date, time, user, tags, etc. The main problem that we encountered here was how to calculate in real time the most popular selfie. We can save the rating data in each photo’s document but for listing the most popular photo we would have to navigate all the images and fetch rating data. Running this type of specific query in a SQL database would have been easier and faster. We overcame the problem by running a cached array to store the most popular photo in real time. We found that this way was easier to execute and was even faster than SQL options.
In the end, it is all about the use-case
One thing that would be clear with these examples would be that using MongoDB is not the only option. It’s all about your requirements. MongoDB is great if your app can work in a schema less environment. However it has its shortcomings as well so you would have to be careful where you use it and how. In many cases MongoDB alone is not adequate so we can mix it with others, but again it’s about use case. From the above examples we did learn that using MongoDB has obviously made the task simpler, but of the shortcomings that were faced were actually specific cases and none of which can be generalized. Experts can help you figure out what possible concerns you must have in your implementation and can help you decide before-hand the best step forward.
If you are having troubles in finding out whether you should go with MongoDB or not, or whether you should go the NoSQL way or not, don’t hesitate to contact us.
Rachit Agarwal
