Deploy mljsapi, madliberationjs to a CloudFront distro with API Gateway and S3

[douglasnaphas]

TODO

• Run the API locally with SAM, from madliberation/. We're actually going to run with straight node, because incorporating SAM into the Docker setup is too hard, because SAM itself starts up a container
• Set up nginx config to reverse proxy from a port to another service
• Access the API (running with SAM outside of Docker) via port that talks to nginx. This will involve running sam local start-api with the --docker-network option. Won't do. There's no way for the nginx conf file to reference the out-of-Docker running API, at least not without doing container networking that I don't know how to do. Running with node is close enough to how it will be run in prod
• Run the API locally with SAM, Docker, and docker-compose.
• Try to run the SAM CLI Docker container from docker-compose. Try something like mapping the volume from madliberation/mljsapi.
• Add an S3 bucket.
• (live site) Add a div to the frontend on the About page containing the config values that I will inject, if they are present.
• (live site) Inject the values (api.passover.lol for the backend, and the redirect URI) that I need for the app to function normally, and confirm they are present in the attributes of the added div
• Switch the frontend to using the injected values, with the current location as default. Validate by observing the (failing) call on the new frontend to /scripts.

[douglasnaphas]

Reference

1. Using GitHub Actions and a private submodule.
2. Running SAM with docker-compose.
3. Running SAM in a container.

[douglasnaphas]

API Gateway might be better due to Lambda@Edge limitations

Lambda@Edge has some pretty concerning limitations:

1. Looks like function memory footprint is limited to 128 MB for viewer requests (I think that's what I'd be using to serve an HTTP API using CloudFront), which is too small.
2. Lambda@Edge functions have to live in US East 1, though of course they are replicated throughout the world. This is a problem because I might want to use different regions as a way to deploy to the same account with different configurations read from AWS Systems Manager Parameter Store.
3. Looks like Lambda@Edge functions can't use Lambda function environment variables. I currently use these for the NODE_ENV, but I might want to use them for other things, like parameters read from Parameter Store.

Now I want to see if I can use API Gateway without a custom domain name (thus using the CloudFront distro's TLS certificate) to proxy based on the path and route to, for example, my S3 bucket for passover.lol/, but API Gateway for passover.lol/api.

[douglasnaphas]

The following are sufficient (as of acaa69b) to run the API locally from madliberation/, with the MLJSAPI code living in madliberation/mljsapi/.

$ cdk --profile=doug synth --no-staging > dev-template-02.yml

$ sam local start-api --template dev-template-02.yml --port 3535 --host localhost

Then I can:

$ curl http://localhost:3535/public-endpoint
{"Output":"this endpoint is public"}