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?

[Rich-Harris]

Something else I've just realised: for whatever reason, the todos page doesn't work on StackBlitz (https://sveltekit.new). Unclear whether it's a fixable bug or an inherent limitation, but could turn out to be another good reason to change the demo

[jycouet]

Yes, userid is set in cookies and it seems that StackBlitz can't support this without customizing some browser settings.

In a demo remote fetch is nice to showcase imo. But maybe only reading data is sufficient?
And a second part with some local things?

I'll be happy to help, let me know how.

[samal-rasmussen]

Here's a screen recording showing the janky behavior you get when clicking on the todos tab in the demo app.

It freezes the ui for a short second giving a rather janky first impression of sveltekit.

Screen.Recording.2022-06-30.at.15.31.44.mov

As I understand it, this is because sveltekit waits for a request to finish before doing the transition to the todos page. Is there a way to make the transition happen before the request has a response and then show a loading indication on the page until it does?

[samal-rasmussen]

OK, so I've tried investigating this a bit further to see if I can find a path forward here.

Rich's comment here gives me the understanding that the point of the todos page is to demonstrate persistence and dynamic SSR. I take it that persistence here means that there has to be a network request to a remote server that persists the data. And dynamic SSR means the ui should be able to render on the server using data that is not statically stored with the source code, but rather fetched from somewhere else at render time.

Neither of these two requirements make the ui freeze when clicking todos necessary as far as I can tell. When clicking todos we are doing client side rendering and not SSR, right? So waiting for SSR should not be a limitation. I see no reason why the ui couldn't do the page transition even if the server is doing some async fetching of persisted data before returning a response. After the page transition we could just use the await block to show some loading state while waiting for this data in the todos component.

In theory this makes sense to me. But as far as I can tell Sveltekit endpoints are based on load functions which are implemented such that they always block rendering when they are async.

[jycouet]

In SSR I think it makes sense to block, but in client-side navigation, it makes less sense (you can fill a store that will update when it will update).

So depending on cases (client-side navigation or SSR), I trick the effect of await in my apps.

You can check #4447 for some more detail.

[UltraCakeBakery]

How about just displaying the latency / response time after each submit below the submit form? Or some status updates about what the request is doing?