Hice un pitch para Fintoc siendo trainee

Los trainees subimos un post contando nuestra perspectiva del programa, y una de las cosas choras que destacamos es hacer proyectos para las startups de Platanus Ventures. Ahora te vengo a contar cómo es un pitch (recuerda que un pitch es un documento con un problema y propuesta de solución, contamos mas de esto acá) que hice para Fintoc, startup que salió del primer batch.

Problema

En Fintoc son fans de la serie Silicon Valley, y quieren tener un parlante como el que avisa cuando minar Bitcoin deja de ser rentable que suene cuando hay problemas con los links, o cuando los usuarios usan una nueva feature que sacaron hace poco.

Definir la solución

El primer día me junté con Chris, dev de Fintoc encargado del pitch. Conversamos un buen rato sobre cómo podría ser la solución y qué features querían que tenga. La implementación estaba bastante abierta para que yo decidiera cómo quería hacerlo, lo que me gustó mucho.

Explicaré brevemente cómo funciona la solución a la que llegamos, y luego más en detalle cada concepto, así que no te preocupes si te pierdes un poco.

diagrama del flujo de requests entre las aplicaciones.

Para reproducir el sonido decidimos usar una raspberry que se conecta a un parlante. Si no has oído o no sabes qué es una raspberry, piensalo como un mini-computador del tamaño de una tarjeta de crédito, de bajo costo y muy programable.

En el raspberry hay una API en rails a la que se le debe hacer un request cada vez que se quiera reproducir un sonido. En el request se envía la información necesaria para poder descargarlo desde S3 y cachearlo en una base de datos, en caso de ser un sonido nuevo.

Para poder cambiar qué sonido se reproduce para cada evento de manera sencilla usamos ActiveAdmin, una gema de rails que nos permite tener un panel de administración con muy poco código.

Los requests a la API del raspberry se hacen desde una app de soporte que usa Fintoc llamada Hive. En Hive hay un engine de rails llamado Anton que encapsula toda la lógica relacionada a los sonidos y eventos, por lo tanto cuando hay un evento, desde el engine se hace el request a la API del raspberry, y este reproduce el sonido en el parlante.

¿Qué es un Engine?

En Rails se puede modularizar una aplicación usando Engines. Estos consisten en sub-aplicaciones independientes de la aplicación principal, parecido a los Blueprints de Flask o las Apps de Django.

Los Engines siguen el mismo patrón MVC que cualquier app de rails, es decir tienen sus propios controladores, modelos y vistas. En Platanus ocupamos una extensión de este patrón, la cual también se ve reflejada en el engine. Si quieres saber más tenemos un video sobre esto.

En el caso de Hive, la aplicación de soporte de Fintoc, hicimos un Engine llamado Anton. Anton encapsula toda la lógica relacionada a la interacción con el raspberry y el manejo de sonidos y eventos. Es la interfaz con todo lo necesario para interactuar con la API del raspberry, y la aplicación principal no depende de este para sus otras funciones.

Los engines viven en un directorio aislado.

¿Cómo hacemos que suene el parlante?

Al recibir el request, la API usa un programa llamado “aplay” para reproducir el sonido. Cada request debe venir con un token en el header, de esa manera nos aseguramos que el request viene desde Hive.

Ya estaba todo funcionando en la oficina, en donde corríamos Hive desde mi computadora que estaba conectada a la misma red que el raspberry. Ahora teníamos que hacer que exista una url pública que la app (Hive) en producción, hosteada en AWS, pueda llamar. Una posible solución era ngrok, pero la versión gratuita tiene un inconveniente: las urls son aleatorias. Podíamos hacer un script que actualizara los dominios en cloudflare cada vez que la url cambiara, pero ngrok tiene sus mecanismos para que la gente no haga eso, lo que es bastante lógico.

Cloudflare al rescate

En Fintoc usan cloudflare como DNS, y encontramos una solución que resultó perfecta: cloudflared. Es un software de cloudflare que nos permite crear un túnel entre un dominio en cloudflare y un servicio corriendo dentro de nuestro computador. Cómo funciona es bastante complejo y da para un post entero, pero nos permite hacer lo mismo que ngrok sin las limitaciones de la versión gratuita.

Argo Tunnel.

Este pitch involucró crear un engine de rails, hacer una api en un raspberry y abrir un túnel a una url pública para exponer los endpoints de la API, y un largo etc. de cosas bacanes donde aprendí mucho. Y aún quedan muchas cosas por hacer, como un sistema de eventos en AWS o hacer que con un bot de Slack hagan hablar al parlante. Y lo mejor de todo es que cuando terminas puedes ver cómo otras personas ocupan algo que hiciste, lo que es raro que se dé antes de salir de la universidad.

Pitches como estos hay muuchos más (hace poco tomé uno que consiste en hacer reverse-engineering de la API de una isapre), por lo que si te gusta hacer este tipo de cosas te invito a postular al programa trainee del verano, las postulaciones están abiertas.