Amoxcalli tiene dos lados. El servidor (backend) guarda la información y aplica las reglas. Las apps (frontend) son lo que docentes y padres ven y usan, en la web y en Android. Aquí se explica cada lado en palabras simples y, debajo, con su detalle técnico.
Las apps nunca hablan directo con los datos: todo pasa por una sola puerta de entrada que reparte cada petición. Detrás hay tres sistemas, uno para cuentas, otro para pagos y otro para la escuela. Cada uno guarda su propia información, así un problema en uno no detiene a los demás.
Detalle técnico: un API Gateway con YARP enruta por prefijo a tres microservicios. Cada servicio es dueño de su base de datos; entre servicios no hay llaves foráneas, se referencian por identificador y cada transacción se queda en una sola base.
El servidor es la parte que no se ve. Guarda la información, revisa quién puede hacer qué y calcula cosas como el promedio final. Está ordenado por capas para que cada regla tenga un solo lugar.
Detalle técnico: .NET 10 con Clean Architecture. Cada microservicio tiene cuatro proyectos (Api, Application, Domain e Infrastructure) y las dependencias apuntan hacia el dominio. Lo común vive en librerías compartidas.
Toda la lectura y escritura de datos pasa por un mismo camino. Si un cambio tiene varios pasos, se guardan todos o ninguno.
IRepository<T> más repositorios específicos; las interfaces viven en DomainExecuteInTransactionAsync para operaciones de varios pasosIEntityTypeConfiguration) por entidadAl eliminar algo, se marca como eliminado en lugar de borrarlo. Así queda historial y se puede recuperar.
BaseEntity) con Id GUID, fechas de auditoría y banderas Active y DeletedCuando algo sale mal, el servidor responde siempre con el mismo formato y un mensaje entendible, que la app muestra tal cual.
Al iniciar sesión recibes un pase digital con fecha de vencimiento. Si alguien roba uno viejo y lo usa, el sistema lo detecta y cierra la sesión.
Un docente puede trabajar en varias escuelas y cambiar de una a otra sin cerrar sesión. Solo ve los datos de la escuela activa.
Cada día, sin que nadie intervenga, el servidor revisa las suscripciones y hace los cobros que tocan.
BackgroundService de facturación diaria, con la hora de MéxicoSon dos aplicaciones: una para docentes y escuelas, y otra para madres, padres y tutores. Las dos están hechas con la misma base y las mismas reglas, así que una mejora en la estructura sirve para ambas. Funcionan en el navegador y como app de Android.
Detalle técnico: dos proyectos Angular 21 hermanos, con la misma arquitectura y la misma configuración de calidad.
Cada clic recorre el mismo camino. La pantalla avisa lo que quieres hacer, un intermediario se encarga de pedirlo al servidor y, cuando llega la respuesta, la pantalla se actualiza sola. Como siempre es el mismo camino, cuando algo falla es fácil saber dónde buscar.
La app solo redibuja la parte de la pantalla que cambió, no la pantalla completa. Por eso responde rápido incluso en teléfonos sencillos.
zone.js (zoneless): la pantalla se actualiza con signalsOnPush y nueva sintaxis @if / @forEl código está dividido por temas (alumnos, asistencia, pagos…). Una herramienta revisa automáticamente que nadie rompa esa división.
core/, shared/ y features/; cada feature expone solo su archivo index.ts../../ y entrar a otro feature sin pasar por su index.tsatm-, mol-, org-, temp-)shared/ no puede depender de features ni del storeCada sección se descarga solo cuando la abres, y antes de mostrarla la app revisa que tengas permiso para verla.
canDeactivate)La app recuerda lo que ya cargó, como tus grupos o tus alumnos, para no pedirlo de nuevo. Las pantallas nunca tocan esa memoria directamente: siempre pasan por un intermediario.
createActionGroup, createFeature y effects; cada uno se registra con su rutatoSignal); una regla de ESLint impide importar el store en un componenteEl código que habla con el servidor se genera automáticamente. Si el servidor cambia algo, la app avisa antes de publicarse en lugar de fallarle al usuario.
ng-openapi-gen crea funciones y modelos a partir del Swagger de cada servicio; un script los regenera todosLos botones, campos y ventanas vienen de una librería probada, adaptada a los colores de Amoxcalli y traducida por completo al español.
ConfirmService basado en PromiseAntes de diseñar pantallas se escribió un documento con reglas comunes: cómo se crea, se edita o se borra algo. Así cada pantalla nueva se comporta igual que las demás y el usuario no tiene que aprender cada una.
Antes de llegar al usuario, el código pasa por pruebas automáticas y revisiones. Con el mismo código se publica la versión web y la app de Android.
La misma app web se empaqueta como app de Android, sin escribir otra desde cero.
CapacitorHttp), sin problemas de CORSCerca de 500 pruebas revisan en segundos que lo que ya funcionaba siga funcionando después de cada cambio.
provideMockStore, y guards con sus propias pruebasCada cambio queda registrado con un formato estándar y la web se publica con un solo comando.
Todo lo que se describe aquí funciona detrás de las dos demos.