000 system structure

Structure for running eRegs in cmcs

proposed

Context

eRegs will be deployed under the MACPRO umbrella. This means that certain aws resources and existing tools will be available to run the system. These include aws lambda, s3, api gateway, and aurora.

Decision

Regulations Site:

API Gateway: Will route browser requests to the regulations-site lambda.

AWS Lambda: Will run the regulations-site system. It will communicate with the regulations-core API Gateway for data.

Amazon cloudfront: Will serve the assets for the regulations-site web pages. (css, js)

Amazon S3: Will store the assets for the regulations-site web pages. (css, js)

Regulations Core:

API Gateway: Will route requests to the regulations-core lambda.

AWS Lambda: Will run the regulations-core system.

Amazon Aurora: Will store the parsed regulations and context information that is managed by regulations-core

Consequences

The conceptually singular regulations-site website will be spread across multiple resources. So while reasoning about the user interface it can continue to be thought of as a single system, during deployment and configuration the disparate resources will have to be taken into account.

• Static assets will be built and stored in s3
• Cloudfront will be configured to server static assets
• regulations-site django application will be configured to point to the configured Cloudfront
  • This requires consideration of the domains each piece is served under.
• Static assets can be easily swapped and updated without updating the python application

Django is traditionally run by something like nginx or apache web server. In the serverless case this is worked around by using the serverless framework and their logic wrapping Django's wsgi.py behavior.

The question of how to run migrations against the database remains open.