In backend web development, choosing the best backend framework may not be as easy as it seems. Here, I’ll explain how we approached this issue at Apptension with an exercise case study.
Some thoughts a software engineer might have:
“There are too many backend frameworks.”
“Backend developers are too different, only consensus can save us.”
Here, at Apptension, a primarily frontend software house, there are not many backend developers.
Recently, we’ve started a mentoring process and picked learning about backend frameworks as the first meeting topic. Read more about our motivations, the exercise and an office event that we organized.
Motivation: Why should you choose the best backend framework?
You are a part of a startup, software house or what-do-they-call-us-these-days.
Every IT company will eventually face this problem: engineers with different programming languages or framework backgrounds.
You land a new project to build and you get to choose the technology. It requires two backend developers. Let us see… Who is free/bookable right now… Great, one PHP developer and one Python developer.
What should you do?
You will probably evaluate who is more experienced and choose his main programming language as the implementation language. Or maybe you decide to start with one programmer and wait for another project to finish so that you have two people with the same background?
What if you had a cyclic framework choosing process? You wouldn’t have the problem. Benefits:
- Every backend developer would work on the same framework during some period of time.
- Estimations would be easier.
- Quality wouldn’t suffer on the project start.
- Reviews would take less time.
- Products could be delivered faster.
The downside of that would be the maintenance of long-living projects written in different styles.
How could this process look like?
It would involve cyclic meetings with all the backend developers to discuss the technology guidelines for your company. Discussions should be preceded with exercising new solutions on typical use cases. You would then test the choices on some small project (preferably for internal use or just as a challenge) to verify applicability of the new guidelines in production environments.
Forcing yourself to do everything in one run is the best way to burn everyone out, so better take your time during this process.
What do we need a backend framework for?
A router, views, models, database queries, controllers, validation, serializers, tests, configurations, error reporting, integrations, profiling and so on.
We focused on the most crucial components and explored them in a new web framework during a programming exercise.
We want to enable the developers to test their new and shiny implementations against some specifications. They should create an application container to allow others to check whether their solutions work correctly. Ideally we would also have a list of commands used to generate the application for tutoring other. Finally, we want to put those things in a repository or make a presentation as a discussion opening.
Eventually you want to know which implementation is the fastest, right? Well… go for C or Rust then.
It is cool when you can deliver something blazingly fast, highly concurrent and scalable but if your client can do without it other factors are more important. Call it deadlines, maintainability or as some proclaim it might be developer happiness.
I prepared a sample exercise called Timetension. Later on the whole backend team created a sensible backend frameworks list and gathered during an office event.
The list of frameworks we wanted to explore was chosen using those guidelines:
- the one you know the least is the best — avoid frameworks you work with everyday
- new language — you want to get out of your favorite language sandbox
- if not maintained continue — do not choose software that is not actively maintained
We had the following agenda for our first meeting.
- Mentoring organisation
- Exercise introduction
Rules for our coding phase:
- ask me anything — you are free to interact with other folks during the exercise
- tension or defeat — there is very little time to create working solution so do not waste it
- we are here to have fun
People chose the following languages and frameworks:
Below is the list of programming languages, frameworks and micro frameworks:
How it went
During the meeting I found out that even 6 people can make a lot of noise and it’s very hard to make decisions about the further meetings if there is no chosen voting structure. You better have leaders or some rules, otherwise deciding on anything is a pain.
Presenting the whole exercise was hard for me because the group wanted to jump straight into coding. It’s important to choose between great exercise documentation or spoken introduction adjusting to your team needs.
Docker was a pain for people who usually don’t do deployments. Especially the database connection. You just want to store some data and then you find out that eventually a second service is needed in your docker-compose.yml file (which saves time passing arguments to docker program on the command line), then a SQL script for initial database settings. Even though you have it all the app says it cannot connect to the database on start because the database service in the database container hasn’t started yet. You write a workaround and notice how much time you have spent on it. And you also want your database time zones to be correct.
We all know how Debian package management works but, being on Mac OS all the time definitely did not help. Our PHP guys were deciding which Python version to download and we advised them to use Python 3. We also had to install the framework dependencies and it took us some time doing things like: how do I specify a dependency, its version; how do I install, update, reinstall packages; where are the downloaded packages.
What others said
I didn’t see sense in presenting code samples written in a language that might not be known to everyone. It makes more sense for me to present the exercise more thoroughly with boundary conditions rather than jumping through project code.
It took me a great deal of time setting up Docker for my Python app, because it was my first experience with Docker. I’m in love with Docker now.
I used Python for the first time, and now I love it! After the meeting I bought a book about Python and I’ve started learning. In regard to Docker, it’s a powerful tool adding much value to the development process in our company.
I used Tornado framework along with Docker, docker-compose and PostgreSQL. It took me sometime to connect the Tornado app with uWSGI (got it working without the async module). I did not find dedicated SQLAlchemy package for Tornado (like e.g. Flask-SQLAlchemy for Flask) and it made me spend more time on configuring database connection. The exercise was pleasant and depending on the chosen framework might have been a challenge.
Not enough time:
For the meeting and for finishing the exercise season.
Christmas time hit us hard and now we have hard time going back and finishing the implementations.
Three of six guys finished their implementations; the team is looking forward to next meeting about Docker rather than going back because it was so long ago.
Next time our exercises will be shortened to the minimum to ensure that everyone finishes with the group rather than alone.
Docker takes time:
DevOps is very different than writing code and switching context does not help. Having dedicated people doing devops tasks might speed up your development process significantly.
Writing code together builds the team:
We mostly work in pairs or lonely on projects and coding with a larger group certainly was fun, entertaining and social.
One room means better knowledge sharing:
It just works.
Thanks for reading! Please share this blog post if you liked it. Hopefully you will visit us another time again.