search

jetbridge / cdk-nextjs

Deploy a NextJS application using AWS CDK
https://constructs.dev/packages/cdk-nextjs-standalone
Apache License 2.0
273 stars 45 forks source link

Is there a path where this project is just a wrapper/abstraction on top of NextjsSite? #123

Closed kevin-mitchell closed 1 year ago

kevin-mitchell commented 1 year ago

Disclaimer: I'm new to Next.js, and have never used SST, so my question may lack a lot of context - sorry in advance!

I'm in deep, deep innovation token debt, and want to use CDK with as few abstractions on top I have to trust.

That said, as I'm taking a stab at getting ISR and open-next v2+ working with this project, I'm finding that a lot of what we need is already written (not surprisingly) in NextjsSite. I'm basically wondering if there is a path to using NextjsSite more directly, so that this project isn't required at all?

The readme for this project says

You may want to look at Serverless Stack and its NextjsSite construct for an improved developer experience if you are building serverless applications on CDK.

I did look through NextjsSite and it does seem like it wouldn't "just work" because there are some hooks / configuration values that I imagine come from the great SST landscape, so it may simply not be possible for this reason. I'm curious though if there are other reasons, e.g. I NextjsSite is one large construct, perhaps a reason to maintain a separate project is for code style or other CDK architecture reasons?

revmischa commented 1 year ago

This construct does much of the same stuff NextjsSite does but without depending on SST. It's for people who aren't using SST but want to use CDK with open-next.

kevin-mitchell commented 1 year ago

Thanks for the response! So the "...but without depending on SST" part I do understand 100%. This is the exact reason I came to this project.

What I'm wondering is if there is a path where there is more of a direct 1:1 copy / refactor (perhaps even automated through a custom script of some sort?) that takes the NextjsSite construct and removes the references to SSR.

Again I do realize that there is SST functionality that exists in the NextjsSite construct (hence jetbridge/cdk-nextjs), it just seems like the majority of functionality is very similar / the same and reducing the number of things to maintain is normally nice.

So my question comes down to whether or not this is something that's been considered but (for example) in reality it's a lot of work to remove the SST hooks, or people prefer to have cleaner, smaller constructs vs "everything basically in one construct" as in NextjsSite, etc.

I'm guessing it's simply "refactoring NextjsSite to free it of SST is non trivial, so we have this project".

revmischa commented 1 year ago

In my opinion it would be useful if NextjsSite made use of CDK-nextjs so users can pick the right tool depending on if they're using SST or not, CDK or not, or just open-next (which both NextjsSite and CDK-nextjs wrap) and remove some duplication of code. It would require sign-off from Frank who thus far has not weighed in on the matter when I brought it up.

A great place to discuss this is the open-next channel on discord: https://discord.gg/ezwvbeHC

revmischa commented 1 year ago

Another point to mention: this module is designed to be a bit more modular; if you want you can pick and choose the various sub-constructs to use in your stack or swap some out for others. This module provides NextjsDistribution for example, which you can use or you can swap it out for your own super-custom CloudFront setup. Same for the lambda function, layer, static asset deployment. Maybe that has some value to someone.

kevin-mitchell commented 1 year ago

Thanks for the thoughts. This all makes sense. Does seem ideal to have SST use this package instead (after of course making sure everything is on common ground), but I know there is a lot to that.

I'll close this and move discussion to open-next - thanks again and sorry for the noise!