How we chose the Plytix technology stack and why we love Python

green python

November 13, 2015 | by Alex López

In this article our co-founder and CTO, Alex López, introduces us to the fascinating world of programming and the practical challenge of choosing the right technology stack for your development project.


 

Coding, and especially software architecture, has a lot to do with expectations. You don’t face a minor ad hoc project the same way you do a big challenge. And you shouldn’t. Why spend hours thinking of a high availability solution for an application that will only be accessed by a single user at a time? Less can definitely be more and well-handled expectations are crucial to efficiency.

In Plytix we’ve aimed for scalability from the very beginning and we work under the assumption that our system will be exposed to huge volumes of traffic in the very near future. That kind of assumption, of course, deserved a proportional software design and development effort, which we have indeed invested in from the very beginning.

However, there’s one question that comes up even before you write the first line of code. Answering this question means making one of the biggest decisions in the whole software life cycle: Which technology stack should I use for my project? Making the wrong choice here would cause a lot of headaches in the future... on top of the headaches you unavoidably face, even when making the right choice.

 

Why we love Python

During my career, I’ve worked with a variety of technologies in different environments. From a sensors board on top of a RaspberryPi to huge web services. And each of these technologies has certain advantages that make your life easier in some way. However, when I get to choose which technology to use, I’ll almost always go for Python as the frontend driving language. I just love Python in so many ways, and my experience with this language makes me significantly more productive than when I work with other programming languages.

For me, the major question was the backend. On the one hand, Plytix was always destined to be a Big Data project with heterogeneous data, which fits a non-relational Database. On the other hand, the end-user application would have users, accounts, profiles, products… which really suits a relational schema.

 

Long-term vs. immediate needs

The decision came easily after evaluating the last big restriction: we needed a working prototype ASAP (welcome to the startup world!), and that meant discarding a solution with more than one database. It would just have been too much to handle multiple database instances from an early stage, no matter how tempting - regarding performance and good coding practices - it was.

So, we needed an NoSQL Database that was easy to set up, had mature drivers - at least for Python - and could be used for a traditional application (even with an ORM). On top of that, the database needed to have Big Data capabilities. You’ve probably guessed it already: I chose MongoDB. Of course, given how the project has evolved over the last year, MongoDB limitations pop up here and there and make clear the need for other solutions, including using several (different) Databases. But, looking back, I think we made the right choice, and I don’t regret it for one second. At this point, we have the resources to face more complex setups, but without the initial simplicity we might have never gotten this far.

 

What does the Plytix technology stack look like?

To wrap it up, allow me to present the complete technology stack we use at Plytix and explain why we chose each of these technologies:

Frontend

Python-Flask. It’s not just that a developer can learn Python and be productive in a few days, or that Google chose it as one of their heading languages. Python is both powerful and beautiful. Powerful because it allows you to do much more with the same lines of code, and it runs fast. Beautiful because Python code is inevitably clean and easy to read. The fact that paddings have a semantic meaning (they define code blocks) is something you can’t help falling in love with.

Why Flask and not Django, you ask? This web development micro framework gives you all the tools you need to be up and running super fast in web development without compromising efficiency and leaving all the control in your hands. I think Django is great, but for a project like Plytix I preferred the freedom and lightness of Flask. Particularly, I didn’t like the fact that Django is ORM oriented by default (and built thinking on SQL solutions). Flask default installation comes with no database driver; from the very beginning you just choose the extensions you want to use.

Fronted UI

Bootstrap. One of the best front end frameworks you can use if you want a practical and responsive admin panel with fairly little effort.

Backend

MongoDB*. As I explained, we started out using MongoDB for everything. After the prototyping phase, we split our database:

- One for the application models, which we’re still keeping in MongoDB.

- One for “raw” data reception, which we’re optimizing for fast writing.

- One for aggregated data consulting, which we’re optimizing for high availability (read). We pre-aggregate data to this database from the previous one on a daily basis.

Regarding the two last points, we’re currently discussing which Databases to use.

Until now we’ve avoided the worst headaches, and hopefully our experience can help you avoid some headaches, too. That said, choosing a technology stack will always to some degree be a question of personal preferences.

 

What do you think?

Do your agree with what we chose, or would you have gone for different technologies?

Alex López
Written by Alex López

Join the discussion

Like our articles?


Subscribe here and get featured content sent directly to your inbox once a month.