My Current Software Stack in 2019

and the 13 Reasons Why

Naven Prasad | RedSquare
Apr 17 · 6 min read

Prelude

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.

Background

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.

Programming Language

As a student I’ve learnt and used no less than 10real programming languages, mostly for internships, classes, projects and competitions. These main 10 are Ruby, JavaScript, PHP, Python, C++, Java, C#, Matlab, Prolog and LISP. Around my second year in University majoring in AI I had a desire to properly learn data science and Machine Learning (Reason 1). Python seems like the obvious choice, so I spent around a year understanding the depth of the language. When I became a fullstack developer, it was easy for me to pick Python as my preferred backend technology. There is also no running away from JavaScript for any kind of front end work (Reason 2), and because of this, JavaScript became my second language.

So, Python primary, JavaScript secondary.

Fullstack Frameworks

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.

API Architecture

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.

Frontend Framework

This was a bit confusing for me because nearly every 3 months I see someone publish their own JavaScript framework. Let’s just talk about the big 3 for now, React, Angular and Vue. I wanted a write-once-use-everywhere to save a lot of time and put the product out for Web, Android and iOS (Reason 7). With React and React Native, I can do that better than the other 2. The hardest libraries that I’ve had to find were maps, svg generators, UI libraries, charts, notifications, and video players. I’ve found near perfect libraries for React and have tested them to work well. Angular’s mobile framework is not as mature, with a smaller community and Vue’s is basically not existent with its mobile framework Weex being unusable. We still write truly native mobile apps with Java and Swift, but I’ve noticed that I can share roughly 60% of the code I write in React with React Native(Reason 8). Sure the performance of the app is 5–10% lower in React Native compared to truly native Android and iOS, but when it comes to maintaining a developer team and putting out product fast, its’ a lot easier to keep to codebase in React/React Native (Reason 9). Oh and there’s one more thing. When you publish an update to your app in React Native to the App Store, it doesn’t need to go through the strict approval process (Reason 10).

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.

Conclusion

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.

Naven Prasad | RedSquare

Written by

I help businesses innovate in the digital age.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade