Welcome to Part 6, The final part of the great RESTful API framework showdown! Last time we had a look at the pros and cons of each framework isolated from the other frameworks. Since then we have had a busy ol’ time in the office but finally, we have time to finish this off. Today is the final stage of the RESTful API framework showdown!
What are we looking for?
When doing a big research story to find out what technologies we should be using for certain tasks it is always good to remind yourself why we started this in the first place. We started this blog series because we wanted to pick the best REST API framework for us here at OptimalBI. This meant that we had a go to piece of technology that we would use every time we needed to build web applications. Here are our original requirements
Lightweight
We love to run stuff in the cloud (AWS), and we like to run stuff properly in the cloud. This means that the applications we are running should run on small servers with limited memory and CPU time. When more capacity is required more tiny servers are spun up to handle the load. This is what being cloud first is to OptimalBI. When we choose pieces of technology that we are going to use in many of our applications we always keep in mind that the technology must work under these limiting circumstances. Most of the frameworks we considered met this requirement, with the possible exception of Spring on Java. As Spring never made it to that stage of testing we will never know.
Security
Web-facing private technology should always be secured. We have an existing security framework at OptimalBI that uses the wildly hard to integrate SAML protocol. As a result, all of that web frameworks need to be able to plug in into this without 6 months of library writing. ASP.Net Core failed this stage at the time of writing (although this issue has been fixed now) but all our other frameworks passed with relative ease.
Preexisting Knowledge
Learning how REST API’s work takes its time, if we also have to learn a new language or a whole new way of interacting with a language to use a framework then this add more time until we can get up to speed as a development team. As such when you are picking a framework existing knowledge should always be considered. After consulting with the other developers in the office; Spring on Java, Django on Flask, and Loopback.js all got the chop.
Compatibility
We use a number of SQL and NoSQL databases to store stuff, and storing stuff is very important for what we do. As a result, the languages that we use have to be able to talk to the databases we use. After research, only Ruby on Rails had issues with connecting to things it needed to connect to and as a result was shown the door. (As far as I can tell these issues are mostly resolved for Ruby now).
Maintainability
Everything we build as developers need’s to work for a long time and be improved over that time. Building technology in a maintainable fashion requires a little help from the language you are building it in and should be a consideration with any selection. None of the languages we look at failed this requirement, but JavaScript did get a small slap on the wrist for its “let the developer do anything” ways.
Honourable Mentions
ASP.Net Core
As time goes on ASP.Net core’s functionality improves. Since our last look at it ASP.Net has improved many of the issues that we had and is now a strong contender. The major thing holding it back is that it is still hard to google issues that you may have as either an old ASP.Net version appears or nothing appears at all.
Go (GoLang)
People keep mentioning Go to me. It has always been on the list of things that I need to sit down and learn but I have yet to have the time to do so. As a result, we have no one in the office with any experience in Go to consider it in this research.
Ruby on Rails
Some developers are Ruby people. More and more developers are not these days. That is fine. Ruby does the job of being a web first language very well and does it in its own sparkly Ruby way. If you have a Ruby inclined development team then Ruby may be the language to go with for you. If you do select Ruby (or JavaScript, even Python to some extent) then make sure your internal processes for creating good, readable, maintainable code are in place and you feel comfortable relying on them.
And the Winner is…
Express on Node.js! No one is surprised here. It passed all our testing stages with flying colours. The only drawback with using Node.js is the fact that JavaScript can lend itself to some really terribly written code. This issue can be handled with hiring competent developers, having good internal process, and peer reviewed code (Typescript anyone?). Drawbacks aside, Express impressed us with its flexibility, the range of third party libraries, and its ability to tackle issues in a small amount of code. Node.js’s package manager is also the best in class (take note Python) which helps us in a huge fashion with any dependencies that we need. And that all I have to say on the matter! In a few months, we will report on how Express and its friends are working for us here at OptimalBI. If you think we missed a big framework or if you have any questions then drop them in the comments!
See you next time!
Coffee to Code Timothy Gray, Code Conjuror
You can read Tim’s “What’s The Best Restful Web API Framework” Part 1, Part 2, Part 3, Part 4and Part 5 to get the whole picture.
