sst integration

[danielroe]

https://serverless-stack.com/

https://github.com/nuxt/framework/discussions/4471

[pi0]

Isn't that a build tool similar to nitro?

[ffxsam]

@pi0 No, Serverless Stack is similar to the Serverless Framework, though with some advantages, including:

• Live Lambda development
• Sits on top of CDK, and there's an escape hatch for every SST construct

[pi0]

Surely. I put the nitro and serverless framework in the same category. Nitro dev has HMR and outputs (also as) a lambda format from the same code and provides similar constructs for Storage, etc. Doing the same thing but different approach. I don't see the point of combining two server frameworks like this together. But you can chain .output of nuxt to them.

[ffxsam]

The point of combining SST + Nuxt is so that they exist together (with Nuxt as a yarn workspace) and Nuxt can simply import functions from the back end code, instead of making API calls. In other words, it reduces latency by going from:

API Gateway -> Nuxt app (cold start) -> API Gateway -> Lambda func (cold start) -> business logic

to this:

API Gateway -> Nuxt app (cold start) -> business logic

[pi0]

Indeed but actually Nitro also exactly does that too! When you use fetch in a server environment, it directly calls them instead of making a new HTTP call. Both Nuxt SSR and API routes live in same build (lambda function)

[ffxsam]

I'm not familiar with Nitro at all, but will it let you define a several sets of CloudFormation stacks and deploy them? Along with Lambda funcs of course, and being able to test locally?

[ffxsam]

Example structure of SST + Nuxt:

.
├── cdk.context.json
├── nuxt
│   ├── app.vue
│   ├── lambda.js -> .output/server/index.mjs
│   ├── nuxt.config.ts
│   ├── package.json
│   ├── public
│   │   └── favicon.ico
│   ├── tsconfig.json
│   ├── tsconfig.node.json
│   └── yarn.lock
├── package.json
├── src (all business logic lives here, including Lambda funcs)
├── sst.json
├── stacks (SST stack definitions)
│   ├── WebAppStack.ts
│   └── index.ts

SST's Lambda funcs (and GraphQL APIs, etc) can import modules from src, as can Nuxt, so there's a single shared codebase.

[ffxsam]

Further context: my back end (built with SST) is a highly complex set of stacks including S3 buckets, SQS queues, Lambda functions, Step Functions, and more. By bundling our Nuxt app into that repo, it has direct access to all the same core code that the various AWS services do.

Of course, there are still kinks to work out. But I think the latency savings will be worth the effort.

Thinking about this more, I'm not too sure if this is a good candidate as a Nitro preset. The Nuxt app needs to live within the SST repo, not vice-versa.

[pi0]

If you like to use a wrapper of SST to integrate your backend with Nuxt 3, it should be possible to adjust the .output format but I'm afraid the development experience would be painful and full of edge cases.

I think it might be worth investigating solutions to make your backend compatible with Nitro instead of wrapping it to another framework.

Normally with Nuxt 3 it should be like this:

├── nuxt
│   ├── app.vue
│   ├── lambda.js -> .output/server/index.mjs
│   ├── nuxt.config.ts
│   ├── package.json
│   ├── public
│   │   └── favicon.ico
│   ├── server
│   │   └── api/
│   │   └── routes/
│   │   └── plugins/
│   ├── tsconfig.json
│   ├── tsconfig.node.json
│   └── yarn.lock

Business logic sits in the Nuxt 3 app (as a full-stack framework inside nuxt/server/ directory and finally converted into a lambda function altogether with the app. Using the same toolchain (Nitropack)

Nitro is following a similar goal of Serverless and SST but with a different approach of being provider agnostic layer for Nuxt and supporting output formats beyond lambda.

But I think the latency savings will be worth the effort.

I can assure you Latency saving with nitro, if not more than other solutions, isn't less. We only need to find a solution to migrate your backend into compatible format :)

[ffxsam]

Well, the main cost savings is Nuxt having direct access to our database. But it would be sloppy to copy the necessary code from our back end to Nuxt and duplicate all of that. The front-end app also needs to access the same bit of code.

front end -> API Gateway/Lambda -> Operation A (for example, 1000 lines of code to fetch from DB, process data, etc)
Nuxt app -> Operation A (wouldn't make sense to copy all of this into the Nuxt repo)

And of course, the Nuxt app could just call the same API Gateway endpoint that the front end does, but again, I want to avoid calling API Gateway twice and having the user potentially experience two Lambda cold starts.

Any thoughts/ideas?

EDIT: Might work out to move that Operation A logic into Nuxt, and then just have the front end call the Nuxt endpoint.

[Hebilicious]

@pi0 from what I understand, I don't think Nitro and SST are in the same category

• SST does many thing, but I look at it as an "IaC framework", ie it's functionally closer to something like Terraform / Pulumi, altough it's built on AWS CDK so it's AWS specific and allow you to do more aws-y stuff.

• SST has a NextJS construct that handles SSR/SSG/API/ISR and image optimisation and also a Vite one (for SPAs)

I'm not sure what would be the right approach to make these 2 work together, but perhaps it would involve a Nuxt construct on the SST side and a Nitro plugin ?

Nitro doesn't really replace SST, so I think there's value in making these 2 play well together.
Or is Nitro meant to support generic IaC as well through plugins ? For example I could see maybe a CDK plugin, or a Pulumi plugin, although I'm not familiar enough with the codebase to say if that's what you intend for Nitro.

[chris-visser]

Shouldnt the SST preset actually be a NuxtsiteStack in SST? It looks like this is not really a nuxt framework topic, but something that SST should support just like NextjsSite is supported by SST. Nuxt should just support AWS Lambda@edge functions which is currently an approved PR already so I expect it to be in quite soon.

So maybe create a PR on SST to have the stack setup in as described in the docs of this commit

[Hebilicious]

Referencing these upstream issue and PR :

sst/sst#2314
sst/sst#2989

Working demo by @jdevdevdev Linking sst/sst#2314 (comment)

[robokozo]

It'd be cool to support it directly in nitro but i think @chris-visser and @Hebilicious are correct in that I think the responsibility of integration lies on the sst project.

[ennioVisco]

It'd be cool to support it directly in nitro but i think @chris-visser and @Hebilicious are correct in that I think the responsibility of integration lies on the sst project.

It'd be cool if the integration with sst considers their new project, ion, willing to ditch Cloudformation for open source Terraform providers. Check https://sst.dev/blog/moving-away-from-cdk.html

[pi0]

Moving to #2973