Suggestions for additional resource config settings

[GavinRay97]

This project is really amazing! I've used it to deploy a personal project and it worked fantastically.

I had some suggestions about resource inputs which I tweaked after forking the repo locally:

1. Add a configurable port to FargateArgs interface. Currently it's hardcoded to 8080. I had added this to the type:

export interface FargateArgs {
  // <snipped>

  /**
   * HTTP port the Fargate service exposes
   */
  servicePort: number
}

// <snipped>
const listener = new awsx.lb.NetworkLoadBalancer(
  // There's a 32 character limit on names so abbreviate to "nlb".
  `${name}-nlb`,
  {},
  { parent: this }
)
  .createTargetGroup(
    `${name}-target-group`,
    { port: servicePort, protocol: "TCP" },
    { parent: this }
  )

2. Add instanceSize and storage args to RDS options, atm it defaults to 5 GB and the T3 micro instance I think

3. Allow syncWeb to take an optional configurable build command and dist/assets folder

interface SyncWebInputs { bucketName: string webPath: string env?: NodeJS.ProcessEnv buildCommand?: string[] distFolder?: string }

function buildWeb(webPath: string, env: NodeJS.ProcessEnv = {}) { // Yarn doesn't have a programmatic api https://github.com/yarnpkg/yarn/issues/906 // spawn.sync doesn't know how to resolve modules in a pulumi serialized function // https://www.pulumi.com/docs/tutorials/aws/serializing-functions/#serializing-javascript-functions const command = require.resolve("yarn/bin/yarn") const args = ["--cwd", webPath, "build"] const proc = spawn.sync(command, args, { env }) if (proc.status !== 0) { console.error(\${command} ${args.join(" ")}` failed`) } }

function buildWebCustom(buildCommand: string[], env: NodeJS.ProcessEnv = {}) { const [cmd, ...args] = buildCommand const proc = spawn.sync(cmd, args, { env }) if (proc.status !== 0) { console.error(\${cmd} ${args.join(" ")}` failed`) } }

async function syncWeb( inputs: SyncWebInputs ): Promise<{ id: string; outs: SyncWebOutputs }> { // if (buildCommand) { buildWebCustom(buildCommand, env) } else { buildWeb(webPath, env) } // ....

4. Not sure if this is feasible, but maybe make the Expo CLI a peer dependency of the Pulumi components package

---

This is what my Pulumi infra file ended up looking like:

```ts
// <bunch of stuff skipped>

const certificate = new Certificate("certificate", {
  domain,
  subjectAlternativeNames: [`*.${domain}`],
  protect: true,
  timeToLive: 60 * 5,
})

const postgres = new RDS("server-db", {
  dbName,
  dbUsername,
  dbPassword,
  instanceClass: dbInstanceSize[stack],
  allocatedStorage: storageGB[stack],
})

new Fargate("hasura", {
  cluster: postgres.cluster,
  domain: `hasura-${stack}.${domain}`,
  certificateArn: certificate.arn,
  servicePort: 8080,
  image: awsx.ecs.Image.fromDockerBuild("hasura", {
    context: "../hasura",
    dockerfile: "../hasura/Dockerfile",
  }),
  env: // ...
})

new Fargate("api", {
  cluster: postgres.cluster,
  domain: `api-${stack}.${domain}`,
  certificateArn: certificate.arn,
  servicePort: 3000,
  image: awsx.ecs.Image.fromDockerBuild("api", {
    context: "../api",
    dockerfile: "../api/Dockerfile.prod",
  }),
  env: // ...
})

new StaticWebsite("frontend", {
  domain: `frontend-${stack}.${domain}`,
  certificateArn: certificate.arn,
  webPath: "../frontend",
  buildCommand: ["yarn", "--cwd", "../frontend", "build"],
  distFolder: "../frontend/dist",
  env: // ...
})

[GavinRay97]

It looks like second one about the RDS configuration was added few days ago so nevermind on that one :sweat_smile:

[tiagob]

Thanks for your feedback! Glad to hear you like the project. Please don't hesitate to let me know what else you'd find useful. You're the first person to see this besides the people I've personally shown. Just out of curiosity, how'd you find out about it?

I made some changes to address your comments, https://github.com/tiagob/create-full-stack/pull/139/files

I defaulted the Fargate service port to 8080. I want to keep the generated pulumi-aws/index.ts files as simple as possible but it makes sense to allow additional configuration.

I renamed distFolder to buildPath which matches the naming in the project. It behaves just like you suggest.

I didn't include buildCommand. The standard build command didn't work for you? Did you get an error?

[GavinRay97]

Just out of curiosity, how'd you find out about it?

Haha, super valid question. I basically searched Github for combinations of "pulumi", "hasura", and "fargate", and then manually combed through every repo result for hours, weeding out stuff of value.

Without a doubt this repo was the most useful and impressive. Kind of shocked me to see it had zero stars, though I see that's intentional now :joy:

By the way, I'm a Technical Evangelist at Hasura -- if you're interested would love to tweet this repo out + put it in community newsletter whenever you feel it's ready. Think a lot of people could benefit from this.

The standard build command didn't work for you? Did you get an error?

No it totally would have! It was more of me just wanting to leave the command open-ended. I'm actually not using this with a React app, so some of the targeted stuff wasn't identical (the frontend I had deployed was a Vue SPA, which also uses yarn build, the backend is a Nest.js API).

The rest of the static website builder is pretty agnostic, the only thing that was locked in was that the build command assumes yarn build (which is probably true for 98% of apps), so while I was tweaking stuff I made it configurable.

But it really doesn't make a difference for my usecase either way to be honest.

[tiagob]

Sounds like a lot of work. Glad you found it!

I would really appreciate a tweet + newsletter. Thank you! I'll let you know when it's ready. Thinking 1-2 weeks. What's the best way to notify you?

Since I'm trying to keep it as simple as possible for the 98% use case, I'm not going to include the buildCommand. If there are other examples in the future to support a custom build command, I'll add it then.

Re: expo-cli, I like that idea. I initially tried doing that but was having problems reaching the expo command when executing it in Pulumi. I could likely do something similar to require.resolve("yarn/bin/yarn") in syncWeb. I think it's ok as-is for now

[tiagob]

Merged and published the changes cfs-pulumi@0.1.11

[GavinRay97]

The Expo CLI thing would be neat if possible because I think it wound up being the majority of the packages dependency weight. If not, no big deal ¯_(ツ)_/¯

Thinking 1-2 weeks. What's the best way to notify you?

Awesome =D Can email me at gavin@hasura.io or DM me on Twitter (GavinRayDev) if that's more convenient :+1:

[tiagob]

@GavinRay97 would splitting up the cfs-pulumi package help? I'm considering cfs-pulumi-aws, cfs-pulumi-auth0 and cfs-pulumi-expo. I'm assuming you're not using expo publish?

Using the expo-cli in a Pulumi dynamic provider is tricky since it runs in an AWS lambda function.

[GavinRay97]

Ahh could see that being thorny. The optimum situation would probably to have the packages be modular, so if someone isn't using Expo/RN it won't pull that dep in.

But if it makes managing the dependencies more difficult, may not be worth the effort.

[tiagob]

Done. I broke up cfs-pulumi into cfs-pulumi-aws, cfs-pulumi-auth0 and cfs-pulumi-expo