Choosing the right backend framework

A few days ago, my team and I were discussing what backend framework to use for our final year project. Being familiar with a lot of the frameworks out there, I wanted to try something new but I also wanted to make sure this doesn’t impact our tight schedule. So I started brainstorming the things we look for in a framework and I thought why not share them?

1. It’s all about writing less code

The whole point of using a framework is not having to write everything from scratch, which will save you a lot of time in the process. How? let’s look at a real world example:

Let’s start with routing.

In short, a backend application is just a black box that listens to requests on a certain port of the hosting computer and respond with a response, and that’s all it is nothing more!

So imagine yourself writing a big switch clause based on the request path, HTTP method and body and returning the response for each case. Your code will grow in size and complexity in an exponential rate. We don’t want that to happen do we? now all frameworks have a routing library, but if you’re reading this article I assume you have the luxury to choose the framework you want, so let’s check a few key points:

  • Support for middlewares. In ASP.NET, Laravel and many other frameworks, routing is done via middlewares, if you’re not already familiar with middlewares check this out: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/middleware/.
  • Support for wildcards. So let’s say you’re building a blogging site and you want the URL of the read blog page to be the following: https://your_blogging_site/blog/{blog_id}, a wildcard is a placeholder that will be copied to your parameter in this case it’s blog_id, and most frameworks support this. So any request matching this form will be routed to your function accordingly.
  • Model Binding. Almost every request has parameters that will affect the response sent back to it. Those parameters can be embedded in the URL or in the body, but parsing those parameters in every route, we just don’t do that here! Fortunately, most frameworks has what we call model binding which will allow to transform those parameters into objects that will contain the data you need, in other words, all you need to do now is the logic part.

In my opinion, those features are very essential, and not having them in your selected framework will cost you a lot of time.

Authorization

Authorization is needed in any web application. At least there should be an admin with special permissions. Having authorization built in the framework itself is a huge advantage security wise and time wise. But being also customizable is a huge necessity. Because if you’re writing a RESTful API, you can’t use session based authorization.

That doesn’t mean if authorization is not built in, you shouldn’t use the framework. But it means that you should consider the time needed to write the authorization code, you can use JWT, a session/cookie based authorization a custom oauth token. But if you do write your own authorization code you need to make sure it’s secure and reliable (e.g. never save a user id, username or a password in the cookies).

Existence of a good ORM

As a developer, there’s a lot of things I hate, one of them is writing code on notepad and watching the “syntax error in line 344:62” in the console. Wait, what does that have anything to do with an ORM? ORM is short for Object Relational Mapping, and without an ORM, you have to write SQL queries embedded in order to retrieve data.

  • If for some reason you changed an column name in the database, you’ll have to find and replace each word in every SQL query you wrote.
  • If you changed your database provider, for example you wanted to switch from SQL Server to PostgreSQL for any reason that might be, some of the SQL statements will have to change syntax, even the find-replace feature won’t help!

I often think of an ORM as a strongly typed database querying library. Even though an ORM works by translating your strongly typed code to SQL statements, but it does that automatically with no effort required by the developer. And I think it’s important to mention some of the ORMs out there (Entity Framework for ASP.NET Eloquent for Laravel, Django for PHP, and a lot more…)

Programming language

We can talk hours and hours about the best backend suitable programming language. But let’s be brief, everyone has his own opinion, yeah I don’t like PHP, but I find Laravel one of the most powerful frameworks out there, so if you like PHP, you don’t have to use ASP.NET just because people argue that C# is better. But take into consideration the following:

  • Does your teammates know this language? If not how much time they need to learn it? So if your team used Xamarin for their mobile app why not just go with ASP.NET (both are C#).
  • Do you want a strongly typed or a weakly typed language? If you are a flexible person you’ll never be happy with the constraint a strongly typed language will impose on your project, so make sure you choose the language that suits your style, believe me it’s important.

2. Performance

So in the first part we talked about the need of the developer. Now let’s talk about the application requirements. But first let’s understand some important concepts:

  • If you have very high performance requirements it doesn’t mean you must write your app in C or C++.
  • Languages like C# allow you to run scripts from different languages, example: Python, C, C++… So if some module in your application require a lot of computing write it in C or C++ and call it from C#, you don’t have to write the entire app in C++.
  • Facebook itself was written in PHP!
  • The code complexity is more important than the programming language that execute it. If a function that runs in a linear time was a executed from Java it will still beat a function that runs in a polynomial time executed in C++.

So, only in rare cases the performance might affect the choice of your backend framework. But you must always consider this aspect.

3. Documentation and libraries

Documentation

A simple rule, a good framework has a good documentation. The way you can find out whether those features we talked about exists in the framework is if you check the documentation online.

An open-source framework will be mostly at your advantage but this also means that you have to be aware that if a bug exists, everyone will know about it (including hackers). But if your framework is maintained by a company like Microsoft, you most likely have nothing to worry about!

Libraries management

Libraries are made to be used everywhere in any project. People write libraries on GitHub that will make people life easier, so we don’t to write everything from scratch.

  • Libraries availability. Make sure some of the libraries you might use are easy to include in your project. After all, a framework is built by a set of libraries each one responsible for a specific task, so if something is missing a library can take its place.
  • Package manager. something to remember is that always make sure there’s a package manager that can be used. If you tell someone you’re using NodeJS without npm or yarn, he’ll probably think you’re insane! If you don’t use a package manager, you’ll be stuck with a huge “vendor” folder that you’ll have to carry everywhere in your version control repository and you have to update it yourself.

4. Deployment and hosting

If you’re like me, you probably won’t think about this step until you finish your application. And by now you should know that this is a huge mistake.

  • Online service can host projects using this framework. If you would to use online services like AWS, GCP or Heroku… Make sure they support the technology you’re working on, including the database.
  • Hosting price. You should be able to estimate it before you start developing your application. Is it cross-platform, can you host it on Linux? It’s probably cheaper than windows…
  • Front end templating engines. Does the framework you use provide an easy way to integrate a front-end application along with it? For example, ASP.NET has support for Razor Pages, Laravel has support for blade engine, you probably don’t want to host your front end site on a different server.
  • Does it have an easy way to host an SPA? If you’re a full-stack developer you’ll be probably using Angular, React or Vue, at this point a templating engine won’t be enough, and you’ll probably want to map your requests to an SPA.

Conclusion

If you’re using a popular framework, you probably have nothing to worry about. This can help you when you’re trying to decide whether to choose a framework that is still new or not that popular which was our case when we wanted to use the Aqueduct framework in our FYP.

I only put in this article the most important things when evaluating a backend framework, but I believe there is more so if you think I missed something important please make sure to leave it in the comments.

And finally, thank you for reading. I hope you got something out of it!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Omar Mneimneh

Omar Mneimneh

A software developer who is always eager to learn and share his knowledge