Get best of the week

Como hicimos el próximo diseñador de chat bots. Parte 1



Hola habromir El año pasado, el equipo y yo pasamos creando nuestra startup "Constructor de chatbots para el negocio de Botlify", y me gustaría compartir con el público una breve historia del proyecto y las decisiones técnicas tomadas. En esta publicación, intentaré concentrarme lo más posible en los detalles técnicos y profundizar menos en el producto y el negocio, a pesar de que en este proyecto mi rol está mucho menos conectado con el desarrollo y la tecnología. Este material se basa en mi experiencia personal, no soy un entrenador de inicio y no pretendo ser un buen programador, gerente, arquitecto o emprendedor. Somos una startup relativamente joven con pocos usuarios, por lo que no habrá nada sobre las cargas de trabajo y los problemas de los grandes proyectos. Debajo del corte, le diré cómo comenzó mi proyecto, qué tipo de desarrollo de avance pisamos y qué conclusiones sacamos.

Mi nombre es Andrey, durante algún tiempo trabajé como desarrollador, principalmente en PHP, luego como líder de equipo, y luego como director técnico en varias pequeñas startups, donde me enamoré de NodeJS. Pero sucedió que últimamente soy más emprendedor. Esta no es la primera startup que fundé, y menos aún la primera startup en la que participé. Trabajé en varios proyectos exitosos y muchos fracasos. Yo mismo fundé más proyectos fallidos. Cada vez, las causas del fracaso son completamente diferentes, así como las etapas en las que fallé, pero de alguna manera usé esta experiencia en este proyecto.

Metas


Antes de comenzar la historia sobre el proyecto, me gustaría hablar sobre los objetivos que perseguimos desde el principio, comenzando esta aventura. De hecho, nuestro diseñador comenzó como un proyecto favorito para aprender los conceptos básicos de gestión de productos, desarrollo de clientes, adquirir nuevas habilidades de gestión y experiencia en nuevas empresas. Escuché e intenté muchas veces aplicar los enfoques LEAN Startup y cada vez resultó completamente diferente. Por supuesto, soñamos con construir un negocio con esto y ganar mucho dinero, pero no nos entretuvimos con la ilusión de que esto era un camino simple y corto. Y aún más, no tratamos de hacer algún tipo de WOW! -Innovation. Mi cofundador y yo tuvimos un trabajo constante a tiempo completo y entendimos que no podremos dedicar mucho tiempo.El principal motivador fue precisamente la oportunidad de dominar áreas completamente nuevas de la industria de TI y aplicar nuevos conocimientos en la práctica, y al mismo tiempo ganar dinero.


Como programador, realmente me gustaba dibujar diagramas de clases, secuencias, diagramas de flujo. Para mí, el proceso de visualización en sí mismo fue una etapa en la comprensión de los problemas y las soluciones, y me permitió tener una idea general de lo que estaba sucediendo. Mientras trabajaba en el próximo proyecto, nuevamente me enfrenté a la necesidad de insertar un widget con chat en línea en el sitio y ver qué soluciones preparadas hay en esta área. Entonces, entre lo que estaba buscando, encontré plataformas que permitían no solo crear widgets con chat en línea para el sitio, sino también incrustar bots de chat en ellos. Hablé con uno de estos bots y me dejó una buena impresión. Y luego comencé a tratar de crear diferentes scripts de chatbot que pudieran ser útiles en mis proyectos. La fantasía se derramó sobre la mesa: una cita con el salón de manicura,ayudar a elegir en la tienda en línea, indicar el lugar correcto en la documentación, aceptar la solicitud al servicio de soporte. Lo que simplemente no pensé.

Luego subí para mirar a varios diseñadores y casi todos me ofrecieron completar formularios, luego completar formularios y luego completar formularios nuevamente. En general, crea bots completando formularios. Como resultado, fue extremadamente inconveniente para mí, perdí constantemente el contexto de lo que estaba sucediendo, tuve que volver a los pasos anteriores para restaurar el contexto, y no había duda de pensar convenientemente a través de la lógica y el diseño de escenarios. Bueno, creo que primero intentaré "diseñar" mis bots en una herramienta externa, y luego lo transferiré a la plataforma deseada.

