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.