moduscreateorg / capsule Goto Github PK

Now we handle 403 via the Lambda function, we need to ensure when a redirect doesn't exist we display a 404 message.

• Setup prettier
• Setup eslint

It would be nice to set up custom redirect rules. We found that useful in Modus Labs (see here) based on Netlify config

We should:

1. Create a docs folder to contain specific documentation, with categories like:

• General capsule cli explanation
• Cloudformation templates explanation including the architecture graph
• AWS credentials setup, suggestions and links to useful AWS docs.
• Explanation for capsule config
• Contribution section:
  • how to create issues
  • how to creat prs
  • how to setup the dev env
  • how to test changes
  • how to release next version
  • "thanks to"
  • others?
• FAQs

2. Update README to be the main project presentation and reference docs in under docs/ folder.
3. Add badges for:

• codebuild test passing,
• npm version
• download count
• license fossa scan

Add in support for custom redirects.

Allow redirect debugging via CloudWatch

The cli should show what is doing on each situation. It particularly should display the cloudformation events in table-like view.

Some projects need to be password-protected, either entirely or specific routes.

Viable authentication methods:

• basic auth
• oauth via Google and other services

having to provide both --dom and --subdom is a bit weird. Can the CLI figure that out from foo.bar.com?

The docs should outline minimal CLI steps for first-time users. Current examples are a bit long and confusing

Consider in addition to npm if we want a Deb and RPM package.

Prior to upload to S3, we can gzip, brotli, and deflate (and potentially other compressions as well) all assets and upload all of the versions (tack on the compression method as an extension, e.g. image.png.br or image.png.gz). Then, in a pre-cloudfront lambda@edge (yes, this means it is run on EVERY request) we read the Accept-Encoding header and then create a CUSTOM x-compression (or w/e) header with a value of the best compression option the user will accept, tell cloudfront to cache based on our custom header value (and pass it along to the origin), and then in a pre-origin lambda@edge, read that value, and then forward the request to the origin after we update the uri to include the compression extension. (edited)

the lambda@edge pre-origin will only get called when assets of that compression type aren’t cached in cloudfront, but the lambda@edge pre-origin will get called every time. It’ll likely add about 10-20ms to the request and cost $0.60 every million requests, but being able to serve brotli will reduce transfer size by ~20%… so given transfer costs and depending on size of assets, it could end up saving money (and almost guaranteed it’ll reduce transfer times for the user) (edited)
(The pre-cloudfront lambda@edge extra effort is b/c cloudfront strips everything except gzip out of the accept-encoding header. Cloudfront only supports gzip natively. Hopefully one day they’ll stop stripping out the other encoding types and then we could potentially drop that extra lambda.)
Pretty much all evergreen browsers (including mobile) support brotli https://caniuse.com/#feat=brotli

This issue is to add CloudTrail setup via CF templates.

You can start by reading the docs here:

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudtrail-trail.html

To get an idea of setting up CoudTrail.

Show an architecture diagram in Readme, similar to

We can use this: https://aws.amazon.com/architecture/icons/

init looks like the command we start with. Here's what I expect from it:

• Create a configuration file
• Create any metadata files such as cloudformation templates
• DO NOT deploy

Then I would expect capsule deploy that does the work.

Does this make sense?

Users may want to choose to deploy the stack to a region other than their default.

Without reading the docs I thought I was expected to use capsule init my-project-name

What does the team think of that approach?

• Chose a Unit testing framework for Capsule
• Write Unit tests for the bin/capsule.js file

"Node.js 8.10 is EOL, please migrate your functions to a newer runtime version"

This file will need to be changed and tested:

https://github.com/ModusCreateOrg/capsule/blob/master/templates/child_templates/template.lambda.yaml

Add support for CodePipeline.

capsule.js should not hardcode version number. Obtain it from package.json instead

Can somebody please clean up the CloudFormation in this file:

https://github.com/ModusCreateOrg/capsule/blob/master/ci/s3_cloudformation.cf

We need a RegEx adding to ensure the project name is valid for use in an S3 bucket. Currently, there is no validation on the name as per the description:

Description: "Name of the project. TODO: Add validation regex"

Minor stylistic cleanups as per the comments on PR 28:

1. Check functions are not defined as async when not required

2. Use ternary operator when setting bucketName based on domain and subdomain

3. Check anywhere, where params were being used for testing but no longer needed are tidied up.

Branch: stylistic_fixes