Y aquí me encontré con el primer problema: ¿cómo describir el diálogo con el bot de tal manera que quede claro qué y por qué responde el bot y al mismo tiempo tiene toda la secuencia de acciones frente a sí mismo?Al principio, intenté usar xmind y otras herramientas para crear un mapa mental. Resultó algo como esto.

Ejemplo de chatbot de mapa mental

Más tarde, quedó claro que los bots de chat en su conjunto encajan bastante bien en el concepto de describir estados y transiciones entre ellos, resulta bastante conveniente navegar en las ramas de conversación, incluso donde hay muchos de ellos.

Solo unos pocos competidores fueron encontrados proporcionando un diseñador visual de bot. Para algunos, era más intuitivo, para alguien menos, pero en general, tales constructores me parecían mucho más fáciles de usar. Nos resultó interesante tratar de hacer algo similar, queríamos crear una herramienta con la que puedas crear un bot de chat sin habilidades de programación, simplemente describiéndolo en forma de diagrama. Por supuesto, todavía se requieren algunas habilidades técnicas, pero no es mucho más difícil crear un mapa mental.

Los bots son un tema bastante complicado y grande, y nuestros recursos son muy limitados. Por lo tanto, era vital para nosotros simplificar nuestra decisión tanto como sea posible para poder ver el mercado. “ Cuanto antes, mejor ”: no me cansaré de repetir este mantra en el contexto de las startups.

AI y ML


La pregunta sobre la inteligencia artificial en los bots de chat todavía está abierta para mí. Pero ahora procedemos del hecho de que somos un inicio temprano, no tenemos competencias en IA y ML dentro del equipo y ya hemos acordado que solo queremos dibujar diagramas y no preparar conjuntos de datos, entrenar redes neuronales y eso es todo. Por el momento, no usamos inteligencia artificial y aprendizaje automático en nuestros bots . Quizás algún día, en el futuro, cuando habrá dinero para ello.

Es importante entender que los mismos bots en su esencia se pueden hacer de manera muy diferente. En términos generales, puede haber un bot que escriba: " ¿Qué estás haciendo? " Y espera una respuesta arbitraria del usuario en el espíritu: " Aprenda sobre borsch ", " Quiero ordenar borsch ", "¿Qué hora es en este momento?". Una vez recibida la respuesta, el bot intenta reconocerla, determinar la intención y elegir la rama correcta para el desarrollo del diálogo. No hace falta decir, dados los errores tipográficos, una variedad de formas y expresiones, esto puede ser costoso.

Por otro lado, podemos usar preguntas cerradas cuando se trata de se trata de elegir, por ejemplo, un bot puede escribir: " ¿Qué estás dispuesto a hacer? "y opciones de oferta:" Obtenga información sobre borsch "," Solicite borsch "," Conozca la hora". Por un lado, el usuario pierde su libertad de acción, pero por otro lado, no solo simplificamos en gran medida los cálculos, sino que también podemos gestionar más fácilmente el contexto del diálogo girándolo en la dirección correcta. Preferimos usar preguntas abiertas en el contexto de la recopilación de datos de texto del usuario: ingrese el correo electrónico , teléfono, escriba su pregunta para soporte, etc.

Chat bot vs hombre


Otro argumento en contra de permitir que el usuario se comunique con el bot de forma gratuita fue la creencia de que el bot de chat no debe "jugar" en una persona. En mi opinión, cuando se comunica con un bot, una persona debe entender claramente qué se comunica con el bot, saber qué oportunidades tiene y cómo usarlas. Y si una persona entiende que se está comunicando con un bot, ¿cuál es el punto en la comunicación de texto libre? Es mucho mejor cuando el chatbot se convierte en asistente de una persona, y no lo sustituye y no es tímido al respecto, y la persona entiende claramente que se comunica con el chatbot y cuáles son sus funciones. En este caso, la comunicación resulta ser notablemente más efectiva.

