TACO Technology Selection Post WC Review

This page reviews our technology selections for the TACO prototype at the end of the work cycle. See the documentation and motivating factors for our original technology selections here: https://github.com/sul-dlss-labs/taco/wiki/TACO-Technology-Selection-Info-Page

Technology	Pros	Cons	General Notes
AWS dynamodb		Cannot handle empty strings Number casting for round-tripping is a pain need to use a custom marshal/unmarshal to keep empty arrays in the data for round-tripping[1] limited number of indexes available Need to transform our MAP into dynamodb structured JSON.
AWS ECS (elastic container service)	Deploys are easier than ElasticBeanstalk	We need aggregated logging, because we can't SSH into the container to check the logs
AWS kinesis		Shard management is a pain Limit on message size
AWS s3
CircleCI	Faster than the competitors. Enables CI/CD	Complicated to understand how it works.
Docker	Can spin up containers locally, exactly the same way they work in production.
Functional Reactive Programming (FRP) backend for processing	Encapsulates change: update the backend without having to change the frontend	Need a better logging infrastructure to understand what triggered a backend event.
Go (golang)	Fast! Pretty easy to learn Good docs	Need to build lots of the tooling ourselves.
go-swagger framework	Keeps the code honest	Doesn't support Open API Spec 3 features	It would work even better if we had a static schema.
Swagger 2.0 (REST API Specification)

1. The need to store empty strings, nulls, and empty arrays is related to the requirements for Updating a resource's metadata - i.e., someone may pass in an empty array to indicate a required deletion of the existing values in that array in the DynamoDB database record for that resource.