boli27/itarg2

1. This repository is a single Next.js application built with the App Router and TypeScript. It combines the public website, server-rendered pages, and API endpoints in one codebase rather than splitting frontend and backend into separate services.

2. The top-level user-facing routes live under src/app/ and map to the main business areas of the site: diplomados, tecnicos, sedes, preinscripcion, transparencia, plus the home page. There are also dynamic detail pages for items identified by [id], which suggests list/detail navigation for programs, locations, and news-like content.

3. The backend/API boundary is implemented with route handlers under src/app/api/. Each domain has its own REST-style endpoints, typically a collection route and an item route: diplomados, faqs, noticias, sedes, and tecnicos. preinscripcion appears to be a write-oriented endpoint for form submissions rather than content retrieval.

4. Data access is organized separately from the route handlers in src/lib/consults/. There is one consult module per domain (Diplomados, Faqs, Noticias, Sedes, Tecnicos), which likely encapsulates fetching, querying, or shaping data before it reaches either API responses or server-rendered pages. This is the main internal boundary between transport/UI and domain data.

5. src/lib/db.ts indicates a shared database or external data source connection layer. Even without the implementation, its presence means the API and consult modules likely depend on a common persistence abstraction instead of each route talking directly to storage.

6. src/lib/validateApiKey.ts is a cross-cutting security control. It suggests at least some API endpoints are protected by an API key check, which is important for distinguishing public content endpoints from internal or privileged operations.

7. The UI is split into reusable components under src/components/. Domain-specific views live alongside shared presentation pieces: noticias, preinscripcion, sedes, tecnicos, and transparencia, plus generic UI such as NavbarMT, Footer, PageHeader, FaqAccordion, NewSlider, and WhatsappFloat. This shows the app is assembled from reusable page sections rather than monolithic page files.

8. The most important data flow is: request enters a page or API route, the route uses consult modules and possibly db.ts, data is validated or filtered, and then the result is rendered into a page component or returned as JSON. The preinscription flow is the clearest write path: form component → /api/preinscripcion → validation/persistence layer.

9. Static assets and site-wide metadata support the public site experience. public/ holds images and other assets, while manifest.ts, robots.ts, and sitemap.ts indicate SEO and PWA-oriented metadata generation are part of the architecture.

10. Styling and build tooling are standard Next.js/Tailwind choices: tailwind.config.js, postcss.config.cjs, and src/app/globals.css drive the visual system. next.config.mjs, eslint.config.mjs, and the TypeScript config files define the framework/runtime boundaries for how the app is built and checked.

11. In architectural terms, this is best drawn as a modular monolith: one Next.js deployment with three clear layers—presentation pages/components, API route handlers, and shared data-access/validation utilities—backed by a common persistence layer and static public assets.