Proceso


Soy fan de udalenki. No me des pan, déjame armar un equipo remoto y comenzar a trabajar con él. Me siento cómodo trabajando remotamente, sé cómo organizar el trabajo y encontrar personas que también puedan trabajar de manera independiente y eficiente. Entiendo perfectamente que esto no es adecuado para todos, estoy completamente de acuerdo con esto, pero creo que en el futuro brillante habrá más y más udalenki. Es solo que la economía no es nada personal. Como este es mi proyecto y pedí música para él, aquí también es remoto, esto deja una cierta huella.

Al comienzo del trabajo en cualquier proyecto, considero muy importante tratar de formalizar mis ideas tanto como sea posible. Si bien la idea no ha encontrado su forma en papel, en forma de texto, notas, dibujos, no existe ninguna idea en absoluto. Al mismo tiempo, todos los procesos dentro del equipo deben ser tan simples, naturales y rápidos como sea posible, y una comunicación efectiva. No debe utilizar herramientas grandes y pesadas para administrar su equipo, como Jira o Redmine, si todo su equipo es usted y su amigo. Pero también para no usar nada, de lo contrario, todo se saldrá rápidamente de control y surgirá el caos, lo que es mucho más difícil que simplemente no permitirlo. Incluso en la cabeza de una persona, tal desorden se puede formar de acuerdo con el proyecto, no me corresponde decirte qué decir sobre el equipo, incluso si solo son 2-3 personas.

Nosotros, como verdaderos principiantes, usamos Trello para organizar tareas y almacenar enlaces importantes para el proyecto, y las ideas también fueron arrojadas allí. Para la documentación comercial, Google Docs , aunque es técnico, está bastante bien creado en rebajas y se coloca en el repositorio correspondiente. Comunicación durante todo el día: Telegram y para stand-ups diarios de Google Hangouts . Las paradas diarias son una de las piedras angulares de la existencia de equipos remotos . Si esto no está allí, no hay equipo, alguien necesariamente comienza a sentirse solo, cansado, se están acumulando malentendidos y descontento, no solo se pierde el control de la situación sino que también se pierden las relaciones en el equipo.

Desde el punto de vista del proceso de desarrollo, Estados Unidos tampoco tuvo que ser descubierto. Determinamos la duración del sprint, planificamos el sprint en función de los objetivos del inicio. Tomamos rompecabezas y comenzamos salchichas. Un nuevo desafío es una nueva rama en su sistema de control de versiones favorito. ¿Ya terminaste? Emitimos una solicitud de extracción, espere hasta que alguien llegue a la revisión. ¿Se fue la revisión? CI funcionó bien? Bueno, entonces puede mantener todo en la rama de desarrollo, esperar la luz verde del conjunto de desarrollo y actualizar el servidor de prueba. El código que almacenamos en GitHub . Hasta el primer cliente que pagaba, estos eran depósitos públicos abiertos. Como una persona que ha tratado de promover varias soluciones de código abierto en el pasado, me molesta sinceramente cada vez que una startup comienza a temblar por la seguridad de su código antes de comenzar a ganar dinero.Si intenta copiar, este es un claro éxito comercial . No cuesta nada cerrar el repositorio más tarde. Y los negocios, ya sabes, están enterrados, por regla general, lejos de estar en el código. Tengo acceso al código de muchos, incluidos productos muy exitosos, pero ¿vale la pena decir que al tenerlos ni siquiera repetiré de cerca su éxito? Para construir contenedores Docker y ejecutar pruebas automáticas, decidimos probar las acciones de GitHub , afortunadamente, nos dieron acceso preliminar. En general, las impresiones se mantuvieron bastante agradables, la velocidad de montaje es satisfactoria. Lo único que fue desagradable fueron las actualizaciones con pérdida de compatibilidad con versiones anteriores. Un par de veces cambiaron bastante el esquema de descripción de acciones y tuvieron que reconfigurar todo. Pero sabíamos lo que estábamos haciendo cuando acordamos probar el producto en estadoBeta .

