Feature: Option to use standard lambda instead of lambda@edge for router

[alex-way]

Hey James,

Thanks for creating this library!

It's my first time using the serverless framework, but your example has helped me to get started and deploy my app via serverless 😎.

One thing I want to try to avoid is to deploy my stack to us-east-1 due to data compliance. However, it doesn't currently seem possible as the router has direct reference to CloudFront, and also enforces the use of custom headers. As you're aware, lambda@edge is only deployable to us-east-1 and as such I'd like to decouple from it, if possible.

I'm thinking of having an option in the adapter, which allows us to toggle the use of the router using lambda@edge, or standard lambda:

// svelte.config.js
import serverless from "@yarbsemaj/adapter-lambda";

/** @type {import('@sveltejs/kit').Config} */
const config = {
    kit: {
        adapter: serverless({
            edgeRouter: false // default true to avoid a breaking change
        })
    }
};

export default config;

I'm happy to start looking into this and attempting to provide a PR if you think it's achievable.

[yarbsemaj]

Hi @alex-way Thank You for your interest in my project!

White you are correct that lambda@edge functions are deployable to us-east-1 only (unfortunately) in reality they run all over the world in the location of the cache node that services the users request (hence the edge in the name).

However, it should not be necessary to deploy whole stack to us-east-1, I just wrote the serverless file this way for simplicity to get people up and running. What you would have to do is have two stacks (one with the ssr function and the bucket, and one with the cloudfront and the edge function). The one with the SSR function can be deployed first to the region of your choice, then using cloudformation outputs you can reference the bucket url and function url from the first stack in the second. You will just have to deploy both stacks. I would do this by having two yml files with diffrent names and using the CLI to specify which one you want to deploy.

I hope this helps you with your project.

A note of caution tho, I would hold off building anything complex you want to able to maintain until SvelteKit hits v1 as the team are often making breaking changes to the framework as its developed.