🤨 🙏 👧 Como fizemos no próximo designer de chat bots. Parte 1 🔑 👩‍🚒 ↙️

Oi Habromir! No ano passado, eu e a equipe criamos nossa startup Botlify Chatbot Constructor for Business, e gostaria de compartilhar com o público uma breve história do projeto e as decisões técnicas tomadas. Neste post, tentarei me concentrar o máximo possível em detalhes técnicos e aprofundar menos o produto e os negócios, apesar do fato de que neste projeto meu papel é muito menos conectado ao desenvolvimento e à tecnologia. Este material é baseado na minha experiência pessoal, não sou um coach de startups e não pretendo ser um bom programador, gerente, arquiteto ou empreendedor. Como somos uma startup relativamente jovem, com poucos usuários, não haverá nada sobre as cargas de trabalho e os problemas de grandes projetos. Abaixo, mostrarei como meu projeto começou, que tipo de comissão de desenvolvimento adotamos e que conclusões tiramos.

Meu nome é Andrey, por algum tempo trabalhei como desenvolvedor, principalmente em PHP, depois como líder de equipe e depois como diretor técnico em várias pequenas startups, onde me apaixonei pelo NodeJS. Mas aconteceu que ultimamente sou mais provável que seja um empreendedor. Esta não é a primeira startup que eu fundei, e muito menos a primeira startup em que participei. Por acaso trabalhei em vários projetos de sucesso e em muitas falhas. Eu fundei ainda mais projetos fracassados. Cada vez, as causas do fracasso são completamente diferentes, bem como os estágios em que eu falhei, mas de alguma forma eu usei essa experiência neste projeto.

Metas

Antes de começar a história do projeto, gostaria de falar sobre quais objetivos buscamos desde o início, iniciando esta aventura. De fato, nosso designer começou como um projeto para aprender os conceitos básicos de gerenciamento de produtos, desenvolvimento de clientes, adquirir novas habilidades de gerenciamento e experiência em startups. Ouvi e tentei várias vezes aplicar as abordagens do LEAN Startup e sempre que eram completamente diferentes. É claro que sonhamos em construir um negócio nisso e ganhar um bom dinheiro, mas não nos divertimos com as ilusões de que esse era um caminho simples e curto. E ainda mais, não tentamos fazer algum tipo de WOW! Meu co-fundador e eu trabalhamos em período integral e entendemos que não poderíamos dedicar muito tempo.O principal motivador foi precisamente a oportunidade de dominar áreas completamente novas do setor de TI, aplicar novos conhecimentos na prática e, ao mesmo tempo, ganhar dinheiro.

Como programador, gostei muito de desenhar diagramas de classes, sequências, fluxogramas. Para mim, o próprio processo de visualização foi um estágio na compreensão de problemas e soluções, e me permitiu ter uma visão geral do que estava acontecendo. Enquanto trabalhava no próximo projeto, novamente enfrentei a necessidade de inserir um widget com bate-papo on-line no site e ver quais são as soluções prontas nessa área. Então, entre o que eu estava procurando, me deparei com plataformas que permitiam não apenas criar widgets com bate-papo online para o site, mas também incorporar bots de bate-papo neles. Conversei com um desses robôs e ele me deixou uma boa impressão. E então comecei a tentar criar diferentes scripts de chatbot que pudessem ser úteis em meus projetos. A fantasia acabou de cair sobre a mesa: uma consulta com o salão de beleza,ajude a fazer uma escolha na loja online, indique o lugar certo na documentação, aceite a solicitação ao serviço de suporte. O que eu simplesmente não pensei.

Então, subi para olhar para vários designers e quase todos me ofereceram para preencher formulários, depois preencher e depois preencher novamente. Em geral, crie bots preenchendo formulários. Como resultado, foi extremamente inconveniente para mim, perdi constantemente o contexto do que estava acontecendo, tive que voltar às etapas anteriores para restaurar o contexto e não havia nenhuma questão de pensamento conveniente através da lógica e da criação de cenários. Bem, acho que vou tentar primeiro "projetar" meus bots em uma ferramenta externa e depois transferi-los para a plataforma desejada.