Desde los primeros días, literalmente, desde el desarrollo de una página de inicio para pruebas de demanda, intentamos lanzar lanzamientos al menos una vez por semana y probar al menos una hipótesis. Al principio, las hipótesis eran más globales, tratamos de encontrar varios problemas, dirigirnos al público y desarrollar una propuesta. Pero cuanto más se desarrolló el producto, menos globales se volvieron y la esencia en sí misma era menos probable que cambiara. El proyecto comenzó desde cero, con la página de inicio habitual, luego en la rodilla creamos un cliente de demostración del bot de chat, que todavía se cuelga en nuestra página principal. Esta demostración podría reproducir un diálogo estrictamente programado y nos sirvió como una demostración de lo que podría hacerse en nuestro constructor, el resultado de su trabajo, y no el constructor en sí. El truco fue que asumimos que el negocio no vendría a nosotros para el diseñador de bot,pero por algún resultado, la ventaja que le dará. Queríamos servir a nuestros clientes una taza de café hecha por nuestra cafetera, en lugar de mostrar la cafetera en sí. Es fácil adivinar quepreparar una taza de café es mucho más rápido y más barato que recoger una máquina de café . Guiados por este principio, decidimos hacer una demostración del cliente primero, especialmente porque con una serie de herramientas listas para usar, no nos llevó más de dos tardes, incluido el desarrollo de escenarios de diálogo.

Cuando vimos el interés de los visitantes del aterrizaje y las conversiones adicionales generadas por nuestra demostración, decidimos que iríamos más allá. Recuerdo que nuestro primer lanzamiento del constructor fue un formulario de registro con un formulario de inicio de sesión, después de lo cual el usuario fue llevado a una página con una disculpa y una promesa de informar cuando algo más funcionaba. Hice los formularios de inicio de sesión y registro cientos de veces en mi vida y ni siquiera podía pensar que aquí encontraríamos muchos problemas de inmediato.Alrededor del 60% de los primeros usuarios simplemente no pudieron completar el proceso de registro . Para quién el botón no funciona, para quién no llega el correo electrónico, para quién es otra cosa. Al principio, percibí la idea de lanzar solo un par de formas con escepticismo, pero una primera mirada a Yandex. Métrica dejó en claro que era más probable que fuera la decisión correcta. La constatación de que los usuarios se comportan de manera diferente de lo que te gustaría, y a veces la forma en que creías que no podías, tuvo un gran impacto en todo lo que hicimos a continuación. Como pasatiempo, pasé varias veces a la semana en un par de horas en un navegador web simplemente viendo cómo los usuarios usan nuestro oficio.

Entonces, poco a poco, agregamos funcionalidad a nuestra creación y llegamos a un producto que todavía tiene valor no solo para nosotros, sino también para nuestros usuarios, algunos de los cuales incluso nos pagan dinero. A la larga, no entendimos a qué queremos llegar, cómo se verá nuestro producto. Lo único que entendimos entonces fue que no entendemos nada y estamos en un estado de incertidumbre.

Resultado


Este experimento nos llevó a mí y a mi equipo a una inversión angelical de la categoría de amigos, familiares, tontos, creada por MVP, primeras ventas, gran experiencia, muchas alegrías y decepciones. Todavía no somos un verdadero negocio, pero nos esforzamos por convertirnos en uno. Y cuando digo esto, quiero decir que todavía estamos en busca de un modelo de negocio sostenible y un ajuste de mercado de productos. Nuevamente, planeamos buscar el concepto de producto correcto, nuestro cliente, nuestro mercado.

Los objetivos iniciales se lograron de ninguna manera, pero el proyecto creció de un pasatiempo hogareño y se convirtió en un trabajo de tiempo completo, y la responsabilidad se mostró a los inversores, usuarios y empleados. Por supuesto, el proyecto tiene muchos problemas, tanto conceptuales como técnicos, pero no hay nada que no se pueda resolver y planeamos continuar trabajando.

