Last 12 weeks · 0 commits
1 of 6 standards met
There's no 404 handling for the docs: https://github.com/sveltejs/api.svelte.dev/blob/master/src/routes/docs.ts This line returns a 200: https://github.com/sveltejs/sites/blob/1c83a81d3957812a2986c6c50667d3cfca790980/sites/svelte.dev/src/routes/blog/%5Bslug%5D.svelte#L5 And so https://svelte.dev/blog/foobar returns a 500 rather than a 404
Repository: sveltejs/api.svelte.dev. Description: The API worker source for https://api.svelte.dev Stars: 14, Forks: 3. Primary language: TypeScript. Languages: TypeScript (92.5%), JavaScript (7.5%). Open PRs: 1, open issues: 0. Last activity: 3y ago. Community health: 37%. Top contributors: lukeed, Rich-Harris, pngwn.
Now that we have three demo apps deployed... https://sveltekit-canary.vercel.app/todos https://netlify.demo.svelte.dev/todos https://svelte-kit-demo.richard-a-harris.workers.dev/todos ...it's clear that Workers KV isn't a viable solution for the Todos app. The CFW implementation works as expected, but the Vercel and Netlify ones both behave in a... somewhat absent-minded fashion. (Add/toggle/delete a few todos and refresh the page to see what I mean, or disable JS and try to interact with the app. It's chaos.) Regardless of where the blame lies, Vercel and Netlify are massively popular and the demo app needs to work correctly with them. We can't expect people not to conclude that SvelteKit itself is the problem. A few ideas for alternatives: Durable Objects Pros we stay in Cloudflare-land a Svelte core team member happens to be a Cloudflare developer advocate pricing seems reasonable Cons they seem a bit... weird — seems like quite a complex way to store data worktop doesn't work with DOs yet they're in beta Fauna Pros they claim to have fast global replication, avoiding the inconsistencies we're seeing HTTP-centric generally seem quite well-regarded Cons minimum $270/yr fugly query language Supabase Pros postgres 😍 😍 😍 well-positioned to support other future use cases — auth/user management, realtime Cons minimum $300/yr quite new, not battle tested (JS client is a bit of a mess, easier to use HTTP) latency for users who aren't near the instance I don't think cost should be a dealbreaker since we're sitting on unused opencollective funds. But it is a factor. Thoughts on all this? Suggestions for alternatives? Do the issues we're encountering also apply to REPL apps (i.e. should we move storage _generally_ away from KV?) or do we think we're in the clear? (The benchmark being 'a user should be able to save a REPL and refresh the page, reliably, without seeing stale data.)