This edition
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
Past editions
As we as humans must stay in the queues for bananas, the Gophers should sometimes stay organised too. You may use various technologies for simple queueing, but you can also easily use Postgres too. Write the reliable consumers in Go on top of Postgres tables and keep your architecture simple...
As a part of our commitment to sustainability, we’re planting “Speaker’s trees” on behalf of our speakers. These trees represent our effort to offset the carbon emissions from their travel. By planting trees, we’re helping to reduce our carbon footprint and combat the effects of climate change. Join us in this symbolic act and help make our conference eco-friendly.