E aqui me deparei com o primeiro problema: como descrever o diálogo com o bot de maneira que fique claro o que e por que o bot responde e, ao mesmo tempo, tem toda a sequência de ações à sua frente?No começo, tentei usar xmind e outras ferramentas para criar um mapa mental. Aconteceu algo assim.

Exemplo de chatbot de mapa mental

Mais tarde, ficou claro que os bots de bate-papo, como um todo, se encaixavam muito bem no conceito de descrever estados e transições entre eles, é bastante conveniente navegar nos ramos de conversação, mesmo onde existem muitos deles.

Apenas alguns concorrentes foram encontrados fornecendo um designer de bot visual. Para alguns, era mais intuitivo, para alguém menos, mas, em geral, esses construtores me pareciam muito mais amigáveis. Tornou-se interessante para nós tentar fazer algo semelhante, queríamos criar uma ferramenta com a qual você pode criar um bot de bate-papo sem habilidades de programação, simplesmente descrevendo-o na forma de um diagrama. Obviamente, algumas habilidades técnicas ainda são necessárias, mas não é muito mais difícil criar um mapa mental.

Bots são um tópico bastante complicado e grande, e nossos recursos são muito limitados. Portanto, era vital para nós simplificar nossa decisão o máximo possível, para que ela pudesse ver o mercado. " Quanto mais cedo melhor " - não vou me cansar de repetir esse mantra no contexto de startups.

AI & ML

A pergunta sobre inteligência artificial nos bots de bate-papo ainda está aberta para mim. Mas agora partimos do fato de sermos uma empresa iniciante, não temos competências em IA e ML na equipe e já concordamos que queremos apenas desenhar diagramas e não preparar conjuntos de dados, treinar redes neurais e isso é tudo. No momento, não usamos inteligência artificial e aprendizado de máquina em nossos bots . Talvez algum dia, no futuro, quando haverá dinheiro para isso.

É importante entender que os mesmos robôs em sua essência podem ser feitos de maneira muito diferente. Grosso modo, pode haver um bot que escreve: " O que você está fazendo? " E espera uma resposta arbitrária do usuário no espírito: " Aprenda sobre borsch ", " Quero encomendar borsch ", "Que horas são?". Tendo recebido a resposta, o bot tenta reconhecê-la, determinar a intenção e escolher o ramo certo para o desenvolvimento do diálogo. Desnecessário dizer que, dados erros de digitação, uma variedade de formas e expressões, isso pode ser caro.

Por outro lado, podemos usar perguntas fechadas quando se trata de trata-se de escolher, por exemplo, um bot pode escrever: " O que você está disposto a fazer? "e opções de oferta:" Aprenda sobre borsch "," Solicite borsch "," Descubra o horário". Por um lado, o usuário perde sua liberdade de ação, mas, por outro lado, não apenas simplificamos significativamente os cálculos, mas também podemos gerenciar mais facilmente o contexto do diálogo, girando-o na direção certa. Preferimos usar perguntas abertas no contexto da coleta de dados de texto do usuário: insira email , telefone, escreva sua pergunta para dar suporte etc.

Bate-papo bot vs man

Outro argumento contra permitir que o usuário se comunique com o bot de forma livre foi a crença de que o bot de bate-papo não deve "jogar" em uma pessoa. Na minha opinião, ao se comunicar com um bot, uma pessoa deve entender claramente o que se comunica com o bot, saber quais oportunidades ele tem e como usá-los. E se uma pessoa entende que está se comunicando com um bot - qual é o sentido da comunicação de texto livre? É muito melhor quando o chatbot se torna assistente de uma pessoa, e não um substituto e não é tímido, e a pessoa entende claramente que se comunica com o chatbot e quais são suas funções. Nesse caso, a comunicação acaba sendo notavelmente mais eficaz.

