Yesterday I wanted to build a quick prototype that would scale for some hundreds of users. I needed realtime notifications, scalable backend, geofencing queries and something easy ti build the REST interface that I had describe in RAML.
You may have several opinions on that matter, but ninety percent of the times I go with the python solution.
Our main goal was to experiment with an idea about a potential start-up, but before we go there we needed to make sure than an MVP would be on place. An MVP is something simple, showcasing the functionality of what you expect to be your core value. So in order to develop one, you need to have a clear state of mind and follow some simple guidelines.
The MVP approach relies on the following guidelines:
- Build a minimum set of features that enable you to gather feedback from visionary early adopters.
- Build only what is required.
- Release improvements to the product (product iterations) quickly and inexpensively as you learn about your market and your solution.
That’s all. There is no extra philosophy, no economic or marketing parameters nor anything. Just keep it simple and focus on the core idea.
The Backend Decisions
In order to develop this MVP we had already decided on the language and the framework which is our case was Flask. Flask is already mature enough, nice also for quick prototyping but when I think about production, django is my religion.
Flask comes bundled already with various extensions to build an API, and I only list below some of the most noteworthy:
As for the backend, we needed something that could scale, easy to handle and super cheap. Obviously setting up a database on a server, either any sql or no-sql was more expensive than connecting to any cloud service.
The options that we also wanted to experiment with were the following:
- Add Search, Time-Ordered Events, Geospatial or Graph Queries Fast with a REST API
- Hosted Search API that delivers instant and relevant results from the first keystroke.
- An API backend, including data storage, user authentication, static hosting, and more.
Finally, after a experimenting a bit we chose firebase, mostly because of its nice url-like storage/access scheme. Totally a personal preference, but I truly love it.
Here I am only briefly going to discuss our decision on realtime notifications. There are already so many articles to study about which is the best approach and solution on this matter, that I don’t want to be part of this debate.
When I have to implement something related I usually choose either pusher or pubnub. This time we decided about pubnub because it was a strived focus onto geo-spatial characteristics that we looked for. They also have nice python libraries and toooones of examples and as in most times nowadays, there is also a github repository.