Deploying to existing infrastructure

[finferflu]

Hi,

I can't seem to find anything that relates to this in the documentation, however, I'd like to deploy my application to existing infrastructure. Is there any way to package the application so that it's ready for deployment, but without creating all the resources via Serverless?

Thank you.

[dphang]

There's no input yet to specify to build the Lambda bundle but not deploy to AWS.

Perhaps a workaround is to set invalid AWS keys, I think it still may output the handlers to the .serverless-nextjs generated directory. However I think S3 assets are uploaded directly, there's no build artifact in that folder, so you would have to figure out that based on .next directory contents.

Feel free to add a new input to do this and I'll be happy to review it.

[finferflu]

Thanks for this @dphang, I'll go back to the code and see what we can do. Are there any plans to support this feature, in any case?

Thanks!

[dphang]

I haven't planned to make a change yet, but it does seem straightforward enough to disable the actual deployment step to AWS (separate build from the deployment) if you just want the build outputs (contents of the serverless_next.js folder).

We'd have to add the S3 assets there too that would have been uploaded in that case. Then you can just use the content of this directory and you'd have to deploy it yourself to Lambda/CloudFront/S3.

1. You can look at lambda-at-edge/src/build.ts code which builds the lambda package. nextjs-component/src/component.ts calls this build and deploys (uploads Lambda and S3 files). So the idea is component.ts should check an input on whether to actually deploy, if that is false, then skip the deploy step. Right now the code is like this, so it always deploys (you can skip the build with an input actually):

  async default(
    inputs: ServerlessComponentInputs = {}
  ): Promise<DeploymentResult> {
    if (inputs.build !== false) {
      await this.build(inputs);
    }

    return this.deploy(inputs);
  }

2. It probably needs a refactor so that the build step creates the files to upload and the deploy step just blindly deploys that folder to S3 (without knowing which files it needs to pick from .next directory, as it currently does).

I think this could help make this component more provider-agnostic in the future by clearly separating build vs. deploy responsibilities.

[finferflu]

Thanks, @dphang, decoupling the asset creation from the actual deployment sounds like a great strategy, and it would surely make this component a lot more viable for people who want to deploy using different tools or providers.

I'll see what I can make of these suggestions and I'll get back to you should any more questions arise. Meanwhile, I'm glad this was labelled as "enhancement", and I hope this will become a feature soon!

[dphang]

Yea, makes sense.

Short term we can make those small refactor to better decouple build and deploy step. So you can deploy the build outputs to AWS yourself. I can work on the change in the next weeks.

Long term I think it makes sense to further decouple the cloud providers from this process (right now AWS is heavily coupled into the core logic). But this is non-trivial to do so I expect it can take some months. So we could have something like this:

1. Common core logic for Next.js serverless which is generic and platform/provider agnostic.

Then, we could adopt a plugin architecture to build and deploy for specific platforms:

2. Build and bundle the handlers using the specific plugin (AWS Lambda@Edge, and other providers in the future). With Rollup it should be easier to do so (for example, the AWS Lambda@edge plugin will provide AWS specific code such as Lambda@Edge compatibility layer, S3 code, and Rollup should be able to bundle it in the handler). This will create a build output for the specific platform you want. You can then choose to stop here and deploy the bundle yourself, or use the deploy step below.
3. Deploy the handler using the corresponding deployment plugin (e.g AWS Lambda@Edge right now).

It will make it easier to support other platforms (Lambda, Cloudflare, GCP, Azure).

[dphang]

I've added a new input deploy which can be set to false to just build assets and skip deployment (now includes s3 assets as well). Available in @sls-next/serverless-component@1.18.0-alpha.12 now.

[finferflu]

@dphang Thanks for the very quick turnaround! We are planning to start using this in the short term.

[finferflu]

Hi @dphang,

We were able to test this release and successfully deploy our Next.js app to existing infrastructure. However, we have noticed that the Serverless artifacts are still being generated. While this is not a deal-breaker in any shape or form, it might be something for you to take a look at just to keep things clean.

Thanks!

[dphang]

@finferflu which serverless artifacts are you talking about, the .serverless directory? If so I think that is always generated by Serverless framework, not this component. But I'll take a look at some point.

[finferflu]

@dphang sorry for the delay, yes, I'm talking about the .serverless directory, as you've inferred.