After wrapping all this things in my head, I've came to conclusion, what I'm saying for more than a year, on the frontend u don't need anyting fancy, just dispatch actions like USER_CREATED and subscribe to all actions which is the projection part. With durrable objects I can see that u don't need ever again something like graphql, because inside the worker listening for the endpoints u just return back trhe response back to the FE and u react on those changes and update your local store or UI directly.
@@MichaelCannUk That brings to lousely decoupled microfrontends, where action from one service dispatched, the other service can subscribe to those actions This is scary. If this made every second kid to start using cloudflare, probably we see the death of microservices as we know, even things like kafka, because with blockchain we go in more distributed nature, which cloudflare duplication and sync problem, solves in pretty similar fashion as blockchain.
@@MrEnsiferum77 Ye, interesting thoughts. Each Durable Object could be considered a "Microservice" so possibly you are right. It works more like the actor model which I want to explore more in future videos so stay tuned :)
Hi Michael! I am in the process of building an event-sourced application in Cloudflare and found this video. This was fantastic - thank you for this! I second what Vlady mentioned here. Any plans on doing an updated video using these new products? Would love to get your take on where you’d implement queues and D1 in this architecture. Would D1 be the event store now? And queues good fit for the “processes”?
This looks fantastic Michael! Thank you for including the repo, its really helpful for learning.
Glad you like it!
Audio is a bit quiet... whoops! oh well :P
After wrapping all this things in my head, I've came to conclusion, what I'm saying for more than a year, on the frontend u don't need anyting fancy, just dispatch actions like USER_CREATED and subscribe to all actions which is the projection part. With durrable objects I can see that u don't need ever again something like graphql, because inside the worker listening for the endpoints u just return back trhe response back to the FE and u react on those changes and update your local store or UI directly.
Yep definately something like that. Its a powerful technology indeed that lends itself to the functional reactive paradigm well
@@MichaelCannUk That brings to lousely decoupled microfrontends, where action from one service dispatched, the other service can subscribe to those actions
This is scary. If this made every second kid to start using cloudflare, probably we see the death of microservices as we know, even things like kafka, because with blockchain we go in more distributed nature, which cloudflare duplication and sync problem, solves in pretty similar fashion as blockchain.
@@MrEnsiferum77 Ye, interesting thoughts. Each Durable Object could be considered a "Microservice" so possibly you are right. It works more like the actor model which I want to explore more in future videos so stay tuned :)
Have you used any libraries/framework for the Admin?
React was it I think :)
Hi Michael, now that some time has passed and Cloudflare Queues is in beta, would you change anything about your approach to this architecture?
Hi Vlady, oh yes for sure. Queues would make things a lot better, that combined with D1 would make this approach for ES suuuper powerful :)
This calls for another video!!
Hi Michael! I am in the process of building an event-sourced application in Cloudflare and found this video. This was fantastic - thank you for this! I second what Vlady mentioned here. Any plans on doing an updated video using these new products? Would love to get your take on where you’d implement queues and D1 in this architecture. Would D1 be the event store now? And queues good fit for the “processes”?