Decide approach to code splitting / routing

[juranki]

sveltejs/kit#2931

[steffenstolze]

Hey @juranki
I'm trying to dig into your project and to understand what's happening :)

I understand that you use one Lambda@Edge function whose handler imports the whole SvelteKit app, does SSR when necessary, otherwise just instructs CloudFront to provide the pre-rendered page.

Could you please help to understand

• why did you chose Lambda@Edge over API Gateway + {proxy+} + regular Lambda pattern? Isn't there a risk that the code reaches the Lamda@Edge quotas?
• Isn't it considered best practice to have many small functions?
• Is this exactly the topic of this issue, to split the application into several lambdas?

Thanks! And please keep up the good work!

This is the only AWS adapter working with the latest sveltekit version out in the wild - afaik. Cool!

[juranki]

I understand that you use one Lambda@Edge function whose handler imports the whole SvelteKit app, does SSR when necessary, otherwise just instructs CloudFront to provide the pre-rendered page.

Correct.

why did you chose Lambda@Edge over API Gateway + {proxy+} + regular Lambda pattern? Isn't there a risk that the code reaches the Lamda@Edge quotas?

The primary reason is the mechanism Lambda@Edge provides for handling pre-rendered pages. Secondary reasons include simplicity and less network hops, thus potentially smaller latency (haven't measured though)

There is a potential for hitting the quotas. The relevant ones are response size (1 MB) and compressed size of the handler (50 MB). For most use cases those should be reasonable, although it's easy to come up with cases that could be problematic.

Isn't it considered best practice to have many small functions?

With many small functions you can possibly reduce startup time and avoid function size quota, but at the same time the number of cold starts increases. Pick your poison :)

Is this exactly the topic of this issue, to split the application into several lambdas?

Yes, and currently I think this is in some-day-maybe category. The complexity is significant and I'm not sure if it's possible to map SvelteKit routes to CloudFront behaviour patterns.

[aihaddad]

Great work on this. I'm still trying to learn Sveltekit and dive deeper into CDK, so take my points with this in mind. I am starting at the end (i.e. deployment) because this has become my natural way of thinking.

1. I am curious as to how would the "many functions" option mentioned be implemented? Demo app only has one Server, so can you elaborate more on that?
2. It could be a good idea if there's a constructor prop that let's you choose Lambda or Lambda@Edge (though, maybe after your desired robustness is achieved)

[juranki]

Hello @aihaddad,

1. SvelteKit produces javascript files that implement the server. Not all routes need all files. SvelteKit also produces dependency information between routes and files, which could be used by adapters to create separate (and potentially smaller) handlers for different routes.
2. Lambda@Edge provides good facilities for handling pre-rendered pages when it's deployed as origin request handler. With lambda that would be much harder. On the other hand, with lambda you can control the region it runs on. Maybe worth considering at some point, but definitely not now.

[aihaddad]

Thank you @juranki

Regarding point 2, Lambda@Edge is definitely the better/best/only option for pre-rendered static and client pages, I was referring more to SSR. Basically everything beyond line 38 (as far as I understand) where it can probably be delegated to another Lambda, and that's the one where the choice can be given