{"id":4245,"date":"2022-05-16T21:42:24","date_gmt":"2022-05-17T00:42:24","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=4245"},"modified":"2024-01-12T18:20:35","modified_gmt":"2024-01-12T21:20:35","slug":"iniciando-o-design-arquitetural-de-um-chat-online","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/","title":{"rendered":"Cap 4.2 Iniciando o design arquitetural de um “chat online”"},"content":{"rendered":"H\u00e1 diversas solu\u00e7\u00f5es de chat online\u00a0<\/em>dispon\u00edveis no mercado, com funcionalidades para todos os interesses e pre\u00e7os para todos os bolsos.<\/strong> Mas, se voc\u00ea for “desafiado” a criar uma solu\u00e7\u00e3o autoral, \u00e9 bom estar preparado.\n
\n

Nesse cap\u00edtulo, vamos utilizar alguns dos conceitos discutidos nesse livro para “pensar a arquitetura” de um sistema de chat online<\/em>.<\/strong> Nosso objetivo n\u00e3o vai ser fazer uma proposta completa, tampouco definitiva, mas “aquecer os motores”. Obviamente, iremos trabalhar um um cen\u00e1rio fict\u00edcio (afinal, precisamos de algumas delimita\u00e7\u00f5es para nossa solu\u00e7\u00e3o).<\/p>\n

O que \u00e9 um “chat online<\/em>“<\/h2>\n

Todo mundo gosta de um bom bate-papo, n\u00e3o \u00e9 mesmo?\u00a0Chat online\u00a0<\/em>trata exatamente disso – conversa, utilizando alguma ferramenta espec\u00edfica para esse prop\u00f3sito.<\/strong><\/p>\n

H\u00e1 quem converse por texto, trocar fotos, mensagens de \u00e1udio ou v\u00eddeo. H\u00e1 tamb\u00e9m quem goste de enviar e receber documentos. As conversas online podem ser entre duas pessoas (assumindo que uma parte leia a e responda) ou entre um grupo de pessoas.<\/p>\n

Em quase todas as ferramentas para trocas de mensagens voc\u00ea poder\u00e1 manter uma rede de contatos (amigos) e saber quem est\u00e1 online\u00a0<\/em>ou\u00a0offline.<\/em><\/p>\n

O ICQ foi uma das ofertas pioneiras desse tipo de aplica\u00e7\u00e3o para chat online<\/em>. Hoje em dia, alguns servi\u00e7os populares s\u00e3o Whatsapp<\/em> e Facebook Messenger.<\/em><\/p>\n

Muitas empresas oferecem interfaces de atendimento atrav\u00e9s de servi\u00e7os de mensagens instant\u00e2neas.<\/p>\n

Um instrumento para a transforma\u00e7\u00e3o digital<\/h2>\n

Um dos pilares da transforma\u00e7\u00e3o digital \u00e9 estreitar as rela\u00e7\u00f5es das organiza\u00e7\u00f5es com seus clientes, fornecedores e parceiros.<\/strong> Nesse contexto, aplica\u00e7\u00f5es de\u00a0chat\u00a0<\/em>est\u00e3o se tornado cada vez mais populares.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Explicando e justificando a transforma\u00e7\u00e3o digital e \u00e1gil<\/p>\r\n

Transforma\u00e7\u00e3o Digital e \u00c1gil<\/p>\r\nEm d\u00favidas do que \u00e9, de fato, transforma\u00e7\u00e3o digital e \u00e1gil? Nesse cap\u00edtulo, apresento alguns conceitos fundamentais para te ajudar no entendimento desse importante movimento.\r\n

Ler cap\u00edtulo<\/a><\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Coletando informa\u00e7\u00f5es para o Haiku<\/h2>\n
\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Architecture Haiku<\/p>\r\n

N\u00e3o sabe o que \u00e9 um “Architecture Haiku”? Consulte agora esse t\u00f3pico no cap\u00edtulo em que tratamos sobre documenta\u00e7\u00e3o de software.<\/p>\r\nAcessar t\u00f3pico<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

As funcionalidades em servi\u00e7os de chat online <\/em>variam bastante. Todos os dias, funcionalidades s\u00e3o incorporadas nas solu\u00e7\u00f5es l\u00edderes de mercado visando tornar a comunica\u00e7\u00e3o mais flu\u00edda – conversas em grupo, rea\u00e7\u00f5es, respostas espec\u00edficas, etc.<\/strong> Em nosso cen\u00e1rio fict\u00edcio, o objetivo \u00e9 fornecer um servi\u00e7o leve de comunica\u00e7\u00e3o 1-para-1 (n\u00e3o haver\u00e1 suporte para grupos, por enquanto), apenas em texto.<\/p>\n

Queremos desenvolver uma solu\u00e7\u00e3o autoral, ou seja, sem depender de componentes prontos.<\/p>\n

Usu\u00e1rios poder\u00e3o utilizar o servi\u00e7o tanto com clientes web<\/em> ou em aplica\u00e7\u00f5es mobile<\/em>. S\u00e3o esperados 2 milh\u00f5es DAU (daily active users<\/em>). O tamanho m\u00e1ximo de uma mensagem \u00e9 de 100 KB, mas, estima-se que elas tenham um tamanho m\u00e9dio de 100 caracteres. Todas as mensagens devem ser armazenadas, para sempre, em servidores da organiza\u00e7\u00e3o.<\/strong><\/p>\n

Cada usu\u00e1rio poder\u00e1 possuir uma lista de “amigos”.<\/strong> O servi\u00e7o dever\u00e1 indicar quais “amigos” est\u00e3o online<\/em> em um determinado momento. Caso uma mensagem seja enviada para um “amigo”\u00a0offline,\u00a0<\/em>ela dever\u00e1 ser “guardada” at\u00e9 que ele possa receber.<\/p>\n

Um mesmo usu\u00e1rio poder\u00e1 estar conectado em mais do que um device\u00a0<\/em>simultaneamente.<\/p>\n

N\u00e3o h\u00e1 demanda por criptografia (que perigo!).<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\"\r\n

Confidencialidade, integridade e disponibilidade<\/p>\r\n

Seguran\u00e7a \u00e9 um tema amplo! Um sistema seguro garante a confidencialidade dos dados dos usu\u00e1rios. Deseja entender mais sobre isso?<\/p>\r\nAcessar t\u00f3pico<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Espera-se que o servi\u00e7o seja escal\u00e1vel e dispon\u00edvel.<\/p>\n

O time de “neg\u00f3cios” deseja que seja desenvolvido um padr\u00e3o propriet\u00e1rio para implementa\u00e7\u00e3o que ser\u00e1 incorporado como ativo da organiza\u00e7\u00e3o.<\/strong><\/p>\n

Conhecendo arquiteturas semelhantes<\/h2>\n

Antes de qualquer tentativa de produzir algum design<\/em> arquitetural \u00e9 importante buscar conhecer implementa\u00e7\u00f5es anteriores para problemas semelhantes.<\/strong><\/p>\n

Sabe-se, por exemplo, que o Whatsapp adota uma varia\u00e7\u00e3o, n\u00e3o documentada, de XMPP<\/a> – um protocolo extens\u00edvel de presen\u00e7a e troca de mensagens – em sua solu\u00e7\u00e3o.<\/p>\n

Facebook Messenger j\u00e1 adotou XMPP, mas, atualmente, utiliza solu\u00e7\u00e3o propriet\u00e1ria, baseada em MQTT<\/a> (um protocolo leve para trocas de mensagens, bastante popular em IoT).<\/p>\n

O Telegram utiliza um protocolo tamb\u00e9m propriet\u00e1rio, por\u00e9m documentado, chamado MTPro.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Conhecer arquiteturas de sistemas semelhantes ao que est\u00e1 projetando pode, al\u00e9m de inspirar e antecipar dificuldades, dar argumentos para discuss\u00f5es com o neg\u00f3cio.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

O que aprendemos observando esses sistemas? Troca de mensagens (chat) e defini\u00e7\u00e3o de presen\u00e7a s\u00e3o os componentes chaves nesse tipo de solu\u00e7\u00e3o.<\/strong><\/p>\n

Design de alto n\u00edvel para a troca de mensagens<\/h2>\n
\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Para sistemas mais complexos, produza vis\u00f5es de modelo, de alto n\u00edvel, para facilitar discuss\u00f5es com o time.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

A vis\u00e3o do modelo abaixo indica que aplica\u00e7\u00f5es “cliente” n\u00e3o se comunicam diretamente. Em lugar disso, conectam-se a um “servidor” que realiza a media\u00e7\u00e3o das trocas de mensagens.<\/p>\n

\"\"<\/p>\n

As principais atribui\u00e7\u00f5es desse servi\u00e7o s\u00e3o:<\/p>\n

    \n
  1. Aceitar mensagens enviadas por um usu\u00e1rio;<\/li>\n
  2. Armazenar mensagens enviadas em um “registro de conversa” entre dois usu\u00e1rios;<\/li>\n
  3. Garantir que mensagens enviadas sejam “entregues” imediatamente para “destinat\u00e1rios” que estejam conectados no servi\u00e7o;<\/li>\n
  4. Fornecer um “hist\u00f3rico recente” de conversas (mensagens trocadas).<\/li>\n<\/ol>\n
    \n

    O fluxo b\u00e1sico de opera\u00e7\u00f5es pode ser melhor entendido a partir da representa\u00e7\u00e3o abaixo.<\/p>\n

    \"\"<\/p>\n

    Tudo come\u00e7a com uma mensagem sendo enviada a partir de uma aplica\u00e7\u00e3o cliente; “enriquecida” com o um id\u00a0<\/em>no lado servidor; encaminhada para uma fila para processamento; armazenada em um banco de dados; caso o destinat\u00e1rio estiver online<\/em>, enviar para o usu\u00e1rio destinat\u00e1rio; caso o destinat\u00e1rio estiver offline.<\/em><\/p>\n

    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\"\r\n

    Modelo e vis\u00f5es de modelo<\/p>\r\n

    N\u00e3o sabe o que s\u00e3o vis\u00f5es do modelo? Consulte agora esse t\u00f3pico no cap\u00edtulo onde discutimos esse e outros conceitos importantes para a documenta\u00e7\u00e3o.<\/p>\r\nAcessar t\u00f3pico<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

    O “servidor” garante a “mem\u00f3ria” de todas as mensagens. Al\u00e9m disso, possui duas interfaces prim\u00e1rias de comunica\u00e7\u00e3o para as “aplica\u00e7\u00f5es” cliente. Toda vez que um usu\u00e1rio, usando um “cliente”, deseja enviar ou receber mensagens, conecta-se ao “servidor” atrav\u00e9s de suas interfaces.<\/p>\n

    \r\n\r\n\r\n\r\n
    \"\"<\/td>\r\n\"\" Ao produzir uma vis\u00e3o de modelo, certifique-se de ponderar sobre modulariza\u00e7\u00e3o – distribui\u00e7\u00e3o de responsabilidades – e a rela\u00e7\u00e3o de componentes & conectores.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n
    \r\n

    Mem\u00f3ria de mensagens no Whatsapp<\/p>\r\n<\/p>\n

    O Whatsapp \u00e9, provavelmente, o sistema de chat\u00a0<\/em>online\u00a0<\/em>mais popular nos dias de hoje. Ele implementa uma vers\u00e3o consideravelmente modificada do XMPP<\/a> – um padr\u00e3o aberto para troca de mensagens e presen\u00e7a, baseado em XML.<\/p>\n

    Pelo seu design <\/em>o Whatsapp n\u00e3o precisa manter um registro centralizado de todas as mensagens deixando o armazenamento do hist\u00f3rico das conversas em bases de dados locais (SQLite), usando servidores em nuvem, eventualmente, como backup<\/em>.<\/p>\n

    <\/div>\n

    Design de alto n\u00edvel para o controle de presen\u00e7a<\/h2>\n

    O servi\u00e7o de presen\u00e7a, em nosso chat online\u00a0<\/em>\u00e9 respons\u00e1vel por determinar se um usu\u00e1rio est\u00e1\u00a0online\u00a0<\/em>e preparado para se comunicar com outros usu\u00e1rios.<\/p>\n

    \"\"<\/p>\n

    Ele disponibiliza tr\u00eas interfaces principais:<\/p>\n

      \n
    1. atualiza\u00e7\u00e3o externa de status<\/strong>, que dever\u00e1 ser consumida primariamente pelo servi\u00e7o de autentica\u00e7\u00e3o, mudando status<\/em> para\u00a0online\u00a0<\/em>quando acontecer login<\/em> e\u00a0offline<\/em> quando acontecer um logoff;<\/em><\/li>\n
    2. monitoramento de pulsa\u00e7\u00e3o de aplicativos clientes<\/strong>, visando detectar problemas de conex\u00e3o;<\/li>\n
    3. fornecimento de listas de status de usu\u00e1rios<\/strong><\/li>\n<\/ol>\n
      \r\n\r\n\r\n\r\n
      \"\"<\/td>\r\n\"\" Projetar as interfaces (e seus respectivos contratos) de um servi\u00e7o\/aplica\u00e7\u00e3o consiste uma excelente <\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

      Cada uma dessas interfaces apresenta desafios particulares.<\/strong><\/p>\n

      A atualiza\u00e7\u00e3o externa pode ser modelada para evoca\u00e7\u00e3o direta, acionamento via webhooks\u00a0<\/em>ou subscri\u00e7\u00e3o de eventos. A ideia inicial \u00e9 habilitar intera\u00e7\u00e3o entre o servi\u00e7o de login (autentica\u00e7\u00e3o) e o servi\u00e7o de presen\u00e7a.<\/p>\n

      \"\"<\/p>\n

      O monitoramento de pulsa\u00e7\u00e3o pode conectar diretamente com aplica\u00e7\u00f5es clientes ou atrav\u00e9s de “mensagens especiais” para o servi\u00e7o de chat.<\/p>\n

      \"\"<\/p>\n

      A atualiza\u00e7\u00e3o de status de amigos pode acontecer fornecendo listas completas atualizadas ou com atualiza\u00e7\u00f5es parciais (fanout<\/em>)<\/p>\n

      Considera\u00e7\u00f5es para outros servi\u00e7os<\/h2>\n

      Presen\u00e7a e\u00a0chat\u00a0<\/em>s\u00e3o os dois servi\u00e7os cruciais e espec\u00edficos para a constru\u00e7\u00e3o de um\u00a0<\/strong>chat online.<\/strong>\u00a0<\/em>Mas, al\u00e9m deles, h\u00e1 alguns outros.<\/p>\n

      Para come\u00e7ar, \u00e9 necess\u00e1rio ter um servi\u00e7o para gerenciar\u00a0login\/logoff<\/em> e assinatura de novos usu\u00e1rios. Tamb\u00e9m \u00e9 necess\u00e1rio manter um servi\u00e7o para registro de dados dos usu\u00e1rios (como fotos de perfil e dados de apresenta\u00e7\u00e3o).<\/p>\n

      Tais servi\u00e7os operam no padr\u00e3o request\/response\u00a0<\/em>e podem ser “feitos em casa” ou adquiridos no mercado.<\/p>\n

      O servi\u00e7o para\u00a0push notifications\u00a0<\/em>\u00e9 um commodity\u00a0<\/em>necess\u00e1rio. Trata-se da maneira de informar usu\u00e1rios offline <\/em>de que h\u00e1 novas mensagens recebidas, mesmo quando a aplica\u00e7\u00e3o, em um celular, n\u00e3o estiver em execu\u00e7\u00e3o.<\/p>\n

      Organizando informa\u00e7\u00f5es para gerar as primeiras ADRs<\/h2>\n
      \r\n\r\n\r\n\r\n
      \"\"<\/td>\r\n\"\"\r\n

      Architecture Decision Record<\/p>\r\n

      O bom arquiteto garante que decis\u00f5es sejam tomadas, justificadas e comunicadas! Precisa relembrar o que \u00e9 uma ADR? Visite o t\u00f3pico onde introduzimos o conceito.<\/p>\r\nAcessar t\u00f3pico<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

      A partir das informa\u00e7\u00f5es obtidas para formula\u00e7\u00e3o do Haiku<\/em> e do “design<\/em> de alto n\u00edvel”, j\u00e1 \u00e9 poss\u00edvel indicar algumas ADRs com status de “aberta para discuss\u00e3o”. Essas ADRs indicariam a “inclina\u00e7\u00e3o arquitetural” para diversos aspectos importantes, possibilitando debates entre especialistas.<\/p>\n

      Descartando XMPP<\/h4>\n

      XMPP \u00e9 um padr\u00e3o constitu\u00eddo para troca de mensagens e presen\u00e7a. \u00c9 a base tecnol\u00f3gica do Whatsapp, j\u00e1 foi o padr\u00e3o adotado pelo Google Hangouts e o Facebook Messenger. Entretanto, n\u00e3o possui implementa\u00e7\u00f5es ativas nas tecnologias familiares para os times, em nosso cen\u00e1rio fict\u00edcio e, essa \u00e9 uma das raz\u00f5es para estar sendo sendo deixado de lado. A outra \u00e9 o fato do “neg\u00f3cio” desejar uma solu\u00e7\u00e3o propriet\u00e1ria.<\/p>\n

      \r\n\r\n\r\n\r\n
      \"\"<\/td>\r\n\"\" Nunca ignore a “qualifica\u00e7\u00e3o t\u00e9cnica” do time para ado\u00e7\u00e3o de solu\u00e7\u00f5es tecnol\u00f3gicas. Eventualmente, a curva de aprendizagem pode inviabilizar a sustenta\u00e7\u00e3o.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\nEm projetos reais, n\u00e3o seria prudente descartar um protocolo maduro e respeitado como o XMPP. H\u00e1 implementa\u00e7\u00f5es opensource<\/em> para o protocolo que deveriam, pelo menos, serem submetidas a provas de conceito.\n
      \r\n\r\n\r\n\r\n
      \"\"<\/td>\r\n\"\" Realize provas de conceito para conhecer e validar alternativas arquiteturais.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n
      \r\n\r\n\r\n\r\n
      \"\"<\/td>\r\n\"\"\r\n

      Arquitetura assertiva<\/p>\r\n

      A assertividade arquitetural demanda que decis\u00f5es sejam tomadas, justificadas e comunicadas. Quer saber mais sobre isso? Leia agora o t\u00f3pico do livro onde tratamos desse tema.<\/p>\r\nAcessar t\u00f3pico<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

      \r\n

      Facebook Messenger e MQTT<\/p>\r\n<\/p>\n

      Modernamente, o Facebook Messenger adota MQTT como base para comunica\u00e7\u00e3o.<\/p>\n

      Do blog da Meta<\/a>:<\/p>\n

      “The method we were using to send was reliable but slow, and there were limitations on how much we could improve it. With just a few weeks until launch, we ended up building a new mechanism that maintains a persistent connection to our servers. To do this without killing battery life, we used a protocol called MQTT that we had experimented with in Beluga. MQTT is specifically designed for applications like sending telemetry data to and from space probes, so it is designed to use bandwidth and batteries sparingly. By maintaining an MQTT connection and routing messages through our chat pipeline, we were able to often achieve phone-to-phone delivery in the hundreds of milliseconds, rather than multiple seconds.”<\/em><\/p>\n

      <\/div>\n

      \r\n\r\n\r\n\r\n
      \"\"<\/td>\r\n\"\" Adquira o h\u00e1bito de acompanhar os blogs dos times de engenharia das big techs<\/em>. H\u00e1 sempre excelentes insights sobre motiva\u00e7\u00f5es e crit\u00e9rios de decis\u00e3o.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

      A “insufici\u00eancia” do HTTP para o chat service<\/em><\/h4>\n
      \r\n\r\n\r\n\r\n
      \"\"<\/td>\r\n\"\" O design arquitetural de uma aplica\u00e7\u00e3o contempla seus componentes, as responsabilidades de cada componente e a forma como eles se relacionam. <\/strong>Escolhas infelizes de protocolos podem representar s\u00e9rias dificuldades para a constru\u00e7\u00e3o de aplica\u00e7\u00f5es com bom evolvability<\/em>.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

      Na maior parte dos sistemas com arquitetura cliente\/servidor, a comunica\u00e7\u00e3o geralmente \u00e9 iniciada pelo lado “cliente”. Isso tamb\u00e9m \u00e9 v\u00e1lido para o envio de mensagens em um chat online.<\/em> Isso\u00a0 torna HTTP uma op\u00e7\u00e3o vi\u00e1vel de protocolo para sending messages interface<\/em>, principalmente considerando a alternativa de usar a op\u00e7\u00e3o keep-alive<\/em><\/a>\u00a0 para reduzir a quantidade de TCP handshakes<\/em>.<\/p>\n

      Para a relaying messages interface<\/em>, entretanto, HTTP n\u00e3o parece ser uma op\u00e7\u00e3o muito boa, j\u00e1 que, nessa interface seria mais natural se a comunica\u00e7\u00e3o come\u00e7asse pelo lado “servidor”.<\/p>\n

      \r\n

      Polling e Long Polling<\/p>\r\n<\/p>\n

      Ao longo dos anos, algumas t\u00e9cnicas foram desenvolvidas para “disfar\u00e7ar” as limita\u00e7\u00f5es de HTTP para comunica\u00e7\u00f5es iniciadas no “servidor” para os “clientes”.<\/p>\n

      Uma delas, polling<\/em><\/strong>, consiste no “cliente” questionando “o que h\u00e1 de novo?” para o “servidor”, repetidamente, em intervalos regulares (por exemplo, a cada 5 segundos). Dessa forma, sempre que houver uma novidade no servidor, ela \u00e9 comunicada . Obviamente, tal abordagem pode ser custosa, consumindo recursos do servidor (escassos) para, na maior parte das vezes, informar que n\u00e3o h\u00e1 nada a comunicar.<\/p>\n

      Outra t\u00e9cnica, variante da primeira, \u00e9 o long polling<\/strong>.\u00a0<\/em>Sua diferen\u00e7a \u00e9 que o”cliente” e “servidor” mant\u00e9m a conex\u00e3o aberta at\u00e9 houver algo a comunicar ou aconte\u00e7a um timeout <\/em>(default<\/em> 100s).<\/p>\n

      <\/div>\n

      Websockets<\/em> como alternativa vi\u00e1vel<\/h4>\n

      As limita\u00e7\u00f5es de HTTP na comunica\u00e7\u00e3o do “servidor” para o “cliente”, necess\u00e1ria para a\u00a0relaying messages interface<\/em>,\u00a0s\u00e3o superadas rapidamente com a ado\u00e7\u00e3o de websockets.\u00a0<\/em><\/p>\n

      \r\n

      Websockets<\/p>\r\n<\/p>\n

      WebSocket<\/em> \u00e9 uma tecnologia – padronizada pelo W3C e pelo IETF – que permite a comunica\u00e7\u00e3o bidirecional por canais full-duplex sobre um \u00fanico soquete TCP.\u00a0\u00a0<\/sup><\/p>\n

      Uma conex\u00e3o\u00a0websocket\u00a0<\/em>\u00e9 iniciada no lado “cliente” com uma requisi\u00e7\u00e3o HTTP normal, atualizada emum handshake<\/em>. Ela funciona nas portas 80 e 443.<\/p>\n

      <\/div>\n

      Embora HTTP seja “good enough”<\/em> para\u00a0sending message interface,\u00a0<\/em>n\u00e3o h\u00e1 raz\u00f5es para n\u00e3o adotar websockets<\/em> ali tamb\u00e9m.<\/p>\n

      \"\"<\/p>\n

      A manuten\u00e7\u00e3o de conex\u00f5es ativas persistentes entre clientes e o servi\u00e7o de chat\u00a0<\/em>classifica esse servi\u00e7o como\u00a0stateful.<\/em><\/p>\n

      Suportando a escala (em servidores stateful<\/em>)<\/h4>\n

      A decis\u00e3o de usar Websockets\u00a0<\/em>com conex\u00f5es ativas persistentes implica na impossibilidade de adotar estrat\u00e9gias de balanceamento simplificadas entre clientes e servidores.<\/p>\n

      Fazendo c\u00e1lculos no “papel de p\u00e3o”, assumindo 2 milh\u00f5es de usu\u00e1rios ativos simultaneamente (respeitando o caso extremo apontado pelo “neg\u00f3cio”), ponderando-se 10KB para cada “conex\u00e3o ativa” sendo mantida pela aplica\u00e7\u00e3o, temos uma aloca\u00e7\u00e3o total de 20GB. Ou seja, um volume suport\u00e1vel para um \u00fanico servidor<\/span>.<\/p>\n

      Obviamente, a distribui\u00e7\u00e3o na horizontal \u00e9 uma demanda importante para garantir a disponibilidade, que \u00e9 fundamental para a escalabilidade.<\/p>\n

      \r\n\r\n\r\n\r\n
      \"\"<\/td>\r\n\"\"\r\n

      Rela\u00e7\u00e3o entre escalabilidade e disponibilidade<\/p>\r\n

      Confuso sobre a rela\u00e7\u00e3o entre escalabilidade e disponibilidade? Ent\u00e3o, visite o t\u00f3pico onde explico esta rela\u00e7\u00e3o.<\/p>\r\nAcessar t\u00f3pico<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

      Uma primeira alternativa para gerenciar os\u00a0handlers\u00a0<\/em>de conex\u00f5es por cliente \u00e9 utilizar alguma estrat\u00e9gia de service discovery\u00a0<\/em>como a oferecida pelo Apache Zookeeper<\/a>\u00a0– Ele registra todos os servidores ativos e direciona conex\u00f5es conforme crit\u00e9rios pr\u00e9-especificados.<\/p>\n

      Outra alternativa, mais radical, \u00e9 adotar o modelo de programa\u00e7\u00e3o com atores – a base de tecnologias como ERLANG, Akka e Orleans.<\/p>\n

      \r\n

      Actors Model<\/p>\r\n<\/p>\n

      O modelo de atores \u00e9 um modelo de programa\u00e7\u00e3o para computa\u00e7\u00e3o concorrente. Nele, um “ator” \u00e9 a principal primitiva. Atores interagem trocando mensagens.<\/p>\n

      Em resposta a uma mensagem recebida, um ator pode: 1) atuar localmente; 2) criar novos atores; 3) enviar novas mensagens ou 4) responder a mensagem recebida.<\/p>\n

      Um ator tem poder apenas para modificar seu estado local, mas somente pode afetar o estado global indiretamente atrav\u00e9s do envio de mensagens.<\/p>\n

      Frameworks<\/em> que implementam o modelo de atores destacam-se por sua capacidade para escalar e distribuir processamento, com alta toler\u00e2ncia a falhas e baixa lat\u00eancia.<\/p>\n

      <\/div>\n

      Por agora, nossa op\u00e7\u00e3o de design<\/em> \u00e9 utilizando abordagens padr\u00f5es de\u00a0service discovery.<\/em><\/p>\n

      Suportando a escala (em servidores stateless<\/em>)<\/h4>\n

      Escalar servi\u00e7os de autentica\u00e7\u00e3o,\u00a0service discovery\u00a0<\/em>e perfil pode adotar abordagens tradicionais de replica\u00e7\u00e3o. Ou seja, replica\u00e7\u00e3o horizontal com carga distribu\u00edda atrav\u00e9s de um\u00a0load balancer.<\/em><\/p>\n

      Armazenamento das mensagens<\/h4>\n

      O armazenamento das mensagens trocadas pelo servi\u00e7o \u00e9 relativamente simples, contendo poucos campos.<\/p>\n

      \"\"<\/p>\n

      O campo id<\/code> precisa suportar ordena\u00e7\u00e3o temporal inteligente e, por isso, sugere-se a ado\u00e7\u00e3o de um servidor de tickets<\/em> ou uma estrat\u00e9gia como o Twitter Snowflake<\/em>.<\/p>\n

      \r\n

      Twitter Snowflake<\/p>\r\n<\/p>\n

      Twitter Snowflake \u00e9 uma estrat\u00e9gia para gera\u00e7\u00e3o de IDs \u00fanicos, com 64 bits<\/em>, de maneira distribu\u00edda, que possibilita ordena\u00e7\u00e3o temporal.<\/strong><\/p>\n

      Na proposta da estrat\u00e9gia:<\/p>\n

        \n
      • O primeiro bit \u00e9 reservado e sempre “zero”<\/li>\n
      • 41 bits s\u00e3o destinados ao armazenamento de um timestamp regular (suficiente para at\u00e9 69 anos).<\/li>\n
      • 5 bits s\u00e3o utilizados para identificar o datacenter, <\/em>determinado durante o setup<\/em>,\u00a0onde se encontra a m\u00e1quina onde o id est\u00e1 sendo gerado (at\u00e9 32 datacenters<\/em>)<\/li>\n
      • 5 bits s\u00e3o utilizados para identificar a m\u00e1quina do datacenter<\/em>, determinado durante o setup<\/em>,\u00a0onde o ID est\u00e1 sendo gerado (at\u00e9 32 m\u00e1quinas por datacenter<\/em>)<\/li>\n
      • 12 bits s\u00e3o um sequencial reinicializado a cada milissegundo.<\/li>\n<\/ul>\n
        \n

        \u00c9 fundamental que o clock<\/em> das diversas m\u00e1quinas esteja sincronizado.<\/p>\n

        <\/div>\n

        Importante lembrar que o volume de mensagens pode ser realmente gigante. Conforme o neg\u00f3cio, entretanto, nada comparado com os volumes de aplica\u00e7\u00f5es suportados por empresas como\u00a0 Whatsapp e Facebook Messenger.<\/p>\n

        Mensagens geralmente s\u00e3o acessadas, no servidor, conforme “idade”. Mensagens recentes s\u00e3o acessadas todo o tempo. Outro ponto importante, o volume de “leituras” e “grava\u00e7\u00f5es” se aproxima da propor\u00e7\u00e3o 1:1 (uma leitura para cada escrita).<\/p>\n

        Bancos de dados chave-valor parecem ser apropriados. Por refer\u00eancia, Facebook Messenger utiliza HBase e Discord utiliza Cassandra.<\/p>\n

        Armazenamento de “dados gen\u00e9ricos”<\/h4>\n

        Dados gen\u00e9ricos, como dados de perfil, configura\u00e7\u00f5es e lista de amigos s\u00e3o f\u00e1ceis de modelar e suportar com bases de dados relacionais tradicionais.<\/p>\n

        Eventualmente, para suportar escala, pode-se adotar t\u00e9cnicas como replica\u00e7\u00e3o e sharding<\/em>.<\/p>\n

        Consolida\u00e7\u00e3o b\u00e1sica de componentes (servidores)<\/h4>\n

        H\u00e1, dentro da solu\u00e7\u00e3o de chat online\u00a0<\/em>at\u00e9 aqui, as seguintes naturezas de servidores:<\/p>\n

          \n
        1. load balancers<\/em><\/li>\n
        2. mecanismos de fila<\/li>\n
        3. servi\u00e7os stateless<\/em>\n
            \n
          1. autentica\u00e7\u00e3o<\/li>\n
          2. dados b\u00e1sicos de perfil<\/li>\n
          3. servi\u00e7o de descoberta<\/li>\n<\/ol>\n<\/li>\n
          4. servi\u00e7os statefull<\/em>\n
              \n
            1. chat<\/li>\n
            2. presen\u00e7a<\/li>\n<\/ol>\n<\/li>\n
            3. bancos de dados\n
                \n
              1. NoSQL chave-valor<\/li>\n<\/ol>\n<\/li>\n
              2. servidores de push notifications<\/em><\/li>\n<\/ol>\n

                Fluxo b\u00e1sico para conex\u00e3o de um cliente ao servi\u00e7o<\/h4>\n

                A conex\u00e3o de um cliente a plataforma segue um processo gen\u00e9rico de apenas 3 etapas.<\/p>\n

                  \n
                1. Uma vez que um usu\u00e1rio possua acesso ao website\u00a0<\/em>ou ao aplicativo da plataforma, poder\u00e1 iniciar conex\u00e3o, mediante servi\u00e7o de autentica\u00e7\u00e3o.<\/li>\n
                2. Com cliente devidamente autorizado, conex\u00e3o com servi\u00e7o de chat<\/em> deve ser iniciada com orquestra\u00e7\u00e3o do servi\u00e7o de descoberta. Uma vez, determinado o servidor, conex\u00e3o\u00a0websocket\u00a0<\/em>deve ser estabelecida.<\/li>\n
                3. Aplica\u00e7\u00e3o cliente, ent\u00e3o, deve solicitar lista de usu\u00e1rios presentes e atualiza\u00e7\u00e3o de mensagens.<\/li>\n<\/ol>\n
                  \r\n\r\n\r\n\r\n
                  \"\"<\/td>\r\n\"\" Registre em ADRs fluxos elementares, em alto n\u00edvel, para os sistemas que estiver modelando<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

                  Pontos que ainda necessitam reflex\u00e3o<\/span><\/h2>\n

                  O processo de elabora\u00e7\u00e3o da arquitetura deve ser incremental.<\/strong>\u00a0T\u00e3o importante quanto relacionar decis\u00f5es realizadas \u00e9 indicar claramente o que ainda precisa ser ponderado.
                  \nCom rela\u00e7\u00e3o ao design de um chat online<\/em> \u00e9 importante, ainda, considerar:<\/p>\n

                    \n
                  • Rate Limiting<\/em>, visando mitigar o risco potencial de usu\u00e1rios mal-intencionados enviarem um n\u00famero esmagadoramente grande de mensagens.<\/li>\n
                  • A op\u00e7\u00e3o por n\u00e3o utilizar um protocolo consolidado, como XMPP, reduz possibilidades de interoperabilidade.<\/li>\n<\/ul>\n

                    Takeaways<\/span><\/h2>\n

                    A elabora\u00e7\u00e3o desse \u201cin\u00edcio de trabalho arquitetural\u201d para um \u201cchat online\u201d permite algumas li\u00e7\u00f5es importantes:<\/p>\n

                      \n
                    1. Problemas comuns tem solu\u00e7\u00f5es bem estudadas que n\u00e3o devem ser ignoradas;<\/li>\n
                    2. A produ\u00e7\u00e3o de modelos visuais ajuda a tangibilizar a arquitetura<\/li>\n
                    3. Mesmo padr\u00f5es consolidados tem problemas para “suportar” o peso da escala<\/li>\n
                    4. Mesmo em escalas que podem ser atendidas por inst\u00e2ncias \u00fanicas, sempre considere replicas para garantir disponibilidade.<\/li>\n<\/ol>\n
                      \n

                      D\u00favidas ou sugest\u00f5es? Deixe suas contribui\u00e7\u00f5es nos coment\u00e1rios.<\/p>\n","protected":false},"featured_media":4362,"parent":0,"comment_status":"open","ping_status":"closed","template":"","url":[72],"sessoes":[62],"apendices":[],"capitulos":[70],"class_list":["post-4245","volume-1","type-volume-1","status-publish","has-post-thumbnail","hentry","url-permanente","sessoes-secao-4","capitulos-capitulo-4-2"],"acf":[],"yoast_head":"\nCap 4.2 Iniciando o design arquitetural de um "chat online" - Manual do Arquiteto de Software<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Cap 4.2 Iniciando o design arquitetural de um "chat online" - Manual do Arquiteto de Software\" \/>\n<meta property=\"og:description\" content=\"Nesse cap\u00edtulo, vamos utilizar alguns dos conceitos discutidos nesse livro para “pensar a arquitetura” de um sistema de chat online. Nosso objetivo n\u00e3o vai ser fazer uma proposta completa, tampouco definitiva, mas “aquecer os motores”. Obviamente, iremos trabalhar um um cen\u00e1rio fict\u00edcio (afinal, precisamos de algumas delimita\u00e7\u00f5es para nossa solu\u00e7\u00e3o). O que \u00e9 um “chat […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/\" \/>\n<meta property=\"og:site_name\" content=\"Manual do Arquiteto de Software\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/eximiaco\" \/>\n<meta property=\"article:modified_time\" content=\"2024-01-12T21:20:35+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/05\/img-cap-4-2.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"600\" \/>\n\t<meta property=\"og:image:height\" content=\"338\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:site\" content=\"@eximiaco\" \/>\n<meta name=\"twitter:label1\" content=\"Est. tempo de leitura\" \/>\n\t<meta name=\"twitter:data1\" content=\"17 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/\",\"name\":\"Cap 4.2 Iniciando o design arquitetural de um \\\"chat online\\\" - Manual do Arquiteto de Software\",\"isPartOf\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/05\/img-cap-4-2.jpg\",\"datePublished\":\"2022-05-17T00:42:24+00:00\",\"dateModified\":\"2024-01-12T21:20:35+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/#primaryimage\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/05\/img-cap-4-2.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/05\/img-cap-4-2.jpg\",\"width\":600,\"height\":338},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Volume 1\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Cap 4.2 Iniciando o design arquitetural de um “chat online”\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"name\":\"Manual do Arquiteto de Software\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"pt-BR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\",\"name\":\"EximiaCo\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"width\":150,\"height\":150,\"caption\":\"EximiaCo\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/facebook.com\/eximiaco\",\"https:\/\/x.com\/eximiaco\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Cap 4.2 Iniciando o design arquitetural de um \"chat online\" - Manual do Arquiteto de Software","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/","og_locale":"pt_BR","og_type":"article","og_title":"Cap 4.2 Iniciando o design arquitetural de um \"chat online\" - Manual do Arquiteto de Software","og_description":"Nesse cap\u00edtulo, vamos utilizar alguns dos conceitos discutidos nesse livro para “pensar a arquitetura” de um sistema de chat online. Nosso objetivo n\u00e3o vai ser fazer uma proposta completa, tampouco definitiva, mas “aquecer os motores”. Obviamente, iremos trabalhar um um cen\u00e1rio fict\u00edcio (afinal, precisamos de algumas delimita\u00e7\u00f5es para nossa solu\u00e7\u00e3o). O que \u00e9 um “chat […]","og_url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/","og_site_name":"Manual do Arquiteto de Software","article_publisher":"https:\/\/facebook.com\/eximiaco","article_modified_time":"2024-01-12T21:20:35+00:00","og_image":[{"width":600,"height":338,"url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/05\/img-cap-4-2.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_site":"@eximiaco","twitter_misc":{"Est. tempo de leitura":"17 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/","name":"Cap 4.2 Iniciando o design arquitetural de um \"chat online\" - Manual do Arquiteto de Software","isPartOf":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website"},"primaryImageOfPage":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/#primaryimage"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/#primaryimage"},"thumbnailUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/05\/img-cap-4-2.jpg","datePublished":"2022-05-17T00:42:24+00:00","dateModified":"2024-01-12T21:20:35+00:00","breadcrumb":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/#primaryimage","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/05\/img-cap-4-2.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/05\/img-cap-4-2.jpg","width":600,"height":338},{"@type":"BreadcrumbList","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/iniciando-o-design-arquitetural-de-um-chat-online\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/"},{"@type":"ListItem","position":2,"name":"Volume 1","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/"},{"@type":"ListItem","position":3,"name":"Cap 4.2 Iniciando o design arquitetural de um “chat online”"}]},{"@type":"WebSite","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","name":"Manual do Arquiteto de Software","description":"","publisher":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"pt-BR"},{"@type":"Organization","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization","name":"EximiaCo","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","logo":{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","width":150,"height":150,"caption":"EximiaCo"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/facebook.com\/eximiaco","https:\/\/x.com\/eximiaco"]}]}},"_links":{"self":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1\/4245","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1"}],"about":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/types\/volume-1"}],"replies":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/comments?post=4245"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media\/4362"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media?parent=4245"}],"wp:term":[{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/url?post=4245"},{"taxonomy":"sessoes","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/sessoes?post=4245"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/apendices?post=4245"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/capitulos?post=4245"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}