DEV Community

Cover image for Refactoring a Request/Response based Go backend into Event-Driven using Pub/Sub
Marcus Kohlberg for Encore

Posted on • Updated on

Refactoring a Request/Response based Go backend into Event-Driven using Pub/Sub

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

Wrapping up

Top comments (6)

dyfet profile image
David Sugar

I could see potential use cases for this in developing cloud mediated and local collaboration services.

marcuskohlberg profile image
Marcus Kohlberg

That's a good idea. Interested to see what you can come up with!

dyfet profile image
David Sugar

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.

robert197 profile image

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.

marcuskohlberg profile image
Marcus Kohlberg • Edited

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:

  • 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 may not be for everyone, and that's all good! :)

lincolnava profile image

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.