TL;DR
In backend web development, choosing the right backend framework may not be as easy as it seems. Here, I'll explain how to do it with a case study.
In backend web development, choosing the right backend framework may not be as easy as it seems. Here, I'll explain how to do it with a case study.
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."Or:“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.
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:
The downside of that would be the maintenance of long-living backend 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.Just kidding!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:
We had the following agenda for our first meeting.
Rules for our coding phase:
People chose the following languages and frameworks:
Below is the list of programming languages, frameworks and micro frameworks:
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.Sadly there’s no interest in analysing Ruby code. To my disappointment guys have chosen programming languages that are commonly used in Apptension, meaning: Python and Javascript. At least our small PHP community has chosen to exercise Python.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.
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.
Explore our collection of insightful blog posts.