Processo

Eu sou fã de udalenki. Não me alimente pão - deixe-me montar uma equipe remota e começar a trabalhar com ela. Eu me sinto confortável trabalhando remotamente, sei organizar o trabalho e encontrar pessoas que também possam trabalhar de forma independente e eficiente. Entendo perfeitamente que isso não é adequado para todos, concordo plenamente com isso, mas acho que no futuro brilhante haverá cada vez mais udalenki. É que a economia não é nada pessoal. Como este é o meu projeto e eu pedi música para ele - aqui também é remoto, isso deixa uma certa marca.

No início do trabalho em qualquer projeto, considero muito importante tentar formalizar minhas idéias o máximo possível. Embora a idéia não tenha encontrado sua forma no papel, na forma de texto, notas, desenhos, nenhuma idéia existe. Ao mesmo tempo, todos os processos dentro da equipe devem ser o mais simples, natural e rápido possível, eficaz na comunicação. Você não deve usar ferramentas grandes e pesadas para gerenciar sua equipe, como Jira ou Redmine, se toda a equipe for você e seu amigo. Mas também para não usar nada também, caso contrário, tudo rapidamente sairá do controle e o caos surgirá, restringindo o que é muito mais difícil do que simplesmente não permitir. Mesmo na cabeça de uma pessoa, essa confusão pode ser formada de acordo com o projeto, não é para eu lhe dizer o que dizer sobre a equipe, mesmo que apenas 2-3 pessoas.

Nós, como iniciantes reais, usamos o Trello para organizar tarefas e armazenar links importantes para o projeto, e idéias também foram lançadas lá. Para documentação comercial, o Google Docs , enquanto o técnico, é muito bem criado em descontos e colocado no repositório correspondente. Comunicação ao longo do dia - Telegrama e para stand-ups diários do Google Hangouts . Os levantamentos diários são uma das pedras angulares da existência de equipes remotas . Se isso não existe, não há equipe, alguém necessariamente começa a se sentir sozinho, cansado, mal-entendido e descontentamento estão se acumulando, não apenas o controle da situação, mas também as relações na equipe.

Do ponto de vista do processo de desenvolvimento, a América também não precisou ser descoberta. Determinamos a duração do sprint, planejamos o sprint com base nos objetivos da inicialização. Pegamos quebra-cabeças e começamos a salsicha. Um novo desafio é uma nova ramificação no seu sistema de controle de versão favorito. Você terminou? Emitimos uma solicitação Pull, aguarde até que alguém se refira à revisão. A revisão foi? CI funcionou bem? Bem, então, você pode manter tudo no ramo de desenvolvimento, aguardar a luz verde do conjunto de desenvolvimento e atualizar o servidor de teste. O código que armazenamos no GitHub . Até o primeiro cliente pagador, estes eram repositórios abertos ao público. Como uma pessoa que tentou promover várias soluções de código aberto no passado, fico sinceramente ressentida toda vez que uma startup começa a tremer pela segurança de seu código antes de começar a ganhar dinheiro.Se você tentar copiar - este é um sucesso comercial claro . Não custa nada fechar o repositório posteriormente. E os negócios, você sabe, estão enterrados, via de regra, longe do código. Eu tenho acesso ao código de muitos, incluindo produtos muito bem-sucedidos, mas vale a pena dizer que tê-los não repetirei nem de perto seu sucesso? Para criar contêineres do Docker e executar autotestes, decidimos experimentar o GitHub Actions , felizmente, eles deram acesso preliminar. Em geral, as impressões permaneceram bastante agradáveis, a velocidade de montagem é satisfatória. A única coisa desagradável foram as atualizações com perda de compatibilidade com as versões anteriores. Algumas vezes eles mudaram seriamente o esquema de descrição das ações e tiveram que reconfigurar tudo. Mas sabíamos o que estávamos fazendo quando concordamos em experimentar o produto com statusBeta .

