There is no such thing as the perfect stack. Every application has different requirements and your stack should be adjusted accordingly. For Sjauf, I have the unique opportunity and responsibility of creating our stack from the ground up, with a legacy application to keep running for our old applications. Designing this stack was a beautiful challenge and it taught me a lot. Let me take you through my process.
Current stack and our requirements
When I joined this company, all we had was a proof of concept. We had iOS apps -- written in Swift -- that communicated with a Python/Django API. While there's nothing wrong with that stack choice, it was far from perfect for our requirements.
First off, Swift is great for iOS apps but for some reason we couldn't get it to compile on Android. We needed a single codebase that would work on both Android and iOS, preferably without ever having to write any Swift or Java. We're still a small startup so we don't have the resources required to write entirely native applications for all our platforms.
Secondly, I didn't know any Python when I took this job. I had read codebases and applied small changes to applications built in Python but I had never had to build or maintain entire applications in that beautiful language. I could've picked it up and continued to build on the existing application but if you're given the chance to build something to your own design, why not use the best possible tools? The code we were working with was subpar and most of it would need to be rewritten regardless of our choices in language/framework so we chose to drop it over time.
Lastly, we had one app communicating with one backend application. The monolith architecture works for a lot of companies but we have no idea where we might be in a year. We might become so successful we'll be forced to hire a whole slew of developers, or we might fail completely and be forced to pivot. Either way, a microservice architecture will make our lives a lot easier. Being able to plug & play entire applications means we can re-use most of our code in projects that have nothing to do with the private driver market.
Stack Choices
When designing an application, a lot of factors come into play. Almost every modern web development language/framework can do what their competitors do. Almost any language is a fine choice as long as you're comfortable writing it. However, when it comes to writing applications meant to carry an entire company and all their processes, I believe in using the right tool for the job. When we looked at our stack, a few items had absolute priority over anything else.
Future proof, ambiguous architecture
In my previous company, I learned a lot about the microservice architecture. Before then I was used to the monolith architecture many applications still run on today. Maintaining a single codebase is easy and offers you a lot of access to data all over the platform. With microservices, relational data becomes harder to implement and you're forced to be quite strict when it comes to separating functionality. However, using multiple small applications that run together offers much more control over your scaling, server analytics and feature refactoring.
In the past, I've had a lot of issues with inefficient legacy code. Having to rewrite entire codebases from scratch is not a good way to quickly improve your company's efficiency but with a monolith, it is sometimes simply required. With the microservice architecture, you can simply replace small pieces of your application, one at a time. For us this was an easy call, knowing we had to replace functionality in the existing monolith without being able to edit its code.
Our architecture consists of a gateway application that communicates with all our microservices. Right now that means it only communicates with our monolith but as we move functionality from that monster and into smaller, more efficient applications, the gateway will communicate with all of them, allowing our apps to only send GraphQL queries to one application. We also have an internal gateway that's used by the microservices to communicate with each other. They have much more access to each other's data but have to pass very strict validation.
Development speed
When you're as small as we are, you're working with limited resources. This means no languages that will give you a slight decrease in memory load or CPU usage if that means needing twice the time to develop an application. We choose our language depending on which functionality we're writing. Some microservices might be written in RoR while others will run on JavaScript. Most of them however, will be written in Elixir/Phoenix due to its mix of agility and uptime. (Plus, I'm really liking the syntax)
Coolness
Startups need to attract the best and most motivated developers. That means you need to offer them something cool and cutting edge. Since we don't have the money for nap pods or an indoor basketball court, we have to go with cool tech. Who wants to join a company that's working with PHP, MySQL and a REST API? While this was only a small factor in my decision making (efficiency, developer enjoyment and futureproofness are simply much more important), it did have impact on my eventual choice.
Conclusion
At the end of the day, you need to use what you feel comfortable with. Making websites, apps and desktop applications is hard and you need to make it as easy as you can. On the other hand, you need to make sure your software is efficient, clean and easy to add functionality to. Choosing the right stack can help you along but it's up to you to make it your own and create something truly amazing.
At Sjauf I work with incredibly trusting, agile and young people. We all want to make the best possible product and trust each other to do our parts. This means I had the freedom to choose my own stack and implement it exactly as I wanted, which is not something most people get to do. I've been fortunate as my previous jobs have allowed me to learn about a bunch of languages and frameworks. Some have become favourites, others I have sworn off forever.
What's your stack like?
Oldest comments (0)