As informações desta página não estão completamente disponíveis no seu idioma de escolha. Esperamos disponibiliza-las integralmente em outros idiomas em breve. Para ter acesso às informações no idioma de sua preferência, faça o download do PDF aqui.
Técnicas
Request-response events in user-facing workflows
NOT ON THE CURRENT EDITION
This blip is not on the current edition of the Radar. If it was on one of the last few editions it is likely that it is still relevant. If the blip is older it might no longer be relevant and our assessment might be different today. Unfortunately, we simply don't have the bandwidth to continuously review blips from previous editions of the RadarUnderstand more
Published: Nov 14, 2018
Nov 2018
Evite
On a number of occasions we have seen system designs that use request-response events in user-facing workflows. In these cases, the UI is blocked or the user has to wait for a new page to load until a corresponding response message to a request message is received. The main reasons cited for designs like this are performance or a unified approach to communication between backends for synchronous and asynchronous use cases. We feel that the increased complexity—in development, testing and operations—far outweighs the benefit of having a unified approach, and we strongly suggest to use synchronous HTTP requests when synchronous communication between backend services is needed. When implemented well, communication using HTTP rarely is a bottleneck in a distributed system.