Desde os primeiros dias, literalmente, desde o desenvolvimento de uma página de destino para testes de demanda, tentamos lançar lançamentos pelo menos uma vez por semana e testar pelo menos uma hipótese. No início, as hipóteses eram mais globais, tentamos encontrar vários problemas, atingir o público-alvo e desenvolver uma proposta. Porém, quanto mais o produto se desenvolvia, menos globais eles se tornavam e a essência em si era menos provável de mudar. O projeto começou do zero, com a página de destino habitual, depois criamos um cliente de demonstração do bot de bate-papo, que ainda está na nossa página principal. Esta demonstração pode reproduzir um diálogo estritamente programado e nos serviu como uma demonstração do que poderia ser feito em nosso construtor - o resultado de seu trabalho, e não o próprio construtor. O truque foi que assumimos que o negócio não iria até nós para o designer de bot,mas por algum resultado, a vantagem que ele dará. Queríamos servir aos nossos clientes uma xícara de café feita por nossa máquina de café, em vez de mostrar a própria máquina de café. É fácil adivinhar quefazer uma xícara de café é muito mais rápido e mais barato do que coletar uma máquina de café . Guiados por esse princípio, decidimos fazer uma demonstração do cliente primeiro, principalmente porque, com várias ferramentas prontas, não demoramos mais do que duas noites, incluindo o desenvolvimento de cenários de diálogo.

Quando vimos o interesse dos visitantes do pouso e as conversões adicionais geradas por nossa demonstração, decidimos que iríamos além. Lembro que nosso primeiro lançamento do construtor foi um formulário de registro com um formulário de login, após o qual o usuário foi levado a uma página com um pedido de desculpas e com a promessa de informar quando outra coisa funcionava. Fiz os formulários de login e registro centenas de vezes na minha vida e não conseguia nem pensar que aqui encontraríamos imediatamente muitos problemas.Cerca de 60% dos primeiros usuários simplesmente não conseguiram concluir o processo de registro . Para quem o botão não funciona, para quem o email não vem, para quem outra coisa é. No começo, percebi a idéia de liberar apenas algumas formas bastante céticas, mas uma primeira olhada no Yandex.Metrica deixou claro que era a decisão certa. A percepção de que os usuários se comportam de maneira diferente do que você gostaria e, às vezes, da maneira que você pensou que não podia, teve um grande impacto em tudo o que fizemos a seguir. Como hobby, passei várias vezes por semana em algumas horas em um navegador da web apenas observando como os usuários usam nosso ofício.

Então, pouco a pouco, adicionamos funcionalidade à nossa ideia e chegamos a um produto que ainda tem valor não apenas para nós, mas também para nossos usuários, alguns dos quais até nos pagam dinheiro. A longo prazo, não entendemos o que queremos chegar, como será nosso produto. A única coisa que entendemos na época era que não entendemos nada e estamos em um estado de incerteza.

Resultado

Esse experimento levou a mim e à minha equipe a um investimento angelical da categoria de amigos, família e tolos, criada pelo MVP, primeiras vendas, ótima experiência, muitas alegrias e decepções. Ainda não somos um negócio verdadeiro, mas nos esforçamos para nos tornar um. E quando digo isso, quero dizer que ainda estamos em busca de um modelo de negócios sustentável e de ajuste do mercado do produto. Mais uma vez, planejamos procurar o conceito de produto certo, nosso cliente, nosso mercado.

Os objetivos iniciais foram alcançados de maneira alguma, mas o projeto cresceu de um hobby em casa e se transformou em um emprego de período integral, e a responsabilidade apareceu para investidores, usuários e funcionários. Obviamente, o projeto tem muitos problemas, tanto conceituais quanto técnicos, mas não há nada insolúvel e planejamos continuar trabalhando.

Antes de embarcar na parte mais técnica da minha obra, provavelmente vale a pena falar brevemente sobre o que o produto permite que você faça.

