Patrones y arquitecturas enterprise en Next.js

Bueno, yo concuerdo con esto que dice Midu acá, que es que dependiendo del proyecto hay un montón. Una es por tipo, por tipo de feature, scaming architecture. Esto es como lo más básico de lo básico, ¿no? Donde tenés por tipo es como decía Crisu, por ahí tenemos una carpeta component, tenemos una carpeta hooks y tenemos carpetas para lo que sea que necesitemos. No es que tenés una estructura específica que es component hooks y si necesitas algo más te cagas, ¿no? Una carpeta por tipo de cosa. Sí,

esto es lo más básico. En realidad hay una una más básica todavía que es cuando vos tenés una aplicación muy muy sencilla. Ni siquiera tenés estas divisiones de por acá. Vos tenés un SRC y ahí adentro tenés directamente los componentes. Rara vez vas a necesitar muchos archivos más. Entonces, te puedes dar el lujo de simplemente tener un api. TS ahí en el mismo nivel que los componentes y ya está. Como eso no va a crecer mucho en estructura, no vas a necesitar mucha más organización que eso. Después tenés lo que es por por

tipo. Después tenés lo que es por tipo y feature, donde tenés básicamente lo mismo que tenés acá, pero adentro de cada una de estas entidades que vos creaste, como la de componen hooks y eso, eh agregas un nivel más denestiado, como en este caso out payment, common employees. El problema que tenemos acá es que cada una de estas entidades va a empezar a duplicar esa esa estructura. O sea, vos tenés component y tenés out, tenés hooks,

tenés out y services, tenés out y así. Estos nombres son nombres no no inventados, pero son convenciones. Ustedes como les digo, pueden optar por lo que quieran. Y después tiene la Screaming Architecture, que es algo parecido a lo que yo estoy haciendo acá en el proyecto que les voy a mostrar hoy. La única diferencia es que en vez de meterlo dentro de modules, lo tengo directamente adentro de SRC y listo. Donde tenés el nombre de las entidades

generalmente en en minúscula, por ejemplo, payment, outlo employee. Y a partir de ahí tenés components, tenés hooks, tenés lif, tenés o lo que vos decidas que sea tu estructura, pero lo tenés adentro de cada uno de los módulos. Lo que tiene de bueno esta arquitectura para mí, cuando vos tenés proyectos que son un poquito más grandes, es que cuando vos tenés que pensar dónde están las cosas, por ejemplo, quiero encontrar en mi

aplicación de gimnasio el formulario de creación de rutina. Okay, yo simplemente hago control P, pongo routine form y posiblemente lo encuentre muy rápido, lo que lo hace bastante más fácil. Cuando nosotros empezamos e con cosas así, tenemos que tener naming muy establecido para poder encontrar todo muy fácil. Y se empieza a poner un poco más complicado cuando empezamos a hacer nesting, por ejemplo, convertimos signup formup se convierte en un index.cx TX y después

tiene más componentes adentro, se empieza a volver más difícil encontrar las cosas. Sí, pero nada, yo creo que este coso que tenemos acá, chiquita, este esta imagen de Midu está está bastante buena. lo que yo generalmente uso. Y acá, bueno, tiene eh nada, un poco más de explicación y pone un coso, pone un un link a un artículo,

pero también dice al final lo importante es que no existe una sola forma buena de hacerlo, sino que dependiendo del proyecto tenés muchas opciones. Después acá Coco dice, "¿Cómo manejar rutas protegidas y públicas en X conw o con Server Components?" Eh, lo vamos a ver acá en el proyecto que que hicimos. En este caso, absolutamente toda mi aplicación es protegida. O sea, vas a tener simplemente una eh un midware que se va