¿Cómo defines la estructura inicial de datos cuando construyes una API con Laravel? Aquí aprendes a crear migraciones, modelos y factories para montar las tablas base de un proyecto, con relaciones uno a muchos y muchos a muchos. Es contenido ideal para desarrolladores backend que quieren aplicar buenas prácticas sin importar el framework.

Todo arranca desde el terminal de Visual Studio Code, porque sin una base de datos y tablas bien pensadas no hay nada que practicar. Antes de escribir una sola línea, conviene verificar las versiones de las herramientas, y aquí viene lo interesante: Laravel es tan flexible que puedes usar otra tecnología de base de datos sin problema.

Qué versiones necesitas para seguir el proyecto

El entorno de trabajo usa versiones específicas que puedes igualar o superar sin complicaciones. La recomendación es mantenerte cerca de estas referencias para evitar incompatibilidades.

• PHP 8.2.6 como motor del proyecto [00:48].
• Composer 2.5.7 para gestionar dependencias [01:02].
• MariaDB como base de datos, verificada con mariadb -v [01:10].

La instalación del proyecto se hace desde la carpeta de sitios con el comando laravel new laravel-api [01:40]. A partir de ahí, todo el trabajo ocurre en el terminal y en dos carpetas clave: la de migraciones y la de modelos.

¿Qué es una migración en Laravel? Es un archivo donde defines la estructura inicial de tus tablas usando código PHP. Cada migración describe campos, tipos de datos y relaciones que luego se traducen en tablas reales de tu base de datos.

Cómo generar modelos, migraciones y factories con un solo comando

Laravel incluye el comando php artisan que muestra todos los comandos disponibles. El protagonista aquí es la familia make, que permite crear archivos base rápidamente.

Para crear la entidad de categoría junto con su migración y su factory, se usa php artisan make:model con opciones adicionales [03:18]. Con un solo comando se generan tres archivos:

• La entidad modelo, que representa la tabla en el código.
• El factory, útil para generar datos de prueba.
• La migración, donde desarrollas la estructura de la tabla.

Qué campos lleva cada tabla del proyecto

La estructura de datos del curso parte de una lógica clara: una categoría tiene muchas recetas, y una receta puede tener muchas etiquetas. Esto define las dos relaciones centrales del proyecto.

La migración de categorías ya incluye por defecto el id, la fecha de creación y la de actualización. Solo necesitas agregar un campo adicional del tipo string llamado name [05:10]. La tabla de etiquetas usa exactamente la misma estructura.

La tabla de recetas es la más completa. Sus campos son:

• category_id del tipo entero sin signo, con relación foránea a categories [05:55].
• user_id con relación foránea a users, para registrar quién creó la receta [07:00].
• title del tipo string [07:30].
• description del tipo text [07:40].
• ingredients, instruction e image, siendo la imagen un campo opcional [08:05].

¿Qué hace un efecto en cascada en una relación foránea? Significa que al eliminar un registro padre, sus registros relacionados también se eliminan. Si borras un usuario, todas sus recetas desaparecen automáticamente con onDelete cascade.

Cómo defines la relación muchos a muchos entre recetas y etiquetas

Las relaciones uno a muchos ya quedan cubiertas: un usuario tiene muchas recetas y una categoría tiene muchas recetas. Para la relación muchos a muchos necesitas una tabla intermedia o pivote.

Esta tabla se crea con php artisan make:migration apuntando a la unión de recetas y etiquetas [09:15]. Y aquí hay un detalle de convención que marca la diferencia entre un proyecto ordenado y uno confuso.

Por qué el nombre de la tabla pivote va en singular y orden alfabético

El estándar de Laravel pide que el nombre de la tabla intermedia combine los nombres de las tablas relacionadas en singular y en orden alfabético [09:40]. Mientras las tablas normales como categories o recipes van en plural, la tabla pivote sigue esta regla distinta.

Dentro de esta tabla intermedia solo guardas dos campos:

• El id de la receta con su relación foránea.
• El id de la etiqueta con su relación foránea.

Un detalle práctico: en esta tabla muchos a muchos se eliminan las columnas de fecha con timestamps, porque no aportan valor en una relación pivote [10:50]. Las tablas principales sí mantienen esa línea para registrar creación y actualización automáticamente.

El resultado son cuatro migraciones que forman la columna vertebral del proyecto: categorías, recetas, etiquetas y la tabla que une recetas con etiquetas. Con esto queda lista la base para una API profesional.

Ahora te toca a ti. Realiza esta práctica y cuéntame en los comentarios si estás trabajando con otro framework, porque cualquier herramienta profesional comparte esta misma lógica de estructura de datos.