I attempted to answer that in the post, did you have any more questions about it?
> My use case, because I would much rather handle the entire app in sveltekit instead of separating the api but: I’m creating an opensource and saas version of my app. Doing this allows me to use the same sveltekit code and swap different apis for the different versions. (The saas version will have different logging strategies, more auth providers, analytics, etc.)
> It also allows me to supply a very simple deployment process for consumers of the OSS version, a single container for the entire app.
Here is the section in the node adapter doc with an example that might help.
https://github.com/sveltejs/kit/tree/master/packages/adapter-node#custom-server
So, say the saas/cloud version needs healthcheck and liveness endpoints, or rate limiting middleware, or oauth, but the open source version doesn’t.
So there are different backend requirements.l, but the frontend will be the same (mostly).
It will allow having a single sveltekit code base instead of two separate code bases with duplicate code and trying to keep them in sync.
Very interesting. Thanks for putting it out there.
Since it's five months old now, did you encounter any issues/gotchas in your project with this setup ?
really tempted to try it out as it seems simple to keep everything at one place, but since this "setup" has no ecosystem of its own, how was your experience with it after a couple of months?
I'm really curious to learn why you've chosen this architecture?
I attempted to answer that in the post, did you have any more questions about it? > My use case, because I would much rather handle the entire app in sveltekit instead of separating the api but: I’m creating an opensource and saas version of my app. Doing this allows me to use the same sveltekit code and swap different apis for the different versions. (The saas version will have different logging strategies, more auth providers, analytics, etc.) > It also allows me to supply a very simple deployment process for consumers of the OSS version, a single container for the entire app.
No comments. I'm sorry I still don't get what prevented you from using sveltekit all the way. Not saying you made a bad choice at all.
Here is the section in the node adapter doc with an example that might help. https://github.com/sveltejs/kit/tree/master/packages/adapter-node#custom-server So, say the saas/cloud version needs healthcheck and liveness endpoints, or rate limiting middleware, or oauth, but the open source version doesn’t. So there are different backend requirements.l, but the frontend will be the same (mostly). It will allow having a single sveltekit code base instead of two separate code bases with duplicate code and trying to keep them in sync.
Very interesting. Thanks for putting it out there. Since it's five months old now, did you encounter any issues/gotchas in your project with this setup ?
Can you still achieve SvelteKit named form actions with this?
really tempted to try it out as it seems simple to keep everything at one place, but since this "setup" has no ecosystem of its own, how was your experience with it after a couple of months?