¿Cómo trabajamos en un proyecto en Flutterflow?
6 min de lectura
En este documento recogemos nuestra manera de trabajar cuando nos enfrentamos a un proyecto de Flutterflow, que principalmente se suelen centrar en el desarrollo de aplicaciones que tienen que en algún momento ser subidos a las stores (iOs/Android) o necesitan una versión web y una versión móvil en una misma plataforma.
En este capítulo te contamos cómo afrontamos un proyecto en esta herramienta para que entiendas las peculiaridades de construír en esta herramienta.
Los proyectos que solemos acometer normalmente están centrados en aplicaciones en las que partimos de una buena definición de lo que el producto tiene que hacer, habitualmente con la UX y el diseño ya listo en Figma. En caso de que esto no esté definido, será necesario hacer este trabajo antes de arrancar siquiera la creación del proyecto en Flutterflow.
Para propósitos de esta guía asumiremos que tenemos ya el diseño y la funcionalidad de la aplicación definida. El objetivo ahora es detallar cuál es el proceso y la metodología de trabajo que seguimos en la agencia para trasladar este diseño a una aplicación funciona, que se divide en las siguientes fases:
Construcción de la Base de Datos en Supabase
Desarrollo de la aplicación en Flutterflow
Subida a producción y a tiendas
Vamos a ir detallando cada una de las fases y las actividades clave que realizamos en cada una de ellas.
Fase 1: Construcción de la Base de Datos en Supabase
Cuando empezamos un proyecto, nos centramos primero en la parte que es menos visual, pero que a la vez es la más importante de cara a trabajar el proyecto, ya que nos permitirá sentar las bases de la aplicación, entender bien las necesidades de estructuración de la misma y las vistas que necesita nuestra aplicación para ser completamente funcional.
Esto puede llevar a que el cliente durante las primeras semanas no reciba avances que pueda ver y tocar lo que puede llevarle a preocuparse, por lo que es imprescindible en esta fase explicar muy bien lo que va a suceder y que aunque no lo pueda ver estamos avanzando en el desarrollo de la aplicación. Un recurso que utilizamos muchas veces es el hacer pequeños prototipos funcionales que puedan ver para que vean que los datos están siendo traídos de la manera correcta.
Creando la base de datos
Lo primero que hacemos es revisar la estructura que va a tener la Base de Datos en Supabase. Para ello, vamos flujo por flujo de la aplicación, entendiendo qué es lo que tienen que hacer y anotando las entidades y campos que serán necesarios para nuestra aplicación, para posteriormente crear las tablas y populandolas con los campos que me voy encontrando en el diseño.
Este proceso no es algo estático ya que puede que en algunas paginas veamos unos campos y en paginas mas de detalle acabemos de ver todo lo que necesitamos que tenga esa tabla.
Una vez creadas las tablas y sus relaciones entre ellas, en las que es realmente importante definir cuál va a ser su interacción y relación, para entender qué sucede cuando eliminas un elemento de la tabla que puede que afecte a otra tabla, o que sea necesario relacionar algunas entre si para poder hacer la funcionalidad deseada. Cuando todo esto está definido, crearemos las vistas que tendrá Supabase.
Ejemplo: Tenemos compras hechas por los usuarios en la app y el usuario elimina su cuenta, lo esperado es que no se eliminen las compras sino que se anonimice el vendedor por protección de datos, pero no que se nos borre la orden.
Ejemplo 2: Que cuando se elimine el usuario se eliminen también sus interacciones como sus likes a posts o sus favoritos.
Las vistas nos permiten tener la información que necesitamos en cada una de las pantallas de nuestra aplicación y son una de las partes críticas del funcionamiento de nuestra aplicación, ya que definirá el rendimiento y la funcionalidad de nuestro proyecto.
Para montar las vistas vamos a ir pantalla por pantalla, identificando qué campos necesitamos mostrar y de qué tablas vienen. Para esto todo el trabajo previo que hemos hecho de definición de nuestro backend nos será de mucha utilidad.
Por ejemplo, en una pantalla de detalle de artículo no solo necesitaremos los datos del propio artículo, sino también el nombre de las categorías asociadas y el del autor. Como toda esa información está relacionada por IDs, lo que haremos será construir una vista (una query) que ya traiga todo resuelto: los datos del artículo más las relaciones necesarias.
Así evitamos tener que lanzar múltiples queries desde el frontend. El objetivo es claro: una sola query por pantalla. Esto es especialmente importante porque vamos a cargar el contenido en bloques, y no todo de golpe. Optimizar desde el principio nos va a ahorrar problemas luego.
Para finalizar la creación de la base de datos nos centraremos en las RLS, uno de los apartados que es clave para hacer aplicaciones seguras y que no se suele tener en cuenta a la hora de desarrollar aplicaciones de primeras. Normalmente siempre añadiremos reglas para las 4 acciones, SELECT, INSERT, UPDATE y DELETE, así supabase va a saber que hacer cuando reciba una petición en cualquiera de los casos. Para ello vamos a pensar que condiciones son necesarias para que un usuario pueda hacer esa acción y trataremos de definir unas reglas de seguridad apropiadas.
Esta sea probablemente la fase más compleja del desarrollo del backend, especialmente si queremos hacer aplicaciones que realmente sean seguras. A continuación puedes ver un par de ejemplo de situaciones en las que las aplicamos y por qué son relevantes.
Ejemplo: Un usuario necesita estar autenticado (primera regla) dentro de nuestra aplicación para poder leer las filas de la tabla de productos sin ninguna reestricción mas, podríamos tener el caso de que solo pudiera ver los productos de la tienda en la que esta asociado por ejemplo.
Ejemplo 2: Un usuario puede hacer UPDATE de su perfil siempre y cuando este autenticado, pero no de los demás a no ser que sea un Admin de la App, pero hay que tener cuidado de que un usuario no pueda actualizarse a si mismo el campo donde se añade como Admin para que no tengamos una brecha de seguridad pro allí.
Una vez tenemos todo esto construido, llega el momento de abrir el proyecto de Flutterflow y empezar a desarrollar la parte más visual.
Fase 2: Desarrollando la aplicación en FF
Esta fase es cuando el cliente empezará a ver cómo su aplicación cobra vida, ya que somos capaces de mostrar por fin pantallas con datos reales que vendrán de nuestra aplicación.
Para ello, siempre lo hacemos de una manera organizada y siguiendo los siguientes pasos:
Conexión con Supabase
Configuración inicial de la aplicación
Creación de componentes y sus variantes
Autenticación y reglas de acceso (RLS)
Desarrollo por bloques funcionales
1. Conexión con Supabase
Antes de empezar a construir vamos a conectar Supabase y a recibir todo el esquema que hemos creado en el paso anterior. Esto lo hacemos antes siquiera de configurar el proyecto ya que es realmente importante que tengamos la aplicación bien conectada a los datos que hemos configurado de nuestro backend en la anterior fase.
2. Configuración inicial de la aplicación
Aunque podamos estar tentados a lanzarnos a construir pantallas y empezar a pasar nuestro diseño de Figma y desarrollar todas las funcionalidades, hay una parte de configuración inicial que es realmente importante de hacer y que debemos asegurarnos de que la cubrimos en todos nuestros proyectos.
Para ello, en todos los proyectos empezamos por configurar bien los siguientes aspectos:
Ajustes Generales:
Colores: (Complementar)
Tipografías
Es muy importante que ya que hemos pasado este trabajo inicial de creación de este sistema luego lo continuemos usando, ya que si en el futuro el diseño cambia, esto nos permitirá ser flexibles y mucho más rápidos antes cualquier cambio de nuestra aplicación, convirtiéndonos en mejores desarrolladores.
3. Componentes y variantes
Tras tener la configuración esencial de nuestro proyecto ya estamos listos para empezar a construir la interfaz, para lo cual usamos un enfoque basado en componentes y sus variantes.
Dedicamos una gran parte del desarrollo inicial a entender cuáles son los componentes que debemos desarrollar dentro de cada pantalla, como por ejemplo cards de información, pantallas de gráficos o listas y crearemos un componente de cada una de ellos.
Esto nos permite ganar en consistencia y velocidad de desarrollo futuro de nuestra aplicación, ya que al crear estos componentes vamos a tener una coherencia en cómo se va a ver nuestra aplicación y nos permitirá ser más ágil cuando vengan cambios, ya que si utilizamos bien los componentes solo tendremos que hacer el cambio una vez, en contraposición con tener que ir buscando todos los lugares en los que teníamos ese elemento sin ser un componente.
Además, si hacemos bien estos componentes y sus variantes, seremos mucho más rápidos al pasar el diseño de Figma a nuestra aplicación ya que la mayoría de páginas se van a componer de combinaciones de estos componentes.
Puede que algunos de los componentes requieran de crearse con código personalizado, cosa que dejamos para un paso posterior en el que ya tengamos bien configurados los datos que traemos de Supabase.
4. Creando la autenticación
Una vez que tenemos las pantallas a nivel de interfaz definidas, es el momento de integrarlo con los datos reales de nuestra aplicación, para lo cual es necesario siempre empezar creando la autenticación y asegurándonos de que funciona correctamente antes de centrarnos en traer los datos de la base de datos.
Para ello podemos apoyarnos en las plantillas que vienen de Flutterflow para ser más ágiles, o rehacerlas de cero, pero en ambos casos nos aseguraremos de crear todas las páginas necesarias como:
Log In
Sign Up
Olvidar contraseña
Cuando esto esté listo, haremos un test de autenticación en nuestra aplicación y veremos que somos capaces de acceder a la aplicación de manera correcta.
5. Construcción de las pantallas y los flujos
Una vez que tenemos todo esto listo podemos empezar a avanzar con pantallas e ir terminando flujos enteros y concretos para poder lanzarlos a pruebas.
Nos centramos en una funcionalidad cada vez, atacando primero aquellas que sean más esenciales para poder enseñárselo al cliente lo antes posible. Lo que buscamos aquí es que puedan testear cada una de las funcionalidades que desarrollamos asegurándonos de que funciona correctamente y aportando su feedback en las fases más iniciales posible.
Esto nos permitirá entender si estamos pasando por alto algún factor de la aplicación que no hayamos definido bien en la primera fase, algo que es realmente habitual, así como no tener un test masivo al final de la aplicación que nos lleve a dolores de cabeza.
Además, es una muy buena práctica en esta fase, ir mostrando los avances con una cadencia semanal. Normalmente cuando terminamos una funcionalidad o pantalla clave, le grabamos un loom al cliente para que lo pueda ver y nos pueda dar su feedback, incluso si no está listo para ser testado en la propia aplicación de Flutterflow.
Además, en esta fase, nos centraremos en revisar las RLS que hemos definido anteriormente para ver si somos demasiado restrictivos o demasiado permisivos y que los usuarios según sus roles y permisos pueden acceder a la información correcta.
6. Subida del proyecto (Opcional)
Fase final en la que configuraremos las tiendas, suelo hacer esta fase al final del primer flujo que terminemos de la aplicación, para que el cliente pueda ir rellenando todos los pasos que se requieren para subir a las tiendas: descripción, categorias, politica de privacidaad, etc…, y mientras podemos subir la App a prueba interna en Google Play y a TestFlight en Play Store para que el cliente pueda ir testeando los flujos a medidas que los terminamos y resolvemos los bugs.
Consideraciones finales.
Con esto tendríamos el proceso que seguimos en la mayoría de proyectos a grandes rasgos. Sin embargo cada proyecto tiene sus pecularidades que hacen que no siempre podamos seguir estas fases de manera cronológica y tal cual están descritas aquí.
Nuestra intención es transmitir nuestra manera de enfocar un proyecto de la manera más sencilla posible para dar una guía de referencia a las personas que están enfrentándose a proyectos en esta herramienta y surgen de nuestra propia experiencia y manera de trabajar en base a nuestras experiencias con clientes reales.
*Este documento es un proceso que está en constante evolución, por lo que el contenido del mismo puede ir cambiando con el paso del tiempo, sin embargo los principios que rigen nuestra manera de crear proyectos están pensados para ser transversales a cualquier proyecto.