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 a encargar