Gerenciar chatbots na sua conta
Editor visual de chatbot
Controlar o acesso aos bots de bate-papo (acesso de edição, acesso público)
Capacidade de publicar bots de bate-papo na web (widget, incorporado, tela cheia)
Configurações do Chatbot (design, nomes, métricas, posição do widget, etc.)
Suporte para integração de chatbots com serviços externos através de solicitações GET e POST
Análise de caixas de diálogo de bot
Gerenciamento de conta
Modelo de Assinatura, Gerenciamento de Assinaturas

Arquitetura

Agora, conhecendo os antecedentes, objetivos, idéias e princípios que nos guiaram no desenvolvimento, posso começar a dar uma descrição geral de como tudo isso funciona. Como nossa escolha inicial foi criar chatbots para sites e chat em tela cheia , como app.botlify.io/bot/5de53dbf9b9bae002b319600 , ficou claro que a maior parte do trabalho seria do lado da interface. Como resultado, a frente do trabalho no cliente foi formada em uma lista significativa de tarefas e lista de desejos:

Crie / encontre uma biblioteca cliente, uma espécie de "mecanismo" para bots de bate-papo em um navegador que compreenda as instruções json recebidas e mantenha um diálogo com o usuário.
Crie um aplicativo para editar nós de bot, que salvará uma lista de nós e links entre eles em algum objeto json (com base no qual a biblioteca cliente conduzirá diálogos).
, , , - . , , , . , , , ..

, , . id , :

<script defer src="https://app.botlify.io/botlify.min.js"
    onload="Botlify({ bot: '5de53dbf9b9bae002b319600', type: 'widget'})"
</script>

, , ( )

Toda a lógica dos diálogos, desde a criação de bots de bate-papo (nós e conexões) até o trabalho direto com eles no Web client, é tratada pelo frontend. O papel do back-end é mais sobre o gerenciamento de acesso, assinaturas, boletins, notificações e armazenamento de dados transmitidos de muitos clientes da Web.

A parte dianteira

Para a frente, usamos Reactjs . Empacotamos tudo no Docker (o construímos e o empurramos para o contêiner nginx), o código no Github em repositórios particulares, para o CI usamos as Ações do Github . Lançamos contêineres em servidores VPS comuns com scripts bash simples. Para simplificar o desenvolvimento da interface do usuário, utilizamos o Blueprint .

Web — javascript , - . json -, . -(, , , , , .).
Web — javascript . id , , Web- .
— , . json, -. , «» , — -.
Conta de usuário - um aplicativo da web para gerenciar sua conta, assinatura e bots.
O painel administrativo é um aplicativo da web para administradores. Gerenciamento de usuários, bots, assinaturas, painéis com análises.

O diagrama abaixo mostra os componentes do front-end e como eles interagem entre si. O cliente da Web e o editor de bot são usados apenas no contexto de outros aplicativos, enquanto se o editor é usado apenas em nossos aplicativos, o cliente da Web também pode ser usado pelos nossos clientes como um módulo da Web. Ao criar o projeto, pacotes com Webclient e Editor são adicionados aos aplicativos Dashboard e Admin. Além disso, o módulo da web é construído usando o webpack para entrega aos usuários.

MVP 1. Cliente da Web

Como uma startup, sempre nos esforçamos para alcançar o máximo de resultados usando um mínimo de recursos. Parece-me que um passo bastante lógico para o primeiro MVP foi a criação de um cliente da Web do ponto de vista que representava a “face do produto”, mostrava o resultado do trabalho do designer, e não o processo de criação do bot - uma xícara de café, não uma máquina de café. Para minimizar o tempo de desenvolvimento da solução, decidimos procurar bibliotecas adequadas aos nossos pedidos e, de repente, encontramos! lucasbassetti.com.br/react-simple-chatbot é um componente de reação que cobriu quase todas as nossas necessidades!

