Blog / ¿Cómo pensar un Backend? - Coder-Box S01E04

¿Cómo pensar un Backend? - Coder-Box S01E04

¿Cómo pensar un Backend?

Coderbox S01E04

Anteriormente seteamos nuestro entorno de trabajo por el lado del frontend. En este capítulo toca encargarse del proceso de planificación de nuestro backend, y para eso tuvimos que recurrir a la voz de la experiencia, la estrella, creador y Gran Maestro Yoda de apx: Marce.

Durante el stream (que podés ver acá: ¿Necesitamos un Backend?) Marce atendió nuestras dudas sobre el backend y nos marcó el camino.

Vamos a intentar resumirte un poco lo que aprendimos:

¿Necesitamos un backend?

Ya vimos que cuando se nos ocurre una idea de app o web interesante y queremos plasmarla en un proyecto real, tenemos que hacernos ciertas preguntas como ¿A qué tipo de usuario va dirigido? ¿Qué problema resuelve? ¿Qué funcionalidades va a tener? ¿Qué datos voy a estar manejando?

Una vez que conocemos las funcionalidades y qué datos van a moverse dentro de nuestra plataforma podemos darnos cuenta si necesitamos un backend o si podemos usar un servicio externo y ahorrarnos las líneas de código.

En el caso de Coderbox sabemos que vamos a tener un sistema de usuarios por lo tanto tenemos que contemplar una base de datos. También vamos a contar con un conjunto de recursos con su respectiva información y todo esto debe estar almacenado en algún lugar. Teniendo en cuenta estas cosas decidimos que Coder-Box SÍ necesita un backend.

¿Cómo manejar el Registro y el Login?

Hay muchas formas de manejar la autenticación de los usuarios, algunas más conocidas que otras. Por ejemplo, podemos crear un usuario en nuestra base de datos a partir de un email y contraseña proporcionados por la persona, también podemos utilizar conectores sociales (login con google o facebook), o utilizar un sistema de códigos por email o mensaje de texto, entre otras. Todas son válidas, y tienen sus pros y sus contras.

Cuando surgió la idea de Coderbox teníamos en claro que el proceso tiene que ser cómodo para los usuarios y nos planteamos 2 opciones.

¿Conector social o autenticación passwordless a través de un código?

Durante el vivo le acercamos esta duda a Marce y llegamos a la conclusión de que si bien la autenticación a través de un conector social como facebook o google facilita mucho el proceso (con un par de clicks el usuario ya se loguea directamente sin necesidad de ingresar datos todo el tiempo) la gente puede utilizar varias cuentas y un email para cada red social, esto puede provocar que al momento de volver a ingresar en Coder-Box se presente la duda “¿Con qué email había entrado?” y haya que realizar algún proceso de conciliación de datos para evitar multicuentas. Ojo, hay servicios que resuelven gran parte de los inconvenientes, pero no suelen ser tan baratos.

Además, ya que Coder-Box apunta a un público de devs, es el proyecto ideal para salirse de lo “común” y mostrarte una opción passwordless.

¿Cómo funciona eso de passwordless?

Como lo dice el nombre, la ventaja de usar este método es que no necesitas definir una contraseña, como usuario solo ingresas tu email, a partir de ahí se genera un código único y se te envía a ese email (ya conociendo que solo vos tenes acceso), es un sistema eficaz y sencillo de llevar a cabo.

¿Cómo mandamos esos emails con los códigos?

A partir de la cantidad de SPAM que corre por internet desde hace varios años, no es una opción válida enviar emails desde un servidor propio, lo ideal es optar por un SaaS (Software as a Service), básicamente una compañía que envíe los emails por nosotros y que cumpla con los protocolos necesarios para evitar que los emails que queremos enviar caigan en Spam o nunca lleguen. Por ejemplo: SendGrid.


Acordate que si querés ver cómo fuimos planteando todo el login/register de Coder-Box (dónde guardamos la información, cuántos pasos conviene tener en el sistema de logueo, cómo adaptamos el diseño a la opción passwordless, qué consideraciones hay que tener en cuanto a seguridad, etc.) podés ver el vivo acá.

¿Cómo pensar nuestra base de datos?

Para empezar a visualizar la estructura de nuestra base de datos, primero vamos a tener que definir las entidades van a estar participando de la misma. Por ejemplo, si sabemos que tenemos usuarios vamos a entender que puede haber una tabla o collection llamada “users”.

En el caso de Coder-Box, sabemos que las entidades principales van a ser las personas y los recursos, esto nos va a dar la pauta de cuál puede ser el modelo (conjunto de tablas/collection y datos) y sus relaciones, y la forma en la que debemos programar nuestra API.

Ejemplo de collection ultrasimple:


¿Cómo saber qué campos deben tener nuestras entidades?

Según el proyecto podemos encontrarnos con entidades más concretas y otras veces el proceso de identificarlas conlleva un poco más de análisis y visión a futuro (teniendo en cuenta la escalabilidad de nuestro proyecto y que puedan agregarse nuevas funcionalidades o elementos).

A veces las entidades pueden tener diferentes nombres en la interfaz gráfica y en la base de datos. Mientras en la interfaz se busca que sea intuitivo para el usuario, en la base de datos se busca un nombre que dé una definición más pura. Esto es importante porque el nombre de esa entidad nos puede facilitar la detección de los campos necesarios para la misma.

En el caso de Coder-Box las llamamos “recursos” y cuentan con los siguientes campos: título, link, descripción, owner (usuario que lo publicó).


¿Cómo guardar los recursos favoritos de un usuario?

Podríamos pensar que basta con guardar cada recurso que el usuario elige dentro de una lista en un campo de ese “objeto” user, pero no, eso podría hacer que eventualmente la entidad user pese demasiado y nos de problemas en cada llamada a la API.

Entonces, ¿cómo podemos hacerlo?, Marce nos propuso como solución la creación de otra collection en la base de datos que guarde una relación entre el ID del usuario y los recursos guardados en favoritos.

Para finalizar

Estos son algunos de los puntos principales que estuvimos tratando en el vivo de Coder-Box, si queres escuchar la charla y aprender más del proceso, pasate por el video.

Igualmente vamos a estar desarrollando cada punto a medida que vayamos codeando el proyecto en vivo. Acordate de estar atento si queres participar, que vamos a estar abriendo PRs para que puedas mandarnos tu código y ser parte del proyecto.

En el próximo capítulo Flor nos va a contar sobre el proceso de diseño UI de coder y nos va a mostrar cosas muy importantes para que apliques a tus propios proyectos, por ejemplo: cómo crear tu propio moodboard, cómo elegir las tipografías y colores de tu web, cómo pensar tu diseño a partir de componentes y muchas cosas más. ¡No te lo pierdas!