Migrate to partyserver (cloudflare/partykit)

[jessa0]

PartyKit was moved to cloudflare/partykit on github (from partykit/partykit), and the new packages had a 0.1.0 release two weeks ago. This PR migrates to the new partyserver package replacing partykit, and y-partyserver replacing y-partykit.

This probably needs a major version bump, as I didn't see any guarantee of compatibility with the old PartyKit, though it was pretty close to compatible, at least. Old clients will definitely not be compatible, as I decided to use YServer's new CustomMessage API instead of overriding onMessage, since the old way of sending playhtml-layer messages relied on PartyKit just incidentally not using text websocket messages. Please let me know if I should create a changeset.

Motivation: I am experimenting with playhtml, but wanted to deploy in the "cloud-prem" configuration (PartyKit on own cloudflare account). I got stuck with PartyKit not being able to deploy to a free Cloudflare account, and noticed advice from the PartyKit authors (but can't find the link to that conversation, sorry..) to migrate to cloudflare/partykit instead. So I went down that rabbit hole..

[jessa0]

Fixed a bug with loading from DB. I haven't tested this PR with supabase yet (I probably will this week).

[spencerc99]

thanks for making this! my main worry with that we don't run into any data loss. im gonna check in with the partytkit authors to get a second pair of eyes

[spencerc99]

nice good catch

[jessa0]

It'd probably be even better to do --include-runtime=true as well, since @cloudflare/worker-types is mostly deprecated, and there seemed to be a couple type errors I couldn't seem to fix with @cloudflare/worker-types as well.. I just wanted to run that by you first. That flag generates more accurate types for the entire runtime, based on the compatibility_date you set in the wrangler config.

If you wanna do that, I'd also ask if you rather have the worker-configuration.d.ts checked in to the repo or generated at compile-time.

[jessa0]

thanks for making this! my main worry with that we don't run into any data loss. im gonna check in with the partytkit authors to get a second pair of eyes

That makes sense. I can also give it a second pass with data migration in mind if you want, as I didn't really do that for this draft.

[spencerc99]

hi @jessa0 sorry for the delay here! couldn't get a hold of the partykit folks but i think it should be fine since im persisting the data separately anyways.

going to actually take a look this week. thanks for putting this up again!

[spencerc99]

@jessa0 im actually curious - could you try deploying this as you originally desired and swapping in your provider URL for use with the playhtml library and seeing if everything works?

If there is danger of compatibility for me switching the main partykit server while the partyserver package is still in development to parity, we can hold off on merging this in, but that doesn't stop you from using this version to do your own on-prem since you'd just be swapping in the provider URL

[jessa0]

@jessa0 im actually curious - could you try deploying this as you originally desired and swapping in your provider URL for use with the playhtml library and seeing if everything works?

I finally got around to testing this, and the new partykit stuff does seem to be backward compatible: I tried deploying the new partyserver, and could switch between the new and old client codebases with the latest data loading on each. I played around with the objects on the main page and on the fridge. The cursor code is currently loaded separately from your domain, so I didn't properly test that.

Edit: What I said about compatibility in the PR description -- "Old clients will definitely not be compatible, as I decided to use YServer's new CustomMessage API instead of overriding onMessage" -- still holds though, in that any custom messages (e.g. "room-reset", "add-shared-reference", "register-shared-element", events sent through dispachPlayEvent, etc..) won't be communicated between new and old clients. However, new client <-> new client obviously works, and old <--> old might still work (but I haven't tested that).

Edit 2: Old client <-> old client custom messages do not work. I just confirmed by trying experiment two, which did not show confetti when clicking on the old client, but did work with the new client. I guess this makes sense, given that I removed the code in the partyserver that relays the old client messages (lol), but its been a while since I wrote this PR now. I actually have an idea to fix this to maintain compatibility between new and old clients, if you want? Let me know.

[jessa0]

If there is danger of compatibility for me switching the main partykit server while the partyserver package is still in development to parity, we can hold off on merging this in, but that doesn't stop you from using this version to do your own on-prem since you'd just be swapping in the provider URL

Oh, is there missing functionality in the new partyserver package? I didn't run into anything that you used that was removed.

[spencerc99]

It doesn't have to be backwards compatible with old clients if i understand what you mean by that (browser tabs that haven't refreshed the page)? So they would just be able to refresh and be on a new client and connect properly?

If that's the case im happy to take a look at merging this in next week (sorry for all the merge conflicts..)