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
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.
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.
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.
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).
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.
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
And the Winner is…
See you next time!
Coffee to Code Timothy Gray, Code Conjuror