Esse componente sugeriu descrever a lógica do chatbot na forma de uma matriz de etapas, ler os valores inseridos pelos usuários, personalizar a aparência, validar os dados e parecer suficientemente flexível para começar. A descrição das etapas mais simples se parece com isso:

<ChatBot
      steps={[
        {
          id: '1',
          message: 'What is your name?',
          trigger: '2',
        },
        {
          id: '2',
          user: true,
          trigger: '3',
        },
        {
          id: '3',
          message: 'Hi {previousValue}, nice to meet you!',
          end: true,
        },
      ]}
    />

Começamos tentando compor um chatbot apresentando nosso projeto, cujo mapa mental estava na tela no início do artigo. Naturalmente, descrever manualmente esse json acabou sendo bastante inconveniente, e eu tive que escrever muitas funções personalizadas, mas, em geral, esse processo deu uma compreensão de como o componente funciona, como alcançar o resultado desejado.

Além disso, meu colega personalizou a aparência, fez várias opções de exibição e inventamos um exemplo com uma barbearia e uma exposição de Van Gogh. Você pode até perceber que nem pensamos em otimização de imagens. Sim, foi e não foi necessário. No processo de trabalho, formamos uma visão aproximada de como o cliente funcionará e começamos a procurar soluções para o próprio designer, a fim de aproveitar os benefícios da edição visual o mais rápido possível.

MVP 2. Construtor

Com base no que vimos ao trabalhar com o cliente, concluímos geral que o bot pode ter vários tipos de ações: enviar algo, aguardar ações do usuário, enviar uma solicitação para um serviço externo. Para um editor de bot minimamente viável, decidimos nos limitar a blocos:

Iniciar - uma unidade técnica que inicia uma nova sessão
Fim - bloco que termina a sessão
Mensagem - ao alcançar o bloco, o bot envia a mensagem especificada no corpo do bloco
— . ,

Supunha-se que os blocos seriam interconectados por setas ou linhas. Todos os blocos, exceto o bloco “Start”, têm uma porta de entrada (soquete). Muitas linhas podem se conectar à porta de entrada, conectando a unidade a outras. Todos os blocos, exceto o bloco End, têm de uma a várias portas de saída. As portas de saída determinam para qual controle de bloco é transferido após a conclusão da lógica do bloco atual.