Antes de embarcarme en la parte más técnica de mi obra, probablemente valga la pena contar brevemente qué le permite hacer el producto.

  • Administra chatbots en tu cuenta
  • Editor visual de chatbot
  • Controle el acceso a los bots de chat (acceso de edición, acceso público)
  • Posibilidad de publicar bots de chat en la web (widget, incrustado, pantalla completa)
  • Configuración de Chatbot (diseño, nombres, métricas, posición del widget, etc.)
  • Soporte para integrar chatbots con servicios externos a través de solicitudes GET y POST
  • Análisis de diálogos de bot
  • Administración de cuentas
  • Modelo de suscripción, gestión de suscripción


Arquitectura


Ahora, conociendo los antecedentes, objetivos, ideas y principios que nos guiaron en el desarrollo, puedo comenzar a dar una descripción general de cómo funciona todo esto. Dado que nuestra elección inicial era crear chatbots para sitios y chatbots de pantalla completa, como app.botlify.io/bot/5de53dbf9b9bae002b319600 , estaba claro que la mayor parte del trabajo estaría en el lado frontal. Como resultado, el frente del trabajo en el cliente se formó en una lista significativa de tareas y lista de deseos:

  1. Cree / encuentre una biblioteca cliente, una especie de "motor" para bots de chat en un navegador que comprenda las instrucciones json recibidas y mantenga un diálogo con el usuario.
  2. Cree una aplicación para editar nodos de bot, que guardará una lista de nodos y enlaces entre ellos en algún objeto json (en función del cual la biblioteca del cliente llevará a cabo diálogos).
  3. , , , - . , , , . , , , ..
  4. , , . id , :

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

La interfaz maneja toda la lógica de los diálogos, desde la creación de bots de chat (nodos y conexiones) hasta el trabajo directo con ellos en el cliente web. El papel del backend es más sobre la gestión de acceso, suscripciones, boletines, notificaciones y el almacenamiento de datos transmitidos desde muchos clientes web.

Interfaz


Para el frente, usamos Reactjs . Empacamos todo en Docker (lo compilamos y lo metemos en el contenedor nginx), el código en Github en repositorios privados, para CI usamos Acciones Github . Lanzamos contenedores en servidores VPS comunes con scripts de bash simples. Para simplificar el desarrollo de la interfaz de usuario tomó Blueprint .

  • Web — javascript , - . json -, . -(, , , , , .).
  • Web — javascript . id , , Web- .
  • — , . json, -. , «» , — -.
  • Cuenta de usuario: una aplicación web para administrar su cuenta, suscripción y bots.
  • El panel administrativo es una aplicación web para administradores. Gestión de usuarios, bots, suscripciones, cuadros de mando con análisis.


El siguiente diagrama muestra los componentes de la interfaz y cómo interactúan entre sí. El cliente web y el editor de bot solo se usan en el contexto de otras aplicaciones, mientras que si el editor solo se usa en nuestras aplicaciones, el cliente web también puede ser usado por nuestros clientes como un módulo web. Al compilar el proyecto, los paquetes con Webclient y Editor se agregan a las aplicaciones Tablero y Administrador. Además, el módulo web está construido utilizando webpack para la entrega a los usuarios.



MVP 1. Cliente web


Como startup, siempre nos esforzamos por lograr los máximos resultados utilizando un mínimo de recursos. Me parece que un paso bastante lógico para el primer MVP fue la creación de un cliente web desde el punto de vista de que representaba la "cara del producto", mostraba el resultado del trabajo del diseñador y no el proceso de creación del bot: una taza de café, no una máquina de café. Para minimizar el tiempo de desarrollo de la solución, decidimos buscar bibliotecas adecuadas para nuestras solicitudes y, de repente, ¡las encontramos! ¡lucasbassetti.com.br/react-simple-chatbot es un componente de reacción que cubrió casi todas nuestras necesidades!

