This is exciting, I could imagine Meteor going serverless one day!
Meteor’s forte is the reactivity via publish/subscribe of, typically, mongodb collections. That is what the server is for – among many other things, like login. In that sense, Meteor’s client and server are like a piston and the chamber in a combustion engine, it just won’t work if you get rid of either.
That said, “Durable Objects” still could be useful in a Meteor app as a new, stateful variant of microservices. I’m not sure if this is going to rock though.
Besides, “Meteor serverless” (should that become possible) would kill the business model of what keeps the company behind Meteor, currently Tiny, alive: it’s based on Galaxy, a server hosting platform.
I must confess, “Durable Objects” as a concept looks very interesting as far as serverless goes. But only as far. Whenever I’m looking at serverless, I can’t help but think what a lock in you get into just for the “convenience” of not dealing with the ops.
I also remember that there is profit to be made if you do your own ops and know what you’re doing.
This is an interesting concept indeed coming from a major provider.
If I understood this correctly, then I think they’ve used the word serverless for the buzz since it is not what people would typically think when they hear serverless. It seems more like a fresh implementation of a cloud pub/sub provider using JS classes/objects, similar to Firebase Realtime Database.
“We see Durable Objects as a low-level primitives for building distributed systems. Some applications, like those mentioned above, can use objects directly to implement a coordination layer, or maybe even as their sole storage layer.”
It might be possible to implement yet another Meteor scaling strategy, a pub/sub adapter package on top of the “Durable Objects” (i.e. Durable Object Oplog, similar to Redis Oplog), this would be very similar to the Meteor Streamer package and even Redis Oplog in terms of functionality but using the cloud as a provider.