Web app backend and API research

Platform Research

List of Evaluated Platforms

When evaluating the platform to host and run the back-end of the application there were two separate things to consider:

Operating System of the Virtual Machine
Service to host the Virtual Machine on

The three operating systems considered for use were Debian, Ubuntu Server and Windows Server. Once the operating system had been determined we then decided whether to use Amazon Web Services or Microsoft Azure as the service to host the virtual machine on.

Choice made from the Evaluated Platforms

For the back-end we chose to use Ubuntu Server hosted on the Microsoft Azure platform. The decision to use Ubuntu Server over either Debian Jessie or Windows Server was dictated mostly by ease-of-use for our use case and the support base.

Spinning up and configuring a Linux instance to host the back-end is much easier to automate in comparison to a Windows server instance. This is chiefly because the whole configuration and deployment process can be scripted from the command line, while it is harder to do on a Windows server installation.

The choice of Ubuntu Server over Debian Jessie as the favoured Linux distribution was primarily down to the support base and the set-up out of the box. Ubuntu Server has a commercial support base in Canonical [1] and free support in the growing community which use it to host their services in production. The set-up out of box is generally less convoluted as many system tools are installed by default and systemd is used at the default service manager.

The core reason behind picking the Azure platform over the competitors in that space was down to the client's preference. The two key factors for this preference were:

The client has access to a large number of pre-existing Azure hosting credits across the organisation.
Many of their other web services are hosted within their Azure organisation and they would prefer to keep them together for administrative purposes.

Potential Downsides

Being restricted to the Microsoft Azure cloud platform does mean that we miss out on the ability to use a cloud providers with a longer history of Linux environment and toolset support, such that they have their own distribution [2]. It is worth noting however that this is not as much of an issue as it might have been in the past and Azure is a perfectly good platform for our use case.

The main trade-off when picking to use a Linux server is not related to the Azure cloud platform, but is instead being forced to migrate to Windows if unsupported .NET tools and frameworks are required in future developments.

Language and Framework Research

Brief Evaluation of C++ Graphics Libraries

While researching methods to programatically convert and process 3D models, I found that many of the libraries able to work with the formats we are to use are for C++ programs. As most other languages are able to have interopability with C++ it was decided that to use the specialised libraries and require a stack which is able to use them through a C++ interface.

The two libraries which we are going to be using are Assimp [3] and the Visualization Toolkit (VTK) [4] library. The first of the two will be used for converting STL files to OBJ files, while the second will be for converting VTK files to OBJ files.

List of Evaluated Development Stacks

When evaluating what stack to use for developing and running the application three main options were considered: Java with JavaEE, JavaScript with node.js and Ruby on Rails. A key requirement was for interop with C++ to be easily achievable for reasons previously mentioned.

Pros/Cons of Java with JavaEE

Pros:

Can run pretty much anywhere with a JDK
Java EE specification means that there are guarantees about what is available between application server [5]
Java/C++ interop is present at the JDK level and is mature [6]
JDK version management is a non-issue in comparison to the others
Every team member has some experience working with Java

Cons:

Maven is very boilerplate heavy for a dependency and build management tool
Client wants to try and keep most projects using Electrode (Node based framework) [7]

Pros/Cons of JavaScript with node.js

Pros:

Many other projects of the client will be using it through Electrode
Vast number of libraries available for every task through NPM [8]
No requirement to switch language context between the back-end and the front-end

Cons

Many different solution for Node/C++ interop [9] [10]
The nodejs debugger is not full-featured [11]
Node version management can be a problem requiring a third party tool, node version manager (nvm)

Pros/Cons of Ruby on Rails

Pros:

Quick and easy to get a generic Create-Read-Update-Delete application up and running
The main dependency management tool, 'RubyGems' works well.
Setting up unit tests is convenient and integrated into the framework [12]
Native interop with C is present at language level and C++ interop is possible if bridged through C [13]

Cons:

Client wants to try and keep most projects using Electrode (Node based framework)
The Rails framework is very heavily scaffolded, making it difficult for inexperienced rails developers to do things it wasn't designed for
There is a large amount of boiler-plating for the framework
Ruby version managment can be a problem requiring a third party tool, ruby version manager (rvm)

Choice and Justification

For the back-end we chose to use a portable Java EE application server called Payara Micro [14]. The reason for picking the Java EE platform came down to a number of reasons: Platform-wide specification, mature libraries, widely available support and development speed.

Java was chosen as the development language for the back-end because there are many mature libraries available for the functionality required for the application. Any functionality not available in the Java ecosystem (namely working with 3D models) can be achieved relatively easily through the Java Native Interface. Another reason for the selection of Java is my experience developing with it over the other solutions, offering greater speed of iteration while developing.

The Java EE specification were chosen because it would allow future developers to more easily migrate the back-end application to another Java EE compliant application server if required, because the specification makes guarantees about what libraries and their interfaces are provided by the application server.

Payara Micro was chosen as the application server to run the application on because it provides many of the required libraries and deploying the application to it is as simple as running a single JAR file.