Após uma breve inspeção das soluções disponíveis, decidimos pelo Rete.js (https://rete.js.org). Eu me familiarizei com a documentação, exemplos e encontrei neles tudo o que precisávamos para começar. Eles até tiveram um exemplo apenas com um bot de bate-papo, que foi o último gatilho

Rete . . , — , JSON

Todos os nós podem conter um nome, entradas, saídas e controles. As entradas e saídas devem estar localizadas à esquerda e à direita do nó, respectivamente (para nós customizados, pode haver exceções). Eles são representados por um soquete e podem ter nomes. Para as entradas, permitimos um número ilimitado de conexões (existem muitas maneiras de chegar ao nó); para a saída, nos limitamos a apenas uma conexão; no entanto, ao contrário dos soquetes de entrada, alguns blocos têm muitos soquetes de saída.

O Rete.js é construído de tal maneira que sua funcionalidade é expandida através da criação de nós, controles e componentes personalizados, o que nos permitiu obter rapidamente exatamente a imagem que queríamos ver, pela qual agradeço aos criadores do Rete ! Obviamente, um dos mais importantes é um editor pronto!

Conforme escrito emdocumentação :

Um editor é uma área com nós e conexões entre seus soquetes. As seguintes opções estão disponíveis:

Interação com o espaço de trabalho (movimentação, dimensionamento) e gerenciamento de nós (movimentação, adição, exclusão)
Exibição de conexões, nós, suas entradas / saídas e controles
Manipulação de eventos do editor
Esquema de importação / exportação no formato JSON
Estendendo a funcionalidade com plugins
Personalização da área de trabalho, nós e conexões

Tendo conjurado um pouco com Rete e estudado em exemplos mais detalhados, conseguimos criar algo que nos permitia criar e excluir blocos “iniciar”, “final”, “mensagem” e “entrada de teclado”. Na saída, recebemos json com uma descrição dos nós, soquetes e linhas que os conectam.

Uma das primeiras versões do editor

Já é alguma coisa, mas isso não é suficiente, porque nosso cliente da web não entende esse json. Ele precisa de algum tipo de descrição, com a descrição das etapas. Decidiu-se incorporar um conversor de um formato json para outro no cliente.

Transformador Json

O utilitário recebe o NodesMap, compilado pelo editor, como entrada e retorna um StepsMap que o cliente entende. O código de todo o transformador leva um pouco mais de 100 linhas, dependendo do tipo de nó e dos dados, nele são criados um passo adequado, funções de acionamento e um conjunto de instruções (ações) a serem executadas neste passo. Existem instruções que salvam a variável no estado chatbot, há aquelas que substituem a variável no texto ou enviam uma solicitação ao nosso servidor.

Depois de amarrar os componentes, começamos a testar as ferramentas resultantes. Mesmo sem o back-end, foi muito emocionante. Criamos diálogos no editor e inserimos o json no cliente por meio de ferramentas de desenvolvimento, e, como resultado, recebemos um bot que diz como precisamos dele! Ele também sabe como salvar variáveis e usá-las, droga! Grandes sensações das primeiras vitórias ... O mosaico do dispositivo de nossa aplicação já se formou praticamente na minha cabeça, conseguimos algo trabalhando nos princípios que queremos usar no futuro. Temos um certo esqueleto em torno do qual restava construir "carne". E o mais importante - ficou claro como fazer isso:

Mude o editor, adicione o tipo de nó desejado
Ensinamos json transformador a transformar um novo nó em uma nova etapa
Ensinamos o cliente a trabalhar com uma nova etapa

Por outro lado, foi necessário começar a se envolver na conta pessoal do usuário para que fosse possível criar bots, salvá-los, gerenciar e decidimos nos concentrar nisso para mostrar rapidamente aos usuários não um conceito, mas um produto.

Conta de usuário

As bibliotecas acima executaram determinadas funções relacionadas à criação da lógica do chatbot (editor), sua interpretação ou sua reprodução (cliente). Os problemas de armazenamento de dados, a capacidade de carregar bots criados, gerenciando-os e definindo propriedades não relacionadas à lógica permaneceram em aberto e o aplicativo deveria ter resolvido-os para os usuários. Armado com blueprintJS, esboçamos um protótipo de uma conta pessoal na qual era possível registrar e criar vários bots. Quando você clica no bot para criar uma pessoa, ele cai no editor com um novo bot e quando você clica no cartão de bot no editor com esse bot. Decidimos confiar as funções de carregar e salvar o bot por meio da API do nosso back-end nessa camada para deixar o editor de bot independente do back-end.

O aplicativo da conta do usuário pode fazer o download do pacote do editor e transferir dados prontos para exibição. Este aplicativo também gerencia formulários para definir propriedades do bot (nome, teclas da API, avatar, configurações de publicação) e permite visualizar estatísticas. Para permitir que os usuários vejam imediatamente o resultado do editor, adicionamos um cliente da Web ao escritório do usuário, ao qual atribuímos o esquema do json bot, ele o interpreta em etapas e o reproduz na guia "preview". Em geral, este é um painel de administração muito clássico, com alguns componentes interessantes (editor de bot e cliente da web), acho que muitos o fizeram. Mas foi nessa fase que se tornou visivelmente inconveniente desenvolver nosso aplicativo.

Inicialmente, pareceu-nos uma boa idéia conter os componentes do produto em diferentes repositórios e não vimos nenhum problema específico nisso. No entanto, rapidamente ficou claro que manter muitos repositórios atualizados é problemático, sem mencionar a necessidade de dançar com um pandeiro durante o desenvolvimento, porque eles são, até certo ponto, interdependentes. E, considerando que tínhamos apenas um desenvolvedor em período integral, essa abordagem foi um grande furacão. E qualquer implantação se transformou em um ramo do inferno na Terra por causa da diferença na montagem e publicação de bibliotecas, aplicativos, problemas de compatibilidade com versões anteriores. Daí a conclusão banal, mas não a mais inútil: a alocação prematura de módulos pode fazer mais mal do que ajudarJá me convenci disso muitas vezes no back-end, e aqui vim novamente, mas na frente. Sim, e não perdi uma chance no back-end: =)

