Let's Go asynchronous

During this talk I would summarize the cases where the synchronous communication is the right choice and on contrary where it is causing problems and it is better to pick the asynchronous one. Throughout the presentation I will combine the slides with actual code comparing the two principles on real simple examples to let the listener to better imagine the impacts. I will show how it is easy to implement load balancing/throttling/rate limiting to prevent Go apps from overwhelming just by switching to asynchronous communication. Also the implementation of retries mechanism will be shown as one example where asynchronous communication may be used. For the examples I will use regular Http server written in Go as a example of synchronous code and consumers using RabbitMQ and PGQ to cover the asynchronicity. The summary of the talk will be, that before designing some feature, you should think twice, whether it is not better to do design it in asynchronous way. And if you decide it is better to make it asynchronous, that it is not a big deal to actually implement it in Go using already existing tools and libraries.

LEVEL: Intermediate

Place
GoLab Deep
Length
40 min
When
November 12th, 2024
12:30

Abstract

DESCRIPTION:

In today's world the monolithic services are quite rare. Instead, a lot of projects and products are designed by splitting into multiple smaller pieces and these pieces must usually be able to communicate with each other. Sometimes it is just fine to implement the communication in synchronous request-response mode as We're all taught by Go HTTP server tutorials. However, in almost every project comes the day, when some specific use-case would need quite different approach of processing. Just shout out to the other service: do something and do not care anymore. In this case the asynchronicity comes on the stage. During this talk I will show you the common use-cases, where the asynchronicity may be the right choice and describe the reasons.
In the demos I will try to reveal the biggest benefits of async communication, but also mention the situation where it usually does not make any sense and is better to stick with notoriously known synchronous way.

There are a lot of tools and libraries, which a developer can use to make his services communicate asynchronously. Plenty of them are even open-source and they have built communities and tooling around them. This brings the developers to the situation where they must decide which option to pick and which way to go, also considering current project situation and constraints. It is usually good to start with simple working one, that matches your need, rather then trying to find the one optimal tool matching 100% of your need, which you probably never find. One of such simple tools in the OSS go package PGQ, which I will use during the demos in this presentation.

GoLab is a conference made by Develer.
Develer is a company based in Campi Bisenzio, near Florence. Our motto is : "Technology to give life to your products". We produce hardware and software to create exceptional products and to improve industrial processes and people's well being.
In Develer we have passion for the new technologies and we offer our clients effective solutions that are also efficient, simple and safe for the end users. We also believe in a friendly and welcoming environment where anybody can give their contribution. This passion and this vision are what we've been driven to organize our conference "made by developers for developers".


Subscribe to our newsletter

We hate spam just as much as you do, which is why we promise to only send you relevant communications. We respect your privacy and will never share your information with third parties.
©2024 GoLab | The international conference on Go in Florence-Design & devCantiere Creativo-Made withDatoCMS