Deploy Support for AWS Amplify

[tylersayshi]

A vite plugin is necessary to configure the build process to build for AWS Amplify.

It would be nice to include docs similar to: https://github.com/dai-shi/waku/blob/main/docs/builder/aws-lambda.mdx#L1-L4 for amplify

Also, it could be interesting to investigate nitro for adding this support.

[dai-shi]

@rmarscher @pmelab thoughts?

[dai-shi]

nitro for adding this support.

Is it related to AWS Amplify?

[pmelab]

@rmarscher @pmelab thoughts?

Is there a reason you tagged me? Unfortunately I don't have experience with AWS Amplify.

[dai-shi]

Is there a reason you tagged me?

I thought you are familiar with AWS Lambda deployment, and I didn't know if there was a difference between Amplify and Lambda. Sorry about that.

Wait, I was completely wrong. I should have tagged @aheissenberger instead.

[pmelab]

Wait, I was completely wrong. I should have tagged @aheissenberger instead.

😂 I suspected something like that.

[rmarscher]

A vite plugin is necessary to configure the build process to build for AWS Amplify.

@tylersayshi Do you have a link to the docs for using Vite with AWS Amplify?

[tylersayshi]

@rmarscher do you mean just deploying any vite app at all to aws amplify?

I don't really have any details on this beyond the initial ask though. I made this issue in response to a user asking for aws amplify support in the waku discord channel.

[rmarscher]

@rmarscher do you mean just deploying any vite app at all to aws amplify?

I don't really have any details on this beyond the initial ask though. I made this issue in response to a user asking for aws amplify support in the waku discord channel.

Yeah, sorry. I found the context on Discord. I thought you meant that Amplify requires using a specific Vite plugin when deploying to it.

The Nitro presets are a pretty good reference for where the static and function assets need to be moved to for deploying to AWS amplify - https://github.com/nitrojs/nitro/blob/v2/src/presets/aws-amplify/preset.ts
https://nitro.build/deploy/providers/aws-amplify
I think we agreed to do our own thing for now and not try to incorporate Nitro's presets/config into our build system since it seems to be coupled with the rest of their ecosystem.

I am finding that a lot of deploy scenarios require a separate "function" folder with the server code from the public assets folder. A manifest of the public asset files is also often necessary.

I'm personally a bit confused on the correct cache headers for some of the files - especially the dist/public/RSC files. It seems like there are a few urls that do not update when the content changes on deploy. So I think those need to have no-cache headers or have their cache invalidated on deploy or something like that. Cloudfront cache invalidations are actually pretty expensive if you do them a lot.

I don't personally have a use case for Amplify so I can't volunteer to take on supporting a deploy plugin. I'm happily using SST for now.

[tylersayshi]

Seems safe for this issue to wait for a stronger use case to develop itself - would be a nice option if someone is new to waku and wanting to use amplify I think. Or would be nice to see 👍's on the issue description to see that this is something many people would use.

[aheissenberger]

Sorry - I have no experience with AWS Amplify

[tseijp]

I have investigated methods to deploy any server application like Waku, Hono or Express on AWS Amplify 🚀

Initiate a project with npm create waku@latest and integrate the following 3 files into the repo's root dir to deploy through the AWS Amplify console:

• startServer.mjs: This file contains code to launch a server in AWS Amplify's AWS Lambda@Edge environment using the command node startServer.mjs

import { Hono } from "hono";
import { compress } from "hono/compress";
import { serve } from "@hono/node-server";
import { serveStatic } from "@hono/node-server/serve-static";
import { serverEngine } from "waku/unstable_hono";

const app = new Hono();

app.use(compress());

app.use(serveStatic({ root: "./public" }));

app.use(
  serverEngine({
    cmd: "start",
    loadEntries: () => import("./entries.js"),
    env: process.env,
  })
);

app.notFound((c) => c.text("404 Not Found", 404));

console.log(`ready: Listening on http://localhost:3000/`);

serve({ ...app, port: 3000 });

• amplify.yml: Specifies commands in AWS Amplify's CI/CD to adjust the directory structure for running any server app. It includes commands to move Waku's build files to .amplify-hosting/compute/default.

version: 1
frontend:
  phases:
    preBuild:
      commands:
        - npm ci --cache .npm --prefer-offline
    build:
      commands:
        - npm run build
    postBuild:
      commands:
        - npm prune --production
        - rm -rf ./.amplify-hosting
        - mkdir -p ./.amplify-hosting/compute
        - cp -r ./dist ./.amplify-hosting/compute/default
        - cp -r ./node_modules ./.amplify-hosting/compute/default/node_modules
        - cp -r ./dist/public ./.amplify-hosting/static
        - cp -r ./dist/public ./.amplify-hosting/compute/default
        - cp deploy-manifest.json ./.amplify-hosting/deploy-manifest.json
        - cp startServer.mjs ./.amplify-hosting/compute/default/startServer.mjs
        - 'echo "{ \"type\": \"module\" }" > ./.amplify-hosting/compute/default/package.json'
  artifacts:
    baseDirectory: .amplify-hosting
    files:
      - '**/*'

• deploy-manifest.json: Describes the AWS Amplify stack adjustments. It modifies computeResources to enable running startServer.mjs.

{
  "version": 1,
  "framework": { "name": "waku", "version": "0.21.7" },
  "imageSettings": {
    "sizes": [100, 200, 1920],
    "domains": [],
    "remotePatterns": [],
    "formats": [],
    "minimumCacheTTL": 60,
    "dangerouslyAllowSVG": false
  },
  "routes": [
    {
      "path": "/_amplify/image",
      "target": {
        "kind": "ImageOptimization",
        "cacheControl": "public, max-age=3600, immutable"
      }
    },
    {
      "path": "/*.*",
      "target": {
        "kind": "Static",
        "cacheControl": "public, max-age=2"
      },
      "fallback": {
        "kind": "Compute",
        "src": "default"
      }
    },
    {
      "path": "/*",
      "target": {
        "kind": "Compute",
        "src": "default"
      }
    }
  ],
  "computeResources": [
    {
      "name": "default",
      "runtime": "nodejs18.x",
      "entrypoint": "startServer.mjs"
    }
  ]
}

[aheissenberger]

@tseijp very cool, great work!

Based on your example code with hono and as you build the Waku app for node (not for AWS Lambda) the app is deployed as a AWS Lambda docker container and not to AWS Lambda@Edge. Compared to the other deployment options you add an extra layer (wrapper) which might impacts performance and costs as all request events are converted to a http request to port 3000 to deploy the original app without any changes to the serving layer. It is very hard to compare the costs between these deployment options but it look like this option is slightly more expensive if you expect higher traffic and there are some fixed costs you pay per construct.

I will have a look at it as it looks like a very simple solution and comes with CI/CDI out of the box