Plataforma de conferencias FNTECH

De OpenStack a FNTECH

Entré a Tipit, una software factory de Buenos Aires, en febrero de 2014. En mis primeros dos años también trabajé para otros clientes (CrowdTangle, un agregador de posts de redes sociales, y Realty512, un sitio inmobiliario de Austin), en paralelo con la OpenStack Foundation, que terminó siendo el único cliente de Tipit.

El sistema de conferencias nació dentro de openstack-org, el monolito en SilverStripe que corría todo el sitio de la fundación; tengo unos 1.600 commits ahí. A medida que los Summits crecieron se partió en servicios: un compañero de equipo construyó el backend, summit-api en Laravel, y yo las apps de frontend encima.

Alrededor de 2021 FNTECH se quedó con la plataforma. Hasta entonces se ocupaban de la parte física de los eventos: equipamiento, mobiliario, staff, catering. Ahora la financian, la mantienen open source y la venden a clientes como Roblox, Facebook y OCP, el más grande. Sigo trabajando para Tipit, part-time, y FNTECH es hoy su único cliente, como antes lo fue OpenStack; durante años lo hice en paralelo con mi trabajo en Firstleaf.

La vida de un evento

Cada etapa es una app propia, todas sobre la misma API y el mismo modelo de datos. Un evento pasa por:

• Configuración: sede, salas, categorías de tracks y tipos de actividad, incluidos los breaks.
• Un call for presentations, en su propio micrositio.
• La selección a cargo de los track chairs; en los años de OpenStack, también con votación pública.
• La agenda.
• Credenciales, credenciales de acceso y señalética: una pantalla por sala con su agenda, que funciona sin conexión.
• Registración y venta de entradas, con un widget para que los asistentes gestionen sus órdenes.
• Un marketplace donde los sponsors compran servicios para sus stands.
• Reserva de las salas de reunión del lugar.
• Emails a lo largo de todo el proceso, programados y automáticos.
• En el lugar: kioscos en iPad que hacen el check-in e imprimen la credencial en el momento, y apps mobile para iOS y Android que escanean credenciales, para que los sponsors capturen leads y para el control de acceso.
• Una app nativa para asistentes en iOS y Android: agenda, entradas, networking y chat.
• El sitio del evento; durante la pandemia, con streaming en vivo y grabado, y chat.

El back-office

summit-admin es la app en React y Redux con la que los organizadores configuran y operan todo eso. El repo se creó en noviembre de 2017, mi primer commit es del día siguiente y desde entonces soy su principal contribuidor. Es sobre todo tablas densas, formularios profundos y flujos de aprobación que duran meses, desde la primera propuesta del CFP hasta la agenda final.

Alrededor construí la mayoría de las apps de frontend: call for presentations, track chairs, servicios para sponsors, los widgets de agenda y búsqueda, los widgets de la época de la pandemia (evento en vivo, chat, oradores, feedback) y la API de encuestas con su analítica. También soy el segundo contribuidor de openstack-uicore-foundation, la librería de UI que comparten todas.

El modelo de datos viene de la época de SilverStripe y lo diseñé junto con un compañero de equipo, que hoy es su responsable, igual que de la API.

Reportes, y GraphQL en retrospectiva

Los organizadores pedían reportes todo el tiempo (de oradores, sesiones, asistentes, sponsors), así que construí summit-reports-api de punta a punta, en Python, Django y Graphene, junto con las pantallas de summit-admin que la usan.

Elegí GraphQL porque los reportes parecían lecturas simples sobre unas pocas tablas: el cliente pide las columnas que quiere y las recibe. Los filtros lo desbordaron. Terminé generando SQL e inyectándolo en Graphene y django-filters para lograr consultas que GraphQL nunca iba a poder expresar. Si empezara hoy, la haría como una API REST común.

9.000 personas en una hora

El summit de OCP tiene unos 15.000 asistentes, y alrededor del 60% hace el check-in en la primera hora del primer día. Son unas 9.000 personas en 10 puestos: escanear el QR, imprimir la credencial, el que sigue.

El flujo se probó con tests de carga antes del evento. Ese día no hubo incidentes.

Themes y widgets, en retrospectiva

Para atender a varios clientes con un solo código, los sitios de los eventos se armaron con themes de Gatsby: un theme compartido y, encima, un sitio liviano por cliente. Los widgets (agenda, búsqueda, oradores) estaban pensados para embeberse en los sitios de los propios clientes.

Ninguna de las dos cosas envejeció bien. Los widgets nunca se embebieron en ningún lado; solo corrieron en nuestros propios sitios. Y con AI, mantener un sitio separado por cliente es tan barato que la capa de themes es más indirección de lo que vale. Estamos migrando el sitio del evento a Astro, sin themes.

En qué estamos ahora

Lo más reciente es el trabajo con agentes de código. Desde marzo de 2026 el equipo mantiene una base de conocimiento compartida, un vault de Obsidian en Markdown del que parte cada sesión, humana o de AI: la arquitectura de la plataforma y el mapa de servicios, patrones de diseño, reglas por stack para los agentes (Laravel, Django, React, Gatsby), cómo escribimos las especificaciones de diseño, el flujo de pull requests asistido por AI y sus controles de revisión, especificaciones de nuevas funcionalidades, conocimiento del día a día y postmortems de los eventos.

Yo aporto desde mi parte de la plataforma: los patrones de formularios de summit-admin, reglas para las apps React y el diseño de FNstream, una app nueva e independiente para manejar los streams en vivo de un evento.