Presets for AWS Adapter Plugin

[thescientist13]

Overview

Given the nature of AWS, and how it generally favors working with IaC (Infrastructure) as code tools, the one question coming out of #1419 was what, if anything, could Greenwood do here, past generating predictable build output? Could we maybe some provide some simple pre-generated IaC code for any of the popular IaC tools like SST or Architect?

Presets

Usage

The general design would like something like this, where options could be passed to the plugin from your greenwood.config.js, with an optional "options" bag

import { greenwoodPluginAdapterAws } from '@greenwood/plugin-adapter-aws';

export default {
  plugins: [
    greenwoodPluginAdapterAws({
      preset: "sst" // or "architect"
    })
  ]
}

With options bag, something like this

import { greenwoodPluginAdapterAws } from '@greenwood/plugin-adapter-aws';

export default {
  plugins: [
    greenwoodPluginAdapterAws({
      preset: {
        "type": "sst",
        "....": "...."
      }
    })
  ]
}

SST

Demo here - ProjectEvergreen/greenwood-demo-adapter-aws#5

SST has a fairly expressive and composable API, but less of a one size fits all approach, allowing SST configuration to be authored in JS / TS. However, in theory this means Greenwood could output its own preset files, and then a user could compose those into their own configs?

// sst.config.ts
/// <reference path="./.sst/platform/config.d.ts" />

export default $config({
  app(input) {
    return {
      name: "my-app",
      removal: input?.stage === "production" ? "retain" : "remove",
      protect: ["production"].includes(input?.stage),
      home: "aws",
    };
  },
  async run() {
    // consume this from Greenwood's AWS output folder
    await import("./aws-output/sst/infra/router")
  },
});

However, this would still likely need to deal with customization of all those resources (names, runtime, methods, etc) so not sure how far we can go. However, users can use the Greenwood build output to programmatically build up SST config, which seems the most ideal, as seen in the demo repo above

// ./infra/api-routes.ts
export const api = new sst.aws.ApiGatewayV2("Api");

const RUNTIME = "nodejs22.x";
const apiRoutes = ((await import(new URL('../../public/manifest.json', import.meta.url), { with: { type: 'json' } })).default).apis.value;
const ssrPages = ((await import(new URL('../../public/graph.json', import.meta.url), { with: { type: 'json' } })).default).filter(page => page.isSSR);

ssrPages.forEach((page) => {
  const { id } = page;

  api.route(`GET /routes/${id}`, {
    // point to Greenwood AWS build output
    bundle: `.aws-output/routes/${id}`,
    handler: "index.handler",
    runtime: RUNTIME
  });
})

apiRoutes.forEach((apiRoute) => {
  const [route] = apiRoute;

  api.route(`ANY ${route}`, {
    // point to Greenwood AWS build output
    bundle: `.aws-output/${route}`,
    handler: "index.handler",
    runtime: RUNTIME
  })
});

Architect

Demo here - ProjectEvergreen/greenwood-demo-adapter-aws#8

One challenge I see with Architect is that unlike SST which has configuration written in JS / TS, Architect configuration seems to only be defined through its own custom text file. Which means unlike SST, you can't "compose" some pre-generated output into your own at least. It seems it would have to be entirely plugin configuration driven.

@app
my-app

@http
/api/fragment
  method any
  src .aws-output/api/fragment

/api/greeting
  method any
  src .aws-output/api/greeting

/api/search
  method any
  src .aws-output/api/search

/products/*
  method get
  src .aws-output/routes/products

@aws
# profile default
region us-east-1
runtime nodejs22.x
architecture arm64

Thoughts

In general, I am not sure a preset pattern is something we want though, since even for the slightest configuration, like with SST in naming your resources (Router, etc) or wanting to lock down the method for each function, linking other AWS resources like DB or other Lambda function, I think it would generally be a losing battle even trying to support even minimal customization, and how often would users be needing to "eject" anyway?

Not dealing with presets, and just documenting the build output and giving a couple demo examples and in the docs, seems like it should provide enough runway for anyone to adapt any IaC tool to Greenwood's output, and customize it from there.

---

While I am personally not sure how much mileage we can get out of this and having to deal with picking "winners and losers", I would be curious to see how user's use this plugin in practice, and what their actual "eject" scenarios look like (if any) and try and build a consensus based on that.