Um dos meus colegas reuniu sua vontade em um punho e combinou tudo em um repositório mono gerenciado com lerna . Agora, nosso único repositório front-end está dividido em pacotes: admin, cliente, comum, painel, editor, módulo da web. Eles podem ter um assembly diferente dentro, mas o lerna permite que eles vinculem e atualizem dependências entre pacotes. Depois disso, o desenvolvimento e a implantação do front-end se tornaram muito mais rápidos e fáceis, tudo está imediatamente à mão, mas ainda está dividido.

Depois de criar o gabinete, passamos algum tempo em novos blocos no editor e seu processamento pelo cliente:

— . ( ),
— -
Email — email

Não tenho muito o que dizer sobre o painel de administração e o módulo da web, tudo é muito padrão lá. Quero apenas observar que o painel de administração também não deve ser feito com antecedência . Temos, mas ninguém o usa, porque, pessoalmente, não é difícil ver tudo o que me interessa imediatamente no banco de dados. Não há humanidades que precisem do nosso painel de administração na equipe, e mantê-lo atualizado é essencialmente um pouco menos caro do que manter a conta de um usuário. Com o tempo, um painel simples foi adicionado lá, exibindo pagamentos, novos registros e visitas do aplicativo, mas essas informações dificilmente valem o desenvolvimento de um administrador inteiro. painéis com tabelas, formulários e autenticação separada

Resultados?

Conseguimos criar protótipos e páginas de destino muito rapidamente. Sim, não era o que muitos imaginam sob o disfarce de MVP. Mas apenas algumas noites após a idéia surgir, poderíamos começar a mostrá-la às pessoas e testá-la. Diferentes páginas de destino, anúncios, textos no bot - poderíamos testar e pesquisar. Eu recomendo que qualquer pessoa envolvida no desenvolvimento de inicialização pense em como fazer as coisas o mais rápido possível. Fizemos o primeiro produto para extrair valor em cerca de três meses e, em seguida, um processo mais gradual de melhoria regular começou. Obviamente, agora temos mais blocos dentro do construtor, adicionamos validação, tipos de dados, solicitações GET e POST, muitas configurações de design e exibição, mas você pode começar sem tudo isso, o que fizemos.

Com o tempo, o sistema começou a se tornar mais complexo e evoluir, e eu não consegui descrever nem de perto tudo o que realmente está acontecendo. Comece pequeno, as coisas ficam complicadas com o tempo, quando necessário. Qualquer componente extra pode resultar em um custo muito alto, porque não é apenas necessário criar e integrar, mas também oferecer suporte, testar, documentar, implantar, monitorar, apresentar outros membros da equipe a ele. Provavelmente você não deve se preocupar com filas no RabbitMQ, se antes não havia filas no seu aplicativo. Provavelmente, soluções baseadas em tecnologias que já existem serão suficientes para começar. Qualquer novo componente é um custo adicional para integração, operação, teste, suporte, documentação, implantação, etc., etc.

Espero que minha experiência seja útil para pelo menos alguém. Durante muito tempo, tentei descobrir qual hub determinaria isso, mas não entendi. Deixe-me saber se vale a pena escrever a segunda parte em que eu queria falar um pouco sobre o back-end, serviços externos e planos de desenvolvimento

Como fizemos no próximo designer de chat bots. Parte 1