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.