Este componente sugirió describir la lógica del chatbot en forma de una serie de pasos, leer los valores ingresados ​​por los usuarios, personalizar la apariencia, validar los datos y, para empezar, parecía lo suficientemente flexible. La descripción de los pasos más simples se ve así:

<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,
        },
      ]}
    />

Comenzamos intentando de esta manera componer un chatbot que presentara nuestro proyecto, cuyo mapa mental estaba en la pantalla al comienzo del artículo. Por supuesto, describir manualmente tal json resultó ser bastante inconveniente, y tuve que escribir muchas funciones personalizadas, pero en general este proceso me permitió comprender cómo funciona el componente, cómo lograr el resultado deseado con él.

Además, mi colega personalizó la apariencia, hizo varias opciones de visualización y preparamos un ejemplo con una barbería y una exposición de Van Gogh.. Incluso podría notar que ni siquiera pensamos en la optimización de imágenes. Sí, fue y no fue necesario. En el proceso de trabajo, hemos formado una visión aproximada de cómo funcionará el cliente y comenzamos a buscar soluciones para el propio diseñador, a fin de aprovechar los beneficios de la edición visual lo antes posible.

MVP 2. Constructor


Según lo que vimos al trabajar con el cliente, llegamos a la conclusión general de que el bot puede tener varios tipos de acciones: enviar algo, esperar las acciones del usuario, enviar una solicitud a un servicio externo. Para un editor de bot mínimamente viable, decidimos limitarnos a los bloques:

  • Inicio: una unidad técnica que inicia una nueva sesión
  • Fin: bloque que finaliza la sesión
  • Mensaje: al llegar al bloque, el bot envía el mensaje especificado en el cuerpo del bloque
  • — . ,

Se suponía que los bloques estarían interconectados por flechas o líneas. Todos los bloques, excepto el bloque "Inicio", tienen un puerto de entrada (socket). Muchas líneas pueden conectarse al puerto de entrada, conectando la unidad con otras. Todos los bloques, excepto el bloque End, tienen de uno a varios puertos de salida. Los puertos de salida determinan a qué control de bloque se transfiere después de que se completa la lógica del bloque actual.

