Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/todos #2

Closed
Rich-Harris opened this issue Apr 16, 2021 · 2 comments · Fixed by #4
Closed

/todos #2

Rich-Harris opened this issue Apr 16, 2021 · 2 comments · Fixed by #4

Comments

@Rich-Harris
Copy link
Member

In sveltejs/kit#1014 (comment) I proposed having a TODO app as part of the SvelteKit 'hello world' — it's more exciting than a blog, and gives us the opportunity to showcase some unique features.

Ideally the data would be accessed via an api.svelte.dev endpoint, I think, so that people aren't required to set up a backend to get the demo app working.

Rather than having people log in I was thinking along these lines:

  • when user first visits the site, we drop a set-cookie: userid=[uuid]; HttpOnly; path=/ header
  • when they return, request.context.userid === cookies.userid
  • an endpoint in the hello world app uses userid to create, read, update and delete TODOs

A TODO looks like this:

type Todo = {
  id: string; // uuid
  created: number; // timestamp
  text: string;
  done: boolean;
};

Does this sound reasonable?

@Conduitry
Copy link
Member

There'd have to be a local endpoint in the hello world app that proxies to api.svelte.dev right? Third-party cookies don't play well with SSR. Also, what do you think about having api.svelte.dev responsible for returning the set-cookie and then the local endpoint just proxies that? Spreading information about what the session cookie is called over two different project bothers me.

Separately, are you worried about deciding when to delete old sessions?

@Rich-Harris
Copy link
Member Author

There'd be a local endpoint, yes. Two, in fact — they already exist:

With the change proposed above we'd just swap out the db stuff therein with calls to this API.

Also, what do you think about having api.svelte.dev responsible for returning the set-cookie and then the local endpoint just proxies that?

I think there's some value in showing how you'd read a cookie in getContext and set one in handle. Is the alternative that the local endpoint forwards the cookie header when fetching from api.svelte.dev? Is that, like... a done thing? I guess that could work. I'm not sure what's more normal.

Separately, are you worried about deciding when to delete old sessions?

Nope — @pngwn pointed this out https://developers.cloudflare.com/workers/runtime-apis/kv#creating-expiring-keys

@Rich-Harris Rich-Harris linked a pull request Apr 17, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants