Optera, una empresa brasileña de consultoría tecnológica, nos contactó con un desafío que pondría a prueba nuestras capacidades técnicas y nos brindaría la oportunidad de mostrar de lo que somos capaces como el primer cliente en encargarnos un proyecto full-stack, el cual hemos entregado con éxito en tan solo 3 meses.
La aplicación empezó como una idea para mejorar la interacción entre Optera y sus clientes, lo que sería un simple sistema de Helpdesk que proporcionaría un puente entre ambos. Aunque el objetivo inicial era construir un MVP, dicho puente tendría que estar bien construido de todos modos, por esa razón, y también como una oportunidad para desafiarnos a nosotros mismos, decidimos establecer un alto estándar para los aspectos técnicos del proyecto y tratarlo no como un MVP sino como un proyecto escalable y completamente listo para producción.
Para nuestro stack tecnológico en el front-end hemos elegido:
- TypeScript – Language used for the project.
- React.js – JavaScript Framework.
- Next.js – React Framework.
- Ant Design – Design system / Components lib.
- Styled-Components – CSS-in-JS solution.
- Redux Toolkit – Global state & services/API management.
- Socket.io – Websocket lib used for messaging.
Y para el the back-end:
- Node.js – JavaScript runtime.
- Express.js – Web app framework for Node.js.
- MongoDB – Document-oriented Database.
- Atlas Cloud – Cloud Storage for MongoDB
- JWT – Authentitcation/Encryption.
- Mongoose – Makes dealing with MongoDB easier.
- bcrypt – Password hashing lib.
- body-parser – Node.js body parsing middleware.
- multer – Node.js multipart file upload middleware.
- Socket.io – Websocket lib used for messaging.
Ahora bien, como persona con una orientación más técnica, una de las primeras preguntas que podría estar haciendo es «¿por qué no usó también TypeScript en el back-end?» Bueno, la respuesta es simple: dado que el proyecto estaba destinado a ser un MVP de entrega rápida, comenzamos haciendo un borrador inicial para el back—————-end en JavaScript y luego, después de haber establecido una arquitectura bastante bien pensada, no lo hicimos. No pensé mucho en refactorizarlo en TS y simplemente coloqué algunas pruebas automatizadas en la parte superior para asegurarnos de que todo estuviera ordenado y funcionando como debería.
La prueba se realizó a través de la herramienta de línea de comandos Newman de Postman. Nuestra idea era integrarlo con Gitlab CI pero, desafortunadamente, no pudimos averiguar cómo configurar una imagen de MongoDB con colecciones preestablecidas junto con Node.js y Newman. Algo que investigaremos cómo hacer en un futuro. Sin embargo, aunque queríamos averiguar cómo implementar la IC adecuada, el cliente dijo que dado que es un MVP ya estaban satisfechos con solo poder ejecutar las pruebas localmente y nos pidió que lo dejáramos de lado, como un desafío de futuro.
La conceptualización del modelo back-end consistió en:
- Tres tipos de usuarios: Admin, Compañía y Helpdesk
- Chats (representando tickets de soporte)
- Mensajes
- Categorías (para filtrar y organizar los chats)
Cada tipo de usuario tendría diferentes características disponibles del back-end. Un usuario de la Compañía, por ejemplo, no debería poder crear una Categoría o editar a otros usuarios. Dichos endpoints y métodos solo deberían estar disponibles para usuarios administradores. Para realizar dicha autenticación y autorización, decidimos utilizar JWT.
Cada chat tiene su propia categoría y, en lugar de tener el chat como anfitrión de los mensajes, cada mensaje está vinculado a su propio chat, lo que viene a ser un enfoque más escalable para las bases de datos documentales.
Front-end:
Comencemos con el inicio de sesión:
Un inicio de sesión bastante simple, pero al principio tuvimos algunas dificultades para implementarlo ya que no teníamos experiencia con Redux Toolkit (RTK) y RTK Query. Incluso llegué a abrir una pregunta en StackOverflow sobre cómo llamar a los puntos finales secuencialmente con RTK Query y React Hooks.
Después de iniciar sesión, se nos presenta la pantalla del panel de control donde podemos ver todos los tickets de soporte abiertos y cerrados. Para fines de demostración, creé cuatro categorías, que en un escenario real representarían los sectores en los que Optera da soporte en las empresas de sus clientes. Echaremos un vistazo a las categorías más adelante.
Cuando se crea un usuario de la empresa, se asigna automáticamente un usuario del servicio de asistencia como usuario responsable de todos los tickets de soporte que ese usuario pueda abrir. Entonces, cuando un usuario de la empresa abre un nuevo ticket, suceden algunas cosas:
- El técnico helpdesk que es responsable por el usuario es automáticamente asignado al ticket.
- El ticket recibe un título de acuerdo con el nombre del usuario/empresa y el número de tickets que el usuario ha abierto previamente en esa categoría.
- Se envía un mensaje automático en el chat de acuerdo con el mensaje predeterminado predefinido que tiene cada categoría.
- Una vista previa del último mensaje enviado en el chat está disponible en el dashboard.
- El ticket de soporte está marcado como «aún por resolver».
Podemos obtener una vista previa del mensaje automático y luego verlo en azul cuando abrimos el chat. Este mensaje lo envía un usuario predeterminado configurado en el back-end que está designado para ser el bot de mensajería para la aplicación.
Un usuario del helpdesk puede ver el ticket de soporte recién creado en su panel y acceder al chat para intercambiar información con la empresa que lo abrió.
Se admiten todos los tipos de archivos, pero solo se pueden previsualizar las imágenes.
Nuestro mayor desafío con esta función fue asegurarnos de que el chat con Socket.io estuviera bien vinculado como los endpoints REST. Cuando empezamos el desarrollo del chat, ya teníamos un paquete de validación y manejo de errores bastante completo para los endpoints express compuesto por middlewares y utils. Entonces, para crear el sistema de mensajería y la transferencia de archivos, nos enfocamos mucho en cosas como la validación y el manejo de errores dentro de las llamadas de Socket.io.
Aquí podemos ver las categorías para cada tipo de ticket. El uso es completamente arbitrario y podría tener una infinidad de diferentes tipos de boletos.
Actualmente, no hay una función de creación de categorías en el front-end, ya que el cliente nos dijo que no era necesaria para una función MVP, sin embargo, hay endpoints y eventos Socket.io que cubren toda la aplicación, por lo que la creación de categorías es posible a través de Postman.
