Microservices com Delphi — Parte Final


Uma arquitetura que utiliza Microservices tem seus prós e contras como qualquer outra tecnologia. Será que essa arquitetura foi uma boa escolha para o projeto?

Imagem

Introdução

No artigo anterior eu lhe mostrei como codificar uma Classe de Negócio para fazer a comunicação com um Microservice utilizando todo o arcabouço apresentado na primeira parte dessa série.

Nesse artigo você irá ver:

  1. Tratamento de Exceções: Quando algo dá errado nos Microservices ou na comunicação com eles;
  2. Links: Separei alguns artigos interessantes sobre o assunto;

Tratamento de Exceções

Todo software precisa tratar erros e exceções, e é claro que estamos fazendo isso.

Na Unit AcmeMicroServiceA.pas o tratamento de exceções é feito no método TMicroServiceClient.Send, verificando o Code de retorno do protocolo HTTP.

Se houver erro, definimos um protocolo privado que descreve como a mensagem para o Client deve ser. Nada mais é do que um XML com nodes específicos que descrevem o erro ou exceção.

Abaixo o código modificado que trata erros e exceções. O código em produção é um pouco mais elaborado, no entanto acredito que com esse exemplo você irá entender como o tratamento ocorre no projeto real.

function TMicroServiceClient.Send(
  const Content: string): IMicroServiceResponse;
begin
  with Response(Content) do
  begin
    Result := TMicroServiceResponse.New(
      Code,
      TXMLFactory.New('ISO-8859-1', Stream).Document
    );
    case Code of
      // BAD REQUEST
      400..499:
        raise EMicroService.Create(
          Result
            .XML
            .DocumentElement
            .ChildNodes['UserMessage'].Text
        );
      // SERVER ERROR
      500..510:
        raise EMicroService.Create(
          Result
            .XML
            .DocumentElement
            .ChildNodes['DevMessage'].Text
        );
    end;
  end;
end;

Repare que para cada tipo de erro/exceção, um node (ou nodes) específico é utilizado para obter a informação.

No Client Delphi, o Code também é acessível através da Interface IMicroServiceResponse, então o Client pode tomar decisões específicas para casos que não gerem uma exceção.

Veja aqui uma lista de HTTP Status Codes.

Separei alguns links interessantes de artigos e vídeos que serviram de inspiração para escrever essa série, assim como foram fontes de informações para o projeto.

Conclusão

A escolha pela arquitetura de Microservices está sendo satisfatória.

Microservices são como instâncias de Objetos pela rede.

Assim como Objetos, cada Microservice deve implementar apenas uma única responsabilidade.

Quando falamos sobre Microservices, WebServices, Multi-camadas, protocolos… tudo isso parece muito complicado. Mas se você souber como as coisas funcionam, poderá remover tudo que é desnecessário para o seu negócio e se concentrar apenas no essencial.

Você não precisa implementar tudo o que dizem para implementar. Utilize tecnologias que fazem sentido para seu negócio e comece simples.

A migração está longe de estar concluída. O sistema tem poucos meses, mas apenas poucos dias de trabalho full time na codificação e integração dos Microservices.

Por enquanto estamos indo bem.

Até logo.

Posts Relacionados

  • Mais Performance usando Argumentos "const" para Interfaces

  • Herança de Formulário é para Iniciantes

  • Eliminando Métodos Privados

  • Classes Aninhadas

  • API Unit: Tudo num só lugar

  • Injeção de Dependência sem XML, Atributos/Anotações ou Frameworks

  • Nomeando Classes em Libraries

  • Versionando e Organizando seus Pacotes

  • Xavier Package

  • Inter-process Communication