Optera, una empresa brasilera de consultoria tecnològica, ens va contactar amb un desafiament que posaria a prova les nostres capacitats tècniques i ens brindaria l’oportunitat de mostrar del que som capaços de fer com el primer client en fer-nos l’encàrrec d’un projecte full-stack, que hem lliurat amb èxit en només 3 mesos
L’aplicació va començar com una idea per a millorar la interacció entre Optera i els seus clients, el que seria un simple sistema de Helpdesk que proporcionaria un pont entre tots dos. Encara que l’objectiu inicial era construir un MVP, aquest pont hauria d’estar ben construït de totes maneres, per aquesta raó, i també com una oportunitat per a desafiar-nos a nosaltres mateixos, decidim establir un alt estàndard per als aspectes tècnics del projecte i tractar-lo no com un MVP sinó com un projecte escalable i completament llest per a producció.
Per al nostre stack tecnològic en el front-end hem triat:
- 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.
I per al 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.
Ara bé, com a persona amb una orientació més tècnica, una de les primeres preguntes que podria estar fent és “per què no fer servir també TypeScript en el back-end?” Bé, la resposta és simple: atès que el projecte estava destinat a ser un MVP de lliurament ràpid, comencem fent un esborrany inicial per al back-end en Javascript i llavors, després d’haver establert una arquitectura bastanta ben pensada, no ho vam fer. No vaig pensar molt a refactoritzar-ho en TS i simplement vaig col·locar algunes proves automatitzades en la part superior per a assegurar-nos que tot estigués ordenat i funcionant com hauria de ser.
La prova es va realitzar a través de l’eina de línia de comandos Newman de Postman. La nostra idea era integrar-ho amb Gitlab CI però, malauradament, no vam poder esbrinar com configurar una imatge de MongoDB amb col·leccions preestablertes juntament amb Node.js i Newman. Alguna cosa que investigarem com fer en un futur. Malgrat això, encara que volíem esbrinar com implementar la IC adequada, el client va dir que atès que és un MVP ja estaven satisfets amb només poder executar les proves localment i ens va demanar que ho deixéssim de costat, com un desafiament de futur.
La conceptualització del model back-end va consistir en:
- Tres tipus d’usuaris: Admin, Companyia i Helpdesk
- Xats (representant tiquets de suport)
Missatges - Categories (per a filtrar i organitzar els xats)
Cada tipus d’usuari tindria diferents característiques disponibles del back-end. Un usuari de la Companyia, per exemple, no hauria de poder crear una Categoria o editar a altres usuaris. Dits endpoints i mètodes només haurien d’estar disponibles per a usuaris administradors. Per a realitzar aquesta autenticació i autorització, decidim utilitzar JWT.
Cada xat té la seva pròpia categoria i, en lloc de tenir el xat com a amfitrió dels missatges, cada missatge està vinculat al seu propi xat, la qual cosa ve a ser un enfocament més escalable per a les bases de dades documentals.
Front-end:
Comencem amb l’inici de sessió:
Un inici de sessió bastant simple, però al principi vam tenir algunes dificultats per a implementar-lo ja que no teníem experiència amb Redux Toolkit (RTK) i RTK Query. Fins i tot vaig arribar a obrir una pregunta en StackOverflow sobre com anomenar als punts finals seqüencialment amb RTK Query i React Hooks.
Després d’iniciar sessió, se’ns presenta la pantalla del panell de control on podem veure tots els tiquets de suport oberts i tancats. Per a fins de demostració, vaig crear quatre categories, que en un escenari real representarien els sectors en els quals Optera dóna suport en les empreses dels seus clients. Donarem un cop d’ull a les categories més endavant.
Quan es crea un usuari de l’empresa, s’assigna automàticament un usuari del servei d’assistència com a usuari responsable de tots els tiquets de suport que aquest usuari pugui obrir. Llavors, quan un usuari de l’empresa obre un nou tiquet, succeeixen algunes coses:
- El tècnic helpdesk que és responsable per l’usuari és automàticament assignat al tiquet.
- El tiquet rep un títol d’acord amb el nom de l’usuari/empresa i el nombre de tiquets que l’usuari ha obert prèviament en aquesta categoria.
- S’envia un missatge automàtic en el xat d’acord amb el missatge predeterminat predefinit que té cada categoria.
- Una vista prèvia de l’últim missatge enviat en el xat està disponible en el dashboard.
- El tiquet de suport està marcat com “encara per resoldre”.
Podem obtenir una vista prèvia del missatge automàtic i després veure’l en blau quan obrim el xat. Aquest missatge l’envia un usuari predeterminat configurat en el back-end que està designat per a ser el bot de missatgeria per a l’aplicació.
Un usuari del *helpdesk pot veure el tiquet de suport recentment creat en el seu panell i accedir al xat per a intercanviar informació amb l’empresa que el va obrir.
S’admeten tots els tipus d’arxius, però només es poden previsualitzar les imatges.
El nostre major desafiament amb aquesta funció va ser assegurar-nos que el xat amb Socket.io estigués ben vinculat com els endpoints REST. Quan comencem el desenvolupament del xat, ja teníem un paquet de validació i maneig d’errors bastant complet per als endpoints express compost per middlewares i utils. Llavors, per a crear el sistema de missatgeria i la transferència d’arxius, ens enfoquem molt en coses com la validació i el maneig d’errors dins de les crides de Socket.io.
Aquí podem veure les categories per a cada tipus de tiquet. L’ús és completament arbitrari i podria tenir una infinitat de diferents tipus de bitllets.
Actualment, no hi ha una funció de creació de categories en el front-end, ja que el client ens va dir que no era necessària per a una funció MVP, no obstant això, hi ha endpoints i esdeveniments Socket.io que cobreixen tota l’aplicació, per la qual cosa la creació de categories és possible a través de Postman.
