Welcome back to the great RESTful framework showdown! If you have not read the previous blogs they can be found here. Today we will be taking a look at the core functions we need our RESTapi to perform and how the frameworks measure up, as well as what our developers think of the frameworks on the chopping block. Without any further waffle, let’s get into it!
Stage Two – Functionality Analysis
At this stage, each framework will be assessed at the high level as to if it provides the core functionality as described by the requirements. The main functions needed are a connection to the following:
- Optimal Data Engine (ODE) running under SQL Server 2014.
- DynamoDB
- Redshift
- S3 via the AWS SDK
- AWS Lambda
- Neo4J
- Other HTTP Endpoints
ASP.Net
Service
Comments
Compatible
Optimal Data Engine (ODE) running under SQL Server 2014Connection is possible from Linux based OS albeit with a more limited function set.YesDynamoDBAWS SDK for .Net Core is still in beta but is functionalYesRedshiftThis will require testing, there is no documentation for this in the current version of dotnet coreUnknownS3 via the AWS SDKAWS SDK for .Net Core is still in beta but is functionalYesAWS LambdaAWS SDK for .Net Core is still in beta but is functionalYesNeo4JNeo4j driver works in .Net CoreYesOther HTTP EndpointsDotNet System.Net.Http ports it completeYes
Result: Tentative
AWS API Gateway
Note all these are connected from AWS Lambda triggered by AWS API Gateway not from API Gateway directly.
Service
Comments
Compatible
Optimal Data Engine (ODE) running under SQL Server 2014There may be an issue with connecting from python, but no issues from Node.jsYesDynamoDBEasy connection from Lambda, already used by OptimalBIYesRedshiftConnection is possible from python and node.jsYesS3 via the AWS SDKYesYesAWS LambdaAWS Lambda has no issue talking to AWS LambdaYesNeo4JLibrary supportedYesOther HTTP EndpointsYes, from both python and Node.jsYes
Result: Pass
Node.js based frameworks (Express, Restify, Loopback)
Service
Comments
Compatible
Optimal Data Engine (ODE) running under SQL Server 2014Supported via libraryYesDynamoDBAWS SDKYesRedshiftThis is done via the Postgres driver and as such is not ideal and likely to breakPossible Issue
S3 via the AWS SDKAWS SDKYesAWS LambdaAWS SDKYesNeo4JWorks through official supported driverYesOther HTTP EndpointsWorksYes
Result: Pass (with issues)
Python based frameworks (Django, Flask)
Service
Comments
Compatible
Optimal Data Engine (ODE) running under SQL Server 2014Connection works with configuration:https://msdn.microsoft.com/library/mt694094.aspx (We currently use python to talk to ODE)YesDynamoDBAWS SDK works fine and currently implemented in Optimal appsYesRedshiftPossible with psycopg2YesS3 via the AWS SDKAWS SDK works fine and currently implemented in Optimal appsYesAWS LambdaAWS SDK worksYesNeo4Jpy2neo supports neo4j connectionsYesOther HTTP Endpointsurlib2 a native library supports this.Yes
Result: Pass
Ruby on Rails
Service
Comments
Compatible
Optimal Data Engine (ODE) running under SQL Server 2014Possible through ODBC, but there are current issues reported and many people find the connection not possiblePossible IssueDynamoDBAWS SDKYesRedshiftPossible through the Postgres driver, which can cause issuesPossible IssueS3 via the AWS SDKAWS SDKYesAWS LambdaAWS SDJYesNeo4JSupported by multiple librariesYesOther HTTP EndpointsEasy for rubyYes
Result: Multiple Issues
Results
Framework
Pass/Fail
ASP.NetTentativeAWS API GatewayPassJava on SpringPassNode.js on ExpressPass (with issues)Node.js on LoopbackPass (with issues)Node.js on RestifyPass (with issues)Python on DjangoPassPython on FlaskPassRuby on RailsFail (Multiple Issues)
Conclusion
ASP.Net Core is a very new system and not every aspect is tested, as such redshift connection is unknown. At this point, OptimalBI does not use Redshift and has no plans to so this is not an issue and can be resolved in the future.
Ruby currently has issues connecting to SQL Server from Linux. This is enough of a concern to not pass Ruby through to the next stage as ODE is a core component of OptimalBI’s work. This is likely to be a current point in time issue which will resolve itself later but a concern for now.
Stage Three – Development Resource
In this stage, we look at which developers at OptimalBI are likely to develop parts of the RESTapi. The main things we are looking at here is the time it would take people to learn the new framework based on their current knowledge.
Scott Willan
Scott mostly lives in JavaScript land writing front end code. He has had some previous experience with Express (and due to design that knowledge translates to Restify). When he looked at Loopback he was not impressed with the lack of flexibility and the confusing change between the UI and code, as such he would prefer not using Loopback.
Scott has some previous Java experience so using Spring would not be an issue and he feels that this experience would allow him to learn C# and ASP.Net easily enough.
Ruby on Rails should be no problem due to a previous project Scott was a member of.
Scott has minimal python experience but enough to comment on Flask, saying that it was simple enough to understand what was going on. He did not like Django as it would be far more complex a tool than what we needed.
Sarah Habershon
Sarah is very comfortable with the development of APIs on Ruby on Rails. This knowledge gives her a starting point for developing python, in which Sarah preferred Flask for its simplicity and comparative functionality to Sinartra (ruby). Sarah has no desire to learn Java and as such Spring would not suit. Resitfy and Express were frameworks that appeal due to their simplicity of development access while Django and Loopback were too complicated with too much superfluous functionality. Kotlin also does not interest Sarah as an alternative to Java for Spring.
Results
So we know what Sarah and Scott think of the frameworks on offer here. Their comment means that we will be dropping Django, Loopback, and Spring from the list of frameworks. This leaves us with ASP.Net Core, AWS API Gateway, Node.js on Express, Node.js on Restify and Python on Flask.
So that’s it for this edition of the great RESTapi Framework Showdown. It might be a while for Part 4 as we are looking at how well each remaining framework interacts with our SAML secure framework. Stay tuned for that!
Coffee to Code – Tim Gray
Tim blogs about the sharp end of code and the languages it is written in.
You can read Tim’s “What’s The Best Restful Web API Framework” Part 1, Part 2, Part 4, Part 5 and Part 6 to get the whole picture.
