My Current Software Stack in 2019
and the 13 Reasons Why
I’ve been seeing a lot of arguments in my social feeds recently about which software stack is the best. These arguments usually revolve around performance, ease of use and community backing for a specific stack. It is important to point out that there is no such thing as a perfect technology stack, and it varies from person to person, with personal taste and preference being the key deciding factor. I decided to share what I’ve been using for the past two years, with the reason why I picked what I picked.
Over the last two years, I’ve been running RedSquare Technologies where we serve startups, corporates and government agencies. But regardless of which type of entity we serve, the job often involves quite a bit of design, business consultation and creating products from scratch for ideas that are not yet mature. So for me, familiarity, flexibility, speed of iteration, and keeping developing costs low and agile are key. The decisions I made were driven by the aforementioned principles.
Since my profession involves a lot of rapid prototyping, I needed a quick to launch framework with minimal setup(Reason 3). Throughout my career, I’ve used Rails, MEVN, Django, and Laravel. Django is written in my primary language of choice, Python, so I naturally gravitated towards that. It comes out of the box, setup with a really good admin panel, and when used with Cookiecutter Django, comes with a really good Docker setup and only line deployment. I have yet to see a faster, easier setup than this. I also noticed that companies who I often read they tech blogs, namely Instagram and Pinterest provide me clear ways of implementing new things with Django (Reason 4). There are certain services that might require a little bit of lower latency and unstructured databases. Django doesn’t do unstructured databases well (Reason 5), so my second choice is Express-MongoDB for some uses cases.
So, Django-Postgres primary, Express-MongoDB secondary.
This is a tough one. Since the choice to use Django was already, the ReST vs GraphQL was particularly hard as Django has amazing tools for both ReST and GraphQL with Django ReST Framework and Graphene respectively. However, given the high iteration speed often required by my clients, I recently started using GraphQL. It provides me with huge flexibility on the front end because I can define the type and shape of the data I want without touching the back end (Reason 6). When I was doing ReST, I found that every time I needed a specific shape of data, I needed to write a new end point. With GraphQL, the way I work is to create a master endpoint with all possible data query-able, with business model restrictions of course, and then define the exact data I need in the front end query. This is not recommended for sure, but since we mostly work on new unproven products, getting it done cheaply is better than doing all possible best practices. There are exceptions to this rule.
So for now, it’s GraphQL above ReST.
Hosting & Monitoring
It’s a lot easier for me to get my clients approved for the $5000 AWS starter credit(Reason 11), so I use AWS for hosting. I run my application, database and web server in an EC2 Ubuntu instance with Docker. There are some instances where I only run the the webserver and application in EC2 and use RDS with PostgreSQL to host the database, but I’ve found this architecture to be at least 2x more expensive. It’s cheaper to run your your database in EC2 and schedule in backups to S3 with a cron job. MongoDB is a different story, since they have a bad track record of loosing data, I use mLab to keep someone else accountable for data loss(Reason 12). For smaller, personal, temporary projects I use Heroku.
AWS already gives me a lot of monitoring tools for the machine and webserver, so I mostly only write code to log my application errors. I needed something that is cheap, verbose enough to identify issue and works really well with Django. The simplest choice was Sentry as it comes with all these features installed with Cookiecutter Django(Reason 13).
Bonus: 3 Reasons to Not Pick My Stack
Python-Django developers are incredibly hard to hire (Reason 1). In Malaysia, PHP developers are easier because traditional CS degree teach it formally and there are a lot of Rails developers because it was sexy for coding schools to teach them. I train my developers from scratch so it is not a deal breaker. But if you are a larger organisation this can be a huge problem.
Although React Native has a huge ecosystem of libraries and tools, it is still lagging behind the libraries already present in native Swift and Java (Reason 2). I’ve personally not had this problem yet, but if I did, the workaround is to use Native Modules in React Native.
React by itself is probably the hardest to learn of the big 3, the primary culprit being JSX and the confusing lifecycle methods (Reason 3). Vue is very beginner friendly and Angular comes out of the box with a lot of features maintained by the core Angular team. If I was only writing web apps, I would pick Vue or Angular. But I don’t, and React seems to save me a lot of time writing code especially when mobile apps are also a requirement.
There are other things which I use in my stack that didn’t get a shoutout in this article, maybe in a future one. A lot of these decisions comes from personal preference, experience, business needs. This is not me preaching what the right stack is, just what is the right stack for me, at this moment in my career.
Let’s start a conversation. Leave your comments below on what your software stack is.