Remove network calls from demo app

[benmccann]

Describe the bug

I have seen so many people complaining that SvelteKit is slow. No one realizes that a locally created demo app would be making network calls.

E.g. https://discord.com/channels/457912077277855764/939868205869072444/950313663850508328

This would also solve our issues around eventual consistency: #1564

Reproduction

I don't know if these people have particularly slow network connections or the app or host is sometimes being quite slow

Logs

No response

System Info

N/A

Severity

annoyance

Additional Information

No response

[Conduitry]

Even without the speed concerns, I'd be in favor of a tiny ad-hoc in-memory data store thing for the todo app rather than calling out to the Cloudflare KV API.

[am283721]

I'm wondering if it's an issue with the API being served from somewhere in North America and certain users on other continents experiencing unusually slow network performance?

I also think some sort of in-memory data store would provide a better/more consistent user experience as long as it's still able to demonstrate the same functionality that is shown with the current setup. Specifically things like utilizing fetch, handling redirects, method overrides, etc... Having a demo that interacts with an external API is very useful as most people will need to do the same, and showing some best practices helps them get started on the right foot.

An update here could also be an opportunity to add functionality demonstrating shadow endpoints (unless that would create too much confusion for new users).

[Rich-Harris]

Semi-related issue here: #4225. Certainly not averse to overhauling the demo app.

The trouble is we're forced to choose between two options:

1. Provide a backend (api.svelte.dev) that allows people to play around with endpoints and test dynamic server rendering in a way that works locally and when the app is deployed, or
2. Use something in-memory or filesystem-based, which provides a great development experience locally but won't persist any data when you deploy the app

I'm a little uncomfortable with the idea of a demo app that stops working the minute you deploy it. Which leaves option 3 — don't demonstrate persistence and dynamic SSR — but then we're failing to demo a significant aspect of SvelteKit's functionality.

[baseballyama]

IMO...

By default, the Demo app will use an in-memory object.
And as default, commenting out files that connect to the API,
If users want to try to use API also, then users can use the commented-out files.
(Or users can toggle these modes on the app.)
Then users don't need to feel bad experience.
And even users can try persistence and dynamic SSR if necessary.

[am283721]

I was thinking using something like json-server could provide a good middle-ground, where a full rest api could be utilized but the backend is running in the same environment as the frontend.

To me, persisting data between a local dev environment and a deployed environment isn't that important, considering in most real-world scenarios you wouldn't want that either.

The main downside I can see of using something like json-server is introducing a 3rd party dependency to the demo app that might require future maintenance. Secondarily, it adds a little more code and complexity to the demo app.

[aolose]

I prefer the app to send these requests, it is closer to reality. We need a more friendly interactive experience.
For example, you could add a status display to each new todo item instead of waiting for the request to complete before adding it to the list.

[Rich-Harris]

To be clear, the issue isn't persisting data between local and deployed, it's having a backend that works both locally and deployed

[baseballyama]

it's having a backend that works both locally and deployed

I may not be getting it correctly, but #4266 stores data for each user, so there is no data conflict even if multiple people connect to the deployed app. The only issue is losing all data when the app is deployed.
(But personally, I think this is a smaller issue than a bad experience.)

[alexiglesias93]

If the confusion is around the loading speed difference between static pages and the TODOs page, perhaps a simpler solution would be to just add some Loading states in the UI that explicitly show that the app is performing some requests in the background?

• Show a Preloading Indicator when navigating through pages.
• Show a loading spinner when creating/updating/deleting a TODO.

[jcalfee]

I see the recent skeleton is using https://api.svelte.dev .. My browser offered up some autocomplete data and because I had not reviewed all the skeleton code first (trying it out so to speak) I was surprised to see only local calls in the browser's console but 3 local calls taking almost a second each. The autocomplete entries added from the browser and confusion poses a small security risk. Also, I was wondering if there was a bug in the update and rendering but I found this issue which clarified everything.

Maybe add an checkbox to use the remote API or not so it is easy to verify the feel of a the local only API calls and with a store when unchecked. And of course a loading indicator.

[jycouet]

Could we imagine providing both experiences with an environment variable switch?
(Defaulting to false)

const base = localDev ? 'http://localhost:3000/api/local_api_svelte_dev' : 'https://api.svelte.dev';

And implement get post patch del in api/local_api_svelte_dev?

After, the question is: Is it a realistic demo?