faceteer / cdk Goto Github PK

If you create and deploy an API handler, and then update the "name" of the handler and re-deploy, you will get a 409 conflict due to a "duplicate route" - this is due to the API route in API gateway already existing, and us not being able to switch for a new lambda function with an UPDATE. Cloudformation is attempting to do a CREATE / DELETE of the "old" route integration (which is unchanged, just with a new lambda target).

Faceteer should be using a Cloudformation "Logical ID" based on the API route, not based on the handler definition's name, since for an API handler its unique identifier is its route in the API.

Steps to reproduce:

1. Create a service with an api handler
2. Deploy it
3. change the "name" in the API handler definition
4. Redeploy
5. Receive the conflict error as seen below:

❌  ExampleService-ayoung failed: Error: The stack named ExampleService-ayoung failed to deploy: UPDATE_ROLLBACK_COMPLETE: Route with key GET /users/{userId} already exists for this API (Service: AmazonApiGatewayV2; Status Code: 409; Error Code: ConflictException; Request ID: 90afc02e-a7b6-4440-9613-1846397bc1d6; Proxy: null)
    at prepareAndExecuteChangeSet (/Users/ayoung/projects/faceteer-deploy-issue/stack/node_modules/aws-cdk/lib/api/deploy-stack.ts:385:13)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at CdkToolkit.deploy (/Users/ayoung/projects/faceteer-deploy-issue/stack/node_modules/aws-cdk/lib/cdk-toolkit.ts:209:24)
    at initCommandLine (/Users/ayoung/projects/faceteer-deploy-issue/stack/node_modules/aws-cdk/lib/cli.ts:341:12)

The stack named ExampleService-ayoung failed to deploy: UPDATE_ROLLBACK_COMPLETE: Route with key GET /users/{userId} already exists for this API (Service: AmazonApiGatewayV2; Status Code: 409; Error Code: ConflictException; Request ID: 90afc02e-a7b6-4440-9613-1846397bc1d6; Proxy: null)

expected outcome:
The API gateway route integration is updated to use our newly named lambda function instead of the existing one.

Currently we are requiring an AVJ schema when defining a new ApiHandler. We've found that this can be restrictive if another schema fits the case better (for example, Joi and Yup can strip attributes while AJV can not). It also fits in line with the patterns we have for queue and event handlers which have no requirements for an AJV validator.

By doing this, we lose the flexibility to automatically generate OpenApi specs or sdk packages. @AnYoung627 brought up a great idea however to enable this in the future with plugins.

From Nextjs to SvelteKit to Nuxt, a lot of web frameworks are choosing filesystem based routing.

The biggest advantage of this method is that it is easy to figure out which API path matches to which file in the codebase. It also helps keep the codebase organized as handlers operating on the same resources will be grouped together within the same folders naturally.

My suggestion would be to follow a method similar to NextJs. To give a few examples, the left sides are the paths for the handlers, and the right sides are examples of routes that will match them:

• index.handler.js -> /
• object/index.handler.js -> /object
• object/{id}.index.js -> /object/123id456
• object/{id}/properties/index.js -> /object/123id456/properties
• posts/{...rest}.index.js -> /posts/2023/01/03/hello

This will really need minimal changes in the codebase. For backwards compatibility, we can keep the route parameter for handlers which will override the filesystem based routes, and compute the route based on the file path otherwise.

Enable a new handler to subscribe to a given DynamoDB stream

Currently, version numbers are manually increased and new versions of a package are manually published to NPM.

We might want to look at solutions to automate this.

semantic-release

https://github.com/semantic-release/semantic-release

This is one tool that we could adopt that seems to have broad usage and support.

It would require us format our commit messages in a particular way, which might be annoying. But if we enforce squash commits for the repository it might be simple enough.

Behavior

If some handler fails to be built, the stack will still be deployed to AWS and ultimately delete the api handler and its endpoint.

Expected behavior

The entire deploy process should fail and no new updates should go into the cloud.

What

CLI tool to run in a faceteer cdk project which will automatically detect what lambda logs to be watching and open a react web app which displays those relevant logs.

Problem it addresses

There is a lot of wasted time and noise while working inside of the AWS CloudWatch console. This feature will spin up on a command and display relevant logs in a prettier format.

Faceteer CDK filters all the files in the service folder to pick ones that end with .handler.ts or .handler.js.

It would be a good extension to let users override this filtering. Some people could prefer to only deploy .handler.ts or .handler.js files, or they could have their own naming scheme like .lambda.ts. Users should be able to pass a regex, or a function, that can be ran against file paths to decide if the file should get required and deployed.