V poslední době jsem četl několik dobrých článků jak Elixir + gRPC: the road to production nebo Don’t use Go’s default HTTP client (in production) a zkoušel jsem hledat zda dokumentace v projektech vlastně učí vývojáře se zamyslet nad tím co poskytují jazyky jako základ a jak ve skutečnosti je potřeba potom aplikaci nastavit, aby šla provozovat dostatečně robustně a spolehlivě.

Klasický příběh je zmíněný v tom článku “Don’t use Go’s default HTTP client (in production)” a to jsou defaultní hodnoty timeoutu pro HTTP klienty. Například v tom článku, je zmíněný default 0 což znamená žádný timeout a to je asi ta nejhorší varianta. V Node.JS je default 120s a dalších jazycích je to například 60s (Ruby, PHP) apod. Je to opravdu zajímavé obzvláště pokud to porovnám se svým světem, kde Heroku zabije každý request za 30s a vy musíte aktivně pracovat na tom, aby jste těch 30s nedosáhli.

Všechno to jsou známé věci, ale nemyslím, že to všichni systematicky dělají. Skvělá dokumentace od Microsoft Azure o Transient fault handling to krásně popisuje a je jen škoda, že něco takového není pro každý cloud (Azure service-specific retry guidelines) a chybí někde pěkně dohromady například pro GRPC. Pokud někdo o něčem podobném týkajícího se GRPC víte, určitě mi dejte vědět. Za léta jsem slyšel hodně best practice většinou od lidí s Googlu, ale nikde v dokumentu detailně popsané konfigurace pro deadlocky a timeouty jsem nenašel.

Na závěr bych se zeptal, jak to děláte vy? Jsou věci jako circuit-breaker, retry a timeouts cizí věci nebo se jimi aktivně zabýváte? Jak to testujete? Jak to monitorujete? Rád si o tom popovídám a pokud vás zajíma Golang můžeme se nepříklad potkat na Golang Prague #4, kde budu mluvit o TinyGO což je poslední věc se kterou si hraju.