Single Worker with DO,RPC and rrv7 with partial prerendering
ok i wonder if that's true because it seems like they are integrating something related to RPC as well
38 Replies
https://github.com/livestorejs/livestore/blob/ad4935a0c0043b32da18ca6c90ca37044cea009e/packages/%40livestore/sync-cf/src/cf-worker/durable-object.ts#L72
class WebSocketServerBase implements CfWorker.DurableObject, CfWorker.Rpc.DurableObjectBranded
Oh, that's hacky...
@HardlyWorkin' sry i don't mean to question it but someone from cloudflare,i have to find where i asked this, already told me i wasn't able to define a durableobject class without extending from durableobject. going to use this library to confirm whether or not rpc won't work but
dude you have no idea how much this breaks me
It looks like they manually brand the DurableObject with
__DURABLE_OBJECT_BRAND, which might make the runtime allow RPC?spent the last few weeks dealing with how to get around cloudflare:imports breaking full stack frameworks that prerender
ya i know
I haven't tried it myself, but maybe it works?
ya the maybe is my prayer
i don't know whats true anymore
ok ty though for confirming that its at least hacky
will try it out tonite thanks for the quick feedback
i wonder if that's why i was inadvertantly gaslit into being told that you couldn't define it without using the cloudflare: import
It implements the DurableObjectBranded interface also so unless they implemented it wrong, it will be able to use RPC
what is even the point of forcing us to have to use the cloudflare:* imports
I don't know about you, but I find it easier to do
extends DurableObject than trying to apply a brand manually, and also apply types to the DO class itself anywayIt's work to use
implements over using the base class implementations with extends so that's why the Cloudflare person told you what they did.ok yes i understand that but itseems like you could have just abstracted that away in @ cloudflare/workers-*
Also, the import is variable based upon the compatibility date. They can bake implementation details into the base class.
i'm assuming one or both of you are cloudflare employees so i'm just going to say my piece once on this bc i have to fake shout at someone over there.
The eventual goal is to reduce usage of
@cloudflare/workers-types(to be clear, it's not going anywhere for the forseeable future, at least not to my knowledge). wrangler types should generally generate types compatible with the compatibility dates/flags you select, in a way that @cloudflare/workers-types would struggle to matchCathartic release is important!
your cloudflare:* imports combined with the fact that you cannot separate the export definitions outside of the main class into secondary means that for full stack frameworks that allow you to do partial prerendering ... you CANNOT GET around the build breaking because node chokes on the cloudflare:* import
Hmmm, I wonder how the vitest integration gets around that since I think it's node-based also
i had to do weirdo stuff to get around this
because they import the wrangler unstable proabably
but the problem is i can't do that for react-router build for instance without rearchitecting that mess of a framework
Afaik it just marks
cloudflare:* imports as external
Just like node:*That makes sense
OK but the problem is that full stack frameworks that are vite based when they try to do prerendering will load the main entry point into node (from the ones that i've found)
they build the client,ssr then they import main and send it the request to render the page
cloudflare/vite-plugin "fixes" it by shortcircuiting the ability to prerender. PROBLEM SOLVED... move on
that issue is sitting in the backlog never to be resolved
meanwhile i just could have done this
anyway sorry love everything that cloudflare is doing EXCEPTING THE GDAMN cloudlfare:* imports
i get it your special i agree with that
just recognize that stuff leaks into node
my god this ate up a 20% of a month of my life
Couldn't you split out the actual entrypoint into a separate file? If you aren't using the
vite-plugin, then you can't use DOs directly in dev anyway. And with a separate entrypoint for Vite Dev/vs your Worker, you shouldn't ever hit a cloudflare:* importyou can use d0's with out the vite plugin with out isseue
the issue is they have to exported from the main class.
the work that i did was to create multiple vite entrypoints separate worker entry point from the rr entry point and make that what rr build loads
the problem with that is that you have to completely separate the two no cross contamination which was not failing until i did something with the loadcontext. then the only time rr touches cloudflare was through the load context after its initialized on the worker side. but it causes a performance hit
tl;dr i nerfed the worker side so that all real functionality that needs anything from the rr side now had to function in the rr side
my problem could be solved if the DurableObject class did not have to be exported from the main class.
i seem to be confused by why cloudflare:* exists. i thought it had something to do with native only. i get it for actual method functionality that expects workerd to be the runtime its running
but if a durable WITH rpc can exist from the workers-types then i don't know anymore outside of actual workerd native only functionality
and the one thing you can get around is you can "dynamic import" a baseclass you plan on extending from
anyway @HardlyWorkin' @Larry thank you and apologies
please don't do this if something needs to be in cloudflare:* yes i understand that but if its a class or anything that might be seen by, resolved,loaded then please leave it in something other than cloudflare:* specifer
either that or build nodejs loaders please even if they are mocking the resolved modules
No apology necessary. I took it as good natured venting from someone who obviously has skills and determination.
it was based on a wrong assumption as well i should have seen that the durableobject definition weren't based on some native runtime object dependency ... i had dived deep into workerd and seen the interfaces but itwasn't until looking at this project that i realized i was wrong
The fact that the import contents can change automatically with the compatability date is a good tradeoff in my mind. When you put it in a library, like
agents and you want to evolve the platform itself in a way that matches the abastract base class definition, then you run the risk that someone will try to use the a version of the library that doesn't match the platform compatability date.also a cloudflare dev somewhere confirmed my wrong assumption
i'm all good with that it just shouldn't be a cloudflare: import specifier
cloudflare:* should be reserved for anything that actually needs the runtime
They are human and the platform has gotten quite complex so forgive them.
I actually don't know if we guarantee that just branding a DO will work in the future, and that you won't need the import specifier
Also, most people asking don't have the ability to understand a nuanced answer nor the patience to read a long one. I sometimes give a simple (but wrong on the edges) answer here.
i recognizes that and i'll have to come up with something else i just feel like its unecessary if you're not going to suport nodejs import loaders or by simply using @ cloudflare/**
it looks like this works. not sure why everyone is +1 'this. it doesn't seem like there's any need for keeping this in the cloudflare:* namespace. i think this is a problem that cloudflare is not aware for but if you look at tanstack,react-router,waku and probably any other framework that i've seen you can't merge the idea partial prerendering with a DO because of the way all of these frameworks have assumed that that they'll be able to resolve and load the server side. injecting wrangler dev server would be a fix for this. but also a nodejs import loader to resolve and load mocked versions of these modules. once again this shouldn't apply to anything that you can dynamically import a function but unfortunately that can't work with an export class definition to my knowledge
it looks cool i grant you that just alot of ppl have just given up on this. the venn diagram of ppl who like cloudflare and a full stack framework with the idea of partial prerendering to the point of complaining is probably too small
I gave up on part-time server-side render all together. The juice never seemed worth the squeeze.
Build time prerender definitely worth the squeeze if you have a alot of stuff that's going to be need it and the assets binding is there
I generally build interactive apps with database back-ends. I believe prerender mostly benfits content-heavy situations.
i hear you but none of that explains the cloudflare:* import specifier for parts of the cloudflare sdk that that aren't specific to the runtime
i thought it was a justification for the durableobject base class because it was specific to workerd but its not necessary
and the argument that there's too much changing from the api doesn't impress because you could say the same thing about the stripe, aws,.... sdk's
It's impossible to know what parts might eventually become specific to a runtime compatability date though. Also, if you need it for some, you may as well use it for all. That's preferrable to having to remember which parts are in which import.
@HardlyWorkin' can i make a suggestion for this?
I literally doesn't see the difference between cloudflare:* and scoped packages with dates/typescript type math.
But if something does need to be customized to the compatibilities flags in the wrangler config:
then if wrangler types exists then why not wrangler classgen along side or maybe even in wrangler types call.
a simple vite-plugin won't do because you're missing on the basic assumption that these full-stack frameworks expect this to be node.
and/or an alternative/complement to wrangler types/classgen: would be if wrangler could function as a subsitute for node eventually meaning that in a non workerd runtime its a pass through for the current node with import handler loaded to at least handle the cloudflare:* import specficier you have wrangler types --experimental which i imagine will be the standard as a way to get rid of cloudflare/worker-types including class definitions in there would be a great complement alongside the cloudflare:* space k screams into the void end of thread
and/or an alternative/complement to wrangler types/classgen: would be if wrangler could function as a subsitute for node eventually meaning that in a non workerd runtime its a pass through for the current node with import handler loaded to at least handle the cloudflare:* import specficier you have wrangler types --experimental which i imagine will be the standard as a way to get rid of cloudflare/worker-types including class definitions in there would be a great complement alongside the cloudflare:* space k screams into the void end of thread