Desarrollador inicial y líder técnico · ReviewTree

El reto no eran las reseñas. Era obtener los datos.

Un negocio no captura a sus clientes de nuevo en una plataforma de reseñas. Ya los tiene en un sistema de gestión de clínicas, de programación de servicios o de expedientes electrónicos. Para pedirle una reseña a la persona adecuada en el momento adecuado, ReviewTree debía conectarse al sistema que usara cada negocio, entender cómo representaba a un cliente y una cita, y seguir haciéndolo de forma confiable.

Dieciocho integraciones, seis áreas

Al entregar la plataforma al equipo que me sucedió, había construido dieciocho integraciones con terceros en las áreas siguientes. Los importadores de citas obtenían únicamente datos de citas y de los clientes asociados, nunca expedientes clínicos.

Cada origen tenía su propio modelo de autenticación, límites de solicitudes, formas de fallar y manera de representar a un cliente y una cita. La mayoría no ofrecía un mecanismo de envío automático de eventos, por lo que los importadores consultaban periódicamente cada sistema. Los callbacks de OAuth eran las únicas llamadas entrantes de esos terceros. Cuando no había API, recurría al web scraping, con la fragilidad que eso implica.

La decisión que marcó la diferencia

Mantuve esa variedad fuera del núcleo. La plataforma usaba un solo modelo interno para clientes, citas y los eventos sobre los que valía la pena pedir una opinión, con una correspondencia de datos para cada origen.

El objetivo era que agregar una decimonovena integración significara crear un servicio y una correspondencia nuevos, sin agregar otra condición al código que también ejecutaban las demás integraciones. Esa separación era mi forma de incorporar nuevos sectores sin volver cada vez más costoso modificar toda la plataforma.

Ser también el sistema con el que otros se integraban

Construí la primera API REST/JSON de ReviewTree para cuentas, usuarios, contactos, reseñas, comentarios, encuestas y clientes de los sistemas de origen. La autenticación usaba claves de API por cuenta. El modelo inicial tenía una sola clave por cuenta; después lo amplié para admitir varias, con una interfaz de administración para emitirlas y revocarlas.

También desarrollé un cliente JavaScript escrito a mano y una herramienta de pruebas independiente para ejercitar los endpoints fuera de la aplicación. Esto ofrecía un cliente a los integradores y nos permitía comprobar la interfaz sin depender de la UI de la aplicación.

Además, construí webhooks de salida: suscripciones por cuenta a tipos de evento específicos, con entregas asíncronas mediante trabajos en segundo plano. Una interfaz dentro de la aplicación permitía a cada cuenta configurar sus propias suscripciones.

Después dejé de ser indispensable

Recluté e incorporé a quienes continuaron el desarrollo, establecí estándares de revisión de código y transferí la plataforma a un equipo dedicado. La meta era que el equipo asumiera la responsabilidad, en lugar de que yo siguiera siendo su único punto de dependencia.