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"}

[douglasnaphas]

I'm widening the scope here to include the front-end madliberationjs, because it will be the default origin for the CloudFront distro.

[douglasnaphas]

I need to set index.html as the default object on the distro.

https://d2zor2cnxtxt2r.cloudfront.net/index.html#/

[douglasnaphas]

https://www.rehanvdm.com/serverless/cloudfront-reverse-proxy-api-gateway-to-prevent-cors/index.html

[douglasnaphas]

Here's a nice piece of progress.

$ curl https://d2zor2cnxtxt2r.cloudfront.net/prod/
{"Output":"Hello World!! "}

$ curl https://d2zor2cnxtxt2r.cloudfront.net/prod/public-endpoint
{"Output":"this endpoint is public"}

[douglasnaphas]

New mode of interaction at https://d2zor2cnxtxt2r.cloudfront.net/#/. fetch("/prod/public-endpoint").then(r => r.json()).then(j => {console.log(j)}); works, so the frontend doesn't need to have a backend URL specified.

[douglasnaphas]

I think I need to set up the existing prod env of passover.lol to have the routing-through-CloudFront approach, because of this in MLJS Configs:

  static apiUrl() {
    if (process && process.env && process.env.REACT_APP_MLJSAPI_URL) {
      return process.env.REACT_APP_MLJSAPI_URL;
    }
    return 'https://api.passover.lol/';
  }

[douglasnaphas]

More progress on the local setup. I can fetch to /api/public-endpoint from http://localhost:3800.

[douglasnaphas]

Some things to deal with.

admin_douglas_naphas:~/environment/mljsapi (table-env-var) $ grep -rIn --exclude-dir=.git --exclude-dir=node_modules 'TableName.*seders' .                                             
./lib/createSession.test.js:29:          params.TableName != 'seders' ||
./lib/dbPlayGetScripts.js:19:    TableName: 'seders'
./lib/db.js:28:          TableName: 'seders',
./lib/db.js:47:          TableName: 'seders',
./lib/joinSeder.test.js:169:        params.TableName != 'seders' ||
./lib/createSession.js:34:      TableName: 'seders',
./lib/dbPlayGetParticipants.js:21:    TableName: 'seders'
./lib/room-code.js:36:        TableName: 'seders',
./lib/joinSeder.js:46:      TableName: 'seders',

The table name should be fully parameterized so that I can pass it in as an environment variable from the CDK project.

[douglasnaphas]

I need to get the tests passing now that the table name is not hard-coded as 'seders', but rather is passed in from the environment.

[douglasnaphas]

The changes I made on my branch table-env-var are causing /scripts to return a 500.

[douglasnaphas]

I should set SameSite: None when NODE_ENV is "development." It looks like Chrome isn't sending my cookie from localhost:4000 to api-dev.passover.lol.

[douglasnaphas]

Closing. The frontend and backend are deployed. I'll set up separate Issues for implementing stages of the workflow (sign-in, listing scripts, joining the seder, etc) in the turnkey env.