El mes pasado estuve en una reunión con un cliente donde tres personas distintas usaron tres palabras distintas para describir el mismo tipo de decisión. Una habló de "elegir una librería". Otra habló de "elegir un framework". Una tercera preguntó si el proyecto quedaría "atado a la plataforma". Todos asentían como si se entendieran entre sí. Nadie se detuvo a preguntar si en realidad estaban hablando de lo mismo.
Se le notaba en la cara a la clienta: no tenía idea. Y la verdad, es normal. Los desarrolladores usamos estas tres palabras de manera intercambiable todo el tiempo, aunque describen tres niveles muy distintos de "cuánta estructura viene ya construida". Si usted está por firmar un contrato o leyendo una propuesta, esa diferencia puede cambiar su presupuesto, sus plazos, y qué tan atado queda a un proveedor dentro de cinco años.
Así que aclarémoslo, con una analogía que uso con casi todos los clientes que me preguntan.
Imagine una Caja de Herramientas, una Estructura de Casa y un Terreno
Imagine que está construyendo una casa.
Una librería es una caja de herramientas. Adentro hay un martillo, una sierra, un nivel. Usted decide cuándo tomar el martillo y para qué lo usa. A la caja de herramientas no le importa qué casa está construyendo. Simplemente espera a que usted meta la mano.
Un framework es una estructura de casa ya construida. Las paredes, los ambientes y las cañerías básicas ya están ahí, distribuidos como los diseñó otra persona. Usted todavía elige la pintura, los muebles y los terminados, pero construye adentro de esa estructura, no alrededor de ella. Si quiere un ambiente que la estructura nunca contempló, eso se convierte en un trabajo mucho más grande.
Una plataforma es todo el terreno, ya conectado al agua, la electricidad y el camino. Usted no recibe solo una estructura. Recibe el suelo sobre el que se asienta, los servicios que la mantienen funcionando, y muchas veces las reglas de qué le está permitido construir ahí.
Es el mismo proyecto de construcción. Tres niveles completamente distintos de "cuánto ya está decidido por usted". El software funciona igual.
Qué Es Realmente una Librería
Una librería es un fragmento de código que alguien ya escribió para que usted no tenga que escribirlo. Usted la llama cuando la necesita, y ella le devuelve una respuesta.
Digamos que su sitio web necesita mostrar fechas en un formato claro y legible, o necesita verificar que una dirección de correo electrónico parezca real. Alguien ya resolvió exactamente ese problema y empaquetó la solución como una librería. Un desarrollador la agrega a su proyecto y la llama cada vez que hay que darle formato a una fecha. El resto del tiempo, simplemente espera ahí, sin hacer nada.
Lo importante: usted sigue teniendo el control. Su código decide cuándo se ejecuta la librería, y no al revés. Es una herramienta dentro de la caja, no un conjunto de reglas que usted tiene que seguir.
Qué Es Realmente un Framework
Un framework invierte esa relación. En lugar de que usted lo llame cuando lo necesita, es él quien llama a su código, según su propio calendario, en los momentos que él decide.
Piense en un framework como esa estructura de casa ya construida. Ya decidió que hay una cocina acá y un dormitorio allá. Su trabajo es completar esos ambientes de la manera en que la estructura lo espera. Ejemplos conocidos son React y Angular, usados para construir lo que el cliente ve en el navegador, o .NET y Ruby on Rails, usados para construir la lógica de negocio detrás de escena. Cuando un cliente hace clic en "enviar" en un formulario de contacto, generalmente es el framework el que nota ese clic y le pasa el control a su código en el momento exacto, y no su código el que sale a buscar ese clic por su cuenta.
Esto es genuinamente útil. Significa que un desarrollador no tiene que reinventar "cómo reacciona un sitio web a un clic en un botón" desde cero en cada proyecto. Pero también significa que su proyecto hereda las opiniones del framework sobre cómo deben organizarse las cosas. Ir en contra de esas opiniones se vuelve caro rápidamente, y por eso elegir bien el framework desde el principio importa más de lo que la mayoría de los dueños de negocio imagina.
Qué Es Realmente una Plataforma
Una plataforma es todo el terreno. No es solo código que se agrega a un proyecto. Es el entorno completo donde vive todo el proyecto, incluyendo los servidores, la seguridad, el sistema de inicio de sesión, y muchas veces un catálogo de complementos ya listos para usar.
Shopify es una plataforma para administrar una tienda en línea. Salesforce es una plataforma para gestionar las herramientas de un equipo de ventas. Amazon Web Services es una plataforma para ejecutar casi cualquier cosa, con cientos de servicios ya conectados entre sí. Cuando usted construye "sobre" una plataforma, no está solo tomando prestado código. Está alquilando terreno, y el dueño de ese terreno pone reglas reales sobre qué puede construir, cuánto le va a costar a medida que crece, y qué tan difícil es mudarse a otro lado después.
Por Qué Esta Distinción Importa al Leer una Propuesta
Aquí está la idea que quiero que se lleve: estas tres opciones cargan riesgos y costos muy distintos, y una propuesta que las mezcla sin distinguirlas está ocultando algo que vale la pena preguntar.
Una librería es de bajo riesgo. Si resulta ser la herramienta equivocada, un desarrollador la cambia por otra, y el resto del proyecto casi ni lo nota.
Un framework es un compromiso intermedio. Cambiar de framework más adelante casi siempre significa reconstruir partes grandes de la aplicación, no solo reemplazar una herramienta.
Una plataforma es el compromiso más grande de los tres. Sus datos, las cuentas de sus clientes, y muchas veces todo su proceso de negocio pueden terminar viviendo dentro del terreno de otra persona. Eso no es automáticamente malo. Muchos negocios exitosos funcionan por completo sobre una plataforma como Shopify o Salesforce porque resulta más rápido y más barato que construir todo desde cero. Pero conviene entrar en esa decisión sabiendo que está eligiendo un propietario, no solo tomando una herramienta de un estante.
La próxima vez que alguien le entregue una propuesta técnica, hágase una pregunta simple: "¿Esto es una herramienta que usamos, una estructura dentro de la cual construimos, o un terreno que estamos alquilando?" Se va a sorprender de cuánto cambia esa pregunta la conversación entera. Esto se relaciona directamente con qué es realmente una API, el tejido conector que permite que las herramientas, las estructuras y los terrenos se comuniquen entre sí, y también vale la pena entenderlo antes de comprometerse con una plataforma, ya que el riesgo de depender de un proveedor crece cuanto más profundo construye dentro del terreno de otra persona.
Si tiene una propuesta enfrente y no logra distinguir con cuál de las tres opciones se está comprometiendo en realidad, con gusto la reviso con usted. Hablemos de su situación.