Software & Deployment Architecture

[mrcrilly]

We need to decide two things:

• How are we going to architect the software, including code base layout, libs, etc.
• How are we going to deploy the software and what will it look like, such as Serverless, AWS services, etc.

This doesn't have to go too deep. For now, we need a guide to work along and keep us focused, versus picking up some technology at the point of implementation and implementing it at random. That being said, we're also not setting in stone the technology choices here, although some of them are pretty good selections and are unlikely to change.

The overall architecture is:

• Individual models in their own Go packages, abstracted enough to be Lambda or binary
• Individual models and logic as a Lambda, supported by a single endpoint in API Gateway
• A single DynamoDB Table backing each model
• Serverless for deploying all functions into AWS Lambda

Software

• [x] Code base structure and packages
• [x] Make sure each package can be hosted as a Lambda or binary
• [x] Select libraries to use and keep it consistent
• [x] Use dependency management
• [x] Write a common Lambda handler for each package
• [x] Decide the HTTPS endpoints will each model deal with: Profile{} => /profile?
• [x] Consider the database (DynamoDB) usage per model: what does the table look like?

Libraries

A small list of libraries that will likely be needed:

• httprouter for standalone deployment
• Viper for configuration of standalone deployments
• dynamock for DynamoDB mocking in tests
• moq for mocking custom interfaces
• gotests for generating table-driven unit tests

Use dep to manage these packages.

Deployment - Serverless

• [x] A single serverless.yml file for pushing everything should be simple enough
• [x] Ensure it supports injecting an environment/stage name to allow for multiple deployments

[mrcrilly]

Let's consider Gandalf and mmock (https://github.com/jmartin82/mmock) for doing our API contract testing.