In this video André shows you how to refactor a REST-based Request/Response driven Go backend application into an event-driven architecture using Pub/Sub.
He uses Encore for developing and deploying the Go application, including fully automating infrastructure to locally run services, databases, and Pub/Sub.
🕹 Try it yourself
- Learn more about building Go apps with Encore using these Tutorials.👈
- Find inspiration on what to build with these Open Source App Templates.👈
Wrapping up
- ⭐️ Support the project by starring Encore on GitHub.
- If you have questions or want to share your work, join the developers hangout in Encore's community on Discord.
Top comments (6)
I could see potential use cases for this in developing cloud mediated and local collaboration services.
That's a good idea. Interested to see what you can come up with!
When I was doing wickr we used php for the backend and long poll, which we later supllimented with websocket for eventing, though websockets were never stable. Simple messaging does not care about multi-second delay, but notification for telephony and live calling does. I actually brought in people with experience in trading systems in NYC to fix those problems. But it was still like building backends with stone axes and bearskin rugs.
Most of the backend needs for secure messaging and secure calling are not complex, especially once you avoid things like sip. Much of the magic is really client side instead. If I wanted to go back to doing secure collaboration again, I know where I can find an experienced team to do that with, and I would prefer to focus mostly on the front-end side.
Even in FAQ they say, it's not a lock-in. It's a freaking big lock-in. Not only in the cloud but also in the encore itself. Also you do not even have the flexibility to switch easily from cloud SQL to for example alloy DB for scallability.
Dear encore team you are making another abstraction on abstraction of abstraction and trying to make money :P The cloud has gotten so much easier already.
349$ / user per month + additional costs for the cloud is super overpriced for just a framework with some cloud integration.
This kind of setup is done in a project in around 2 Months at the beginning of a project and then you do not have to pay big money for the entire project lifetime. Just maintaining and improving.
Nice website and nice sales/marketing but sorry I'm not convinced. I am a senior go dev but maybe encore is more something for Java developers.
Thanks for sharing your thoughts!
Adding some context regarding lock-in:
Everything you use for local development and everything running in your cloud is Open Source, so is tooling to generate standalone Docker images if you don't wish to use Encore's CI/CD and cloud automation tools. See more in the docs here: encore.dev/docs/how-to/migrate-away
Cloud lock-in is lessened if you use Encore, since you can deploy to different cloud providers without making big changes to your application. Of course there is always an element of being tied into your cloud providers of choice since you may not wish to migrate data or you use some specific managed services only they offer.
About pricing, we're trying to make sure we offer great value at a sustainable price. Our customers don't think Encore is expensive and they generally claim they get 10x value back. Where many early-stage companies fail is they run out of runway before they get to a sustainable scale, and this is exactly where Encore helps. Taking your example: saving months at the start can mean the difference between life and death for a new business.
And we like to think the productive workflow doesn't only matter at the beginning, rather it helps speed up iterations continuously by providing tooling for local dev, testing, and DevOps.
Here's what our customers are saying btw: encore.dev/customers
Encore may not be for everyone, and that's all good! :)
Refactoring a Go backend from Request/Response to Event-Driven with Pub/Sub architecture can enhance scalability and flexibility. By decoupling components and allowing emersonrfp asynchronous communication via message brokers like Kafka or RabbitMQ, the system becomes more resilient to spikes in traffic and enables easier integration of new features or services. Embracing event-driven design fosters a more responsive and adaptable backend architecture, aligning with modern distributed systems principles.