Skip to content
This repository has been archived by the owner on Mar 14, 2022. It is now read-only.

TACO Language & Framework Selection

Christina Harlow edited this page Apr 2, 2018 · 1 revision

TACO Prototype Language and Framework Selection

This outlines and presents the criteria and rational that was used by the TACO Prototype development team for initial language and framework selection.

Guiding principle

We will be developing the prototype in the cloud with a specific focus on serverless deployment. However, we are committed to being "cloud first but cloud neutral" in our design, implementation selections, and work.

Wants

The following is a list of desired abilities of the deployment strategy that were used to inform language selection.

  • Polylingual
  • Serverless
    • Move away from individual machine/vm maintenance
    • Fallback: containers (i.e. docker) is also acceptable
    • Targeting AWS ECS (elastic container service)
  • Compiled language [particular emphasis on Go - to allow neutrality] that makes static linked binaries
  • To avoid java (performance issues, support, team currency, rapid delivery issues, testing on local machines)
  • Continuous Delivery (integration and deployment)
  • Swagger support
  • Parallelizable
  • AWS Support —> (notably that ruby presents several AWS serverless issues and a lack of lambda support
  • Rapid development and delivery

Available Options

  • Go
  • Java
  • Node
  • Python
  • Ruby

Selection Criteria

  • Maintenance Concerns (with an ops-y focus)
  • Usability of code for colleagues
  • Existing support within language
  • Extensibility
  • Testability
  • Speed / Performance / Scalability
  • Ease of deployment
  • Cloud Neutral (But cloud first?)
  • Local “test” deployability
  • Want to learn
  • Bus ("write once") factor

Selection

Based on the guiding principles of the prototype development cycle, and the selection criteria outlined above, the development team has selected Go as the language with which to develop phase 1 of the TACO prototype.

Notably, this selection allows:

  • Small amount of code to write per component
  • Not a radical departure from Ruby
  • Easier to learn because explicit
  • AWS Support
  • Robust libraries
  • Similar origin needs to ours
  • Cloud neutral via docker containers
  • Built in test framework
  • Deployment via binaries

Framework

Based on the selection of Go as the language for this project, we reviewed the Gin framework for our application framework.

However, working with Swagger 2.0 specifications and the [go-swagger] library, which allows specification-driven API code generation, led us to not using a framework library for our TACO API prototype.

TO DO / ACTION ITEMS

The team will be establishing and documenting development and deployment practices (based on existing practices) within the selected framework.