Después de una breve inspección de las soluciones disponibles, nos decidimos por Rete.js (https://rete.js.org). Conocí la documentación, los ejemplos y encontré en ellos todo lo que necesitábamos para comenzar. Incluso tenían un ejemplo solo con un bot de chat, que fue el último desencadenante

Rete . . , — , JSON


Nodo en Rete.js

Todos los nodos pueden contener un nombre, entradas, salidas y controles. Las entradas y salidas deben ubicarse a la izquierda y a la derecha del nodo, respectivamente (para los nodos personalizados puede haber excepciones). Están representados por un zócalo y pueden tener nombres. Para las entradas, permitimos un número ilimitado de conexiones (puede llegar al nodo de muchas maneras), para la salida nos limitamos a una sola conexión, sin embargo, a diferencia de los zócalos de entrada, algunos bloques tienen muchos zócalos de salida.

Rete.js está construido de tal manera que su funcionalidad se expande creando nodos, controles y componentes personalizados, lo que nos permitió obtener rápidamente exactamente la imagen que queríamos ver, ¡por lo que agradezco a los creadores de Rete ! ¡Por supuesto, uno de los más importantes es un editor listo para usar!

Como está escrito endocumentación :
Un editor es un área con nodos y conexiones entre sus sockets. Las siguientes opciones están disponibles:

  • Interacción con el espacio de trabajo (mover, escalar) y gestión de nodos (mover, agregar, eliminar)
  • Visualización de conexiones, nodos, sus entradas / salidas y controles.
  • Manejo de eventos del editor
  • Esquema de importación / exportación en formato JSON
  • Ampliando la funcionalidad con complementos
  • Personalización del espacio de trabajo, nodos y conexiones.


Después de haber evocado un poco con Rete y haber estudiado en ejemplos más detallados, logramos construir algo que nos permitió crear y eliminar bloques "inicio", "fin", "mensaje", "entrada de teclado". En la salida, recibimos json con una descripción de los nodos, sockets y líneas que los conectan.

Una de las primeras versiones del editor.

Ya es algo, pero esto no es suficiente, porque nuestro cliente web no entiende este json. Necesita algún tipo de la suya, con la descripción de los pasos. Se decidió incrustar un convertidor de un formato json a otro en el cliente.

Transformador Json


La utilidad recibe NodesMap, compilado por el editor, como entrada, y devuelve un StepsMap que el cliente entiende. El código de todo el transformador toma un poco más de 100 líneas, dependiendo del tipo de nodo y los datos, se crean un paso adecuado, funciones de disparo y un conjunto de instrucciones (acciones) que se realizarán en este paso. Hay instrucciones que guardan la variable en el estado de chatbot, hay otras que sustituyen la variable en el texto o envían una solicitud a nuestro servidor.

Después de unir los componentes, comenzamos a probar las herramientas resultantes. Incluso sin el backend, fue muy emocionante. Creamos diálogos en el editor e insertamos json en el cliente a través de herramientas de desarrollo, y como resultado obtuvimos un bot que dice cómo lo necesitamos. También sabe cómo guardar variables y usarlas, ¡maldita sea! Grandes sensaciones de las primeras victorias ... El mosaico del dispositivo de nuestra aplicación ya se ha formado prácticamente en mi cabeza, tenemos algo funcionando sobre los principios que queremos usar en el futuro. Tenemos un cierto esqueleto alrededor del cual quedaba para construir "carne". Y lo más importante: quedó claro cómo hacer esto:

  1. Cambie el editor, agregue el tipo de nodo deseado
  2. Enseñamos al transformador JSON a transformar un nuevo nodo en un nuevo paso
  3. Enseñamos al cliente a trabajar con un nuevo paso.

Por otro lado, era necesario comenzar a participar en la cuenta personal del usuario para que fuera posible crear bots, guardarlos, administrarlos y decidimos concentrarnos en esto para mostrar rápidamente a los usuarios no un concepto, sino un producto.

Cuenta de usuario


Las bibliotecas anteriores realizaron ciertas funciones relacionadas con la creación de la lógica de chatbot (editor), su interpretación o su reproducción (cliente). Los problemas de almacenamiento de datos, la capacidad de cargar bots creados, administrarlos y establecer propiedades no relacionadas con la lógica permanecieron abiertos y la aplicación debería haberlos resuelto para los usuarios. Armados con blueprintJS, esbozamos un prototipo de una cuenta personal en la que era posible registrarse y crear varios bots. Cuando haces clic en el bot para crear, una persona tuvo que caer en el editor con un nuevo bot, y cuando haces clic en la tarjeta del bot en el editor con este bot. Decidimos confiar las funciones de cargar y guardar el bot a través de la API de nuestro backend a esta capa para dejar al editor del bot independiente del backend.



La aplicación de la cuenta del usuario puede descargar el paquete del editor y transfiere los datos listos para su visualización. Esta aplicación también gestiona formularios para configurar propiedades de bot (nombre, claves de API, avatar, configuración de publicación) y le permite ver estadísticas. Para permitir que los usuarios vean inmediatamente el resultado del editor, agregamos un cliente web a la oficina del usuario, al que le damos el esquema json bot, lo interpreta en pasos y lo reproduce en la pestaña "vista previa". En general, este es un panel de administración muy clásico con un par de componentes interesantes (editor de bot y cliente web), creo que muchos lo hicieron. Pero fue en esta etapa que se volvió notablemente inconveniente desarrollar nuestra aplicación.

Inicialmente, nos pareció una buena idea contener los componentes del producto en diferentes repositorios y no vimos ningún problema particular en esto. Sin embargo, rápidamente se hizo evidente que mantener muchos repositorios actualizados es problemático, sin mencionar la necesidad de bailar con una pandereta cuando se desarrollan, porque en cierta medida son interdependientes. Y dado que solo teníamos un desarrollador a tiempo completo, este enfoque fue una gran punzada. Y cualquier implementación se convirtió en una rama del infierno en la tierra debido a la diferencia en el ensamblaje y publicación de bibliotecas, aplicaciones, problemas de compatibilidad con versiones anteriores. De ahí la conclusión banal, pero no la más inútil: la asignación prematura de módulos puede hacer más daño que ayudaYa me he convencido de esto muchas veces en el backend, y aquí vine otra vez, pero al frente. Sí, y no perdí una oportunidad en el backend: =)

Uno de mis colegas reunió su voluntad en un puño y combinó todo en un mono-repositorio administrado con lerna . Ahora nuestro único repositorio front-end está dividido en paquetes: administrador, cliente, común, tablero, editor, módulo web. Es posible que tengan un ensamblaje diferente en el interior, pero lerna les permite vincularse y actualizar las dependencias entre paquetes. Después de eso, el desarrollo y la implementación de la interfaz se hicieron mucho más rápidos y fáciles, todo está al alcance de la mano, pero aún se divide.

Después de crear el gabinete, pasamos un tiempo en nuevos bloques en el editor y su procesamiento por parte del cliente:

  • — . ( ),
  • — -
  • Email — email

No tengo mucho que contar sobre el panel de administración y el módulo web, todo es muy estándar allí. Permítanme señalar que el panel de administración tampoco debe hacerse con anticipación . Lo tenemos, pero nadie lo usa, porque personalmente no es difícil para mí ver todo lo que me interesa de inmediato en la base de datos. No hay humanidades que necesiten nuestro panel de administración en el equipo, y mantenerlo actualizado es esencialmente un poco menos costoso que mantener la cuenta de un usuario. Con el tiempo, se agregó un panel simple, que muestra los pagos, los nuevos registros y las visitas de la aplicación, pero esta información apenas vale el desarrollo de un administrador completo. paneles con tablas, formularios y autenticación separada

Resultados?


Pudimos construir prototipos y páginas de destino muy rápidamente. Sí, no era lo que muchos imaginan bajo el disfraz de MVP. Pero solo un par de noches después de que surgió la idea, podríamos comenzar a mostrárselo a las personas y probarlo. Diferentes páginas de destino, anuncios, textos en el bot: podríamos probar y buscar. Recomiendo encarecidamente que cualquier persona involucrada en el desarrollo de startups piense en cómo hacer las cosas lo más rápido posible. Creamos el primer producto para extraer valor en aproximadamente tres meses, y luego comenzó un proceso más gradual de mejora regular. Por supuesto, ahora tenemos más bloques dentro del constructor, agregamos validación, tipos de datos, solicitudes GET y POST, muchas configuraciones de diseño y visualización, pero podría comenzar sin todo esto, lo que hicimos.

Con el tiempo, el sistema comenzó a volverse más complejo y evolucionar, y no pude describir de cerca todo lo que realmente está sucediendo. Comience con poco, las cosas se complican con el tiempo, cuando sea necesario. Cualquier componente adicional puede resultar en un costo muy alto porque no solo es necesario crearlo e integrarlo, sino también respaldarlo, probarlo, documentarlo, implementarlo, monitorearlo y presentarlo a otros miembros del equipo. Probablemente no debería molestarse con las colas en RabbitMQ, si antes no había colas en su aplicación. Lo más probable es que las soluciones basadas en tecnologías que ya existen sean suficientes para empezar. Cualquier componente nuevo tiene un costo adicional para la integración, operación, prueba, soporte, documentación, implementación, etc., etc.

Espero que mi experiencia sea útil al menos para alguien. Durante mucho tiempo intenté averiguar qué centro determinar esto, pero no lo entendí. Avíseme si vale la pena escribir la segunda parte en la que quería hablar un poco sobre el backend, los servicios externos y los planes de desarrollo.

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles