ARQUITECTURA FRONTEND AGULAR + MATERIAL DESIGN

Requisitos:

• Npm 5.5.1
• Nodejs 8.9.1 [ https://nodejs.org/dist/v8.9.1/ ]
• Angular 5.2.0 [ npm install -g @angular/cli@1.7.4]
• Angular Cli 6.2.0

Encontrar una estructura de carpetas adecuada para mis aplicaciones con angular fue algo con lo
que he luchado durante mucho tiempo. Esto se convirtió en un problema real en mi primer proyecto
Angular en el mundo real, especialmente cuando la aplicación creció en tamaño.

Quiero aclarar que las prácticas utilizadas en este documento son muy aplicables para este proyecto,
y de ninguna manera deben seguirse estrictamente. La estructura de carpetas de un proyecto
cambiará en función de una amplia gama de factores.
|-- app
|-- modules
|-- home
|-- [+] components
|-- [+] pages
|-- home-routing.module.ts
|-- home.module.ts
|-- core
|-- [+] authentication
|-- [+] footer
|-- [+] guards
|-- [+] interceptors
|-- [+] mocks
|-- [+] services
|-- [+] header
|-- core.module.ts
|-- ensureModuleLoadedOnceGuard.ts
|-- logger.service.ts
|
|-- shared
|-- [+] components
|-- [+] directives
|-- [+] pipes
|-- [+] models
|
|-- [+] configs
|-- assets
|-- scss
|-- [+] partials
|-- _base.scss
|-- styles.scss
Módulos

|-- modules
|-- home
|-- components
|-- pages
| |-- home
| |-- home.component.ts|html|scss|spec
|
|-- home-routing.module.ts
|-- home.module.ts

En angular podemos definir cuantos módulos necesitemos, pero debemos tener en cuenta que la
forma de organizar los mismos nos ayudará a tener una mejor estructura lo que hará más fácil
nuestro trabajo.

La idea de módulos con carpetas designadas para páginas y componentes. Es perfecto para el
escalado y la lógica de componentes y páginas están separadas.

El módulo Core

El CoreModule asume el rol de AppModule raíz, pero no es el módulo que Angular arranca en tiempo
de ejecución. El CoreModule debe contener servicios singleton (que suele ser el caso), componentes
universales y otras características donde solo hay una instancia por aplicación. Para evitar volver a
importar el módulo central en otro lugar, también debe agregar una protección para él en el
constructor del módulo central.
|-- core
|-- [+] authentication
|-- [+] footer
|-- [+] guards
|-- [+] http
|-- [+] interceptors
|-- [+] mocks
|-- [+] services
|-- [+] header
|-- core.module.ts
|-- ensureModuleLoadedOnceGuard.ts
|-- logger.service.ts

La carpeta de authentication simplemente maneja el ciclo de autenticación del usuario (desde el

inicio de sesión hasta el cierre de sesión).
|-- authentication
|-- authentication.service.ts|spec.ts
Las carpetas footer y header contienen los archivos de componentes globales, utilizados
estáticamente en toda la aplicación. Estos archivos aparecerán en cada página de la aplicación.
|-- header
|-- header.component.ts|html|scss|spec.ts
|-- footer
|-- footer.component.ts|html|scss|spec.ts

la interfaz HttpInterceptor. Esto nos permite capturar y modificar las solicitudes y respuestas de
nuestras llamadas a la API. La carpeta de interceptors es una colección de interceptores que
encuentro especialmente útil.
|-- interceptors
|-- api-prefix.interceptor.ts
|-- error-handler.interceptor.ts
|-- http.token.interceptor.ts

La carpeta guards contiene todos los guards que uso para proteger diferentes rutas en nuestra
aplicación.
|-- guards
|-- auth.guard.ts
|-- no-auth-guard.ts
|-- admin-guard.ts

Los mocks son especialmente útiles para las pruebas, pero también puede usarlos para recuperar
datos ficticios hasta que se configure el back-end. La carpeta simulacros contiene todos los archivos
simulados de nuestra aplicación.
|-- mocks
|-- user.mock.ts

La carpeta services es una de las principales carpetas dentro del módulo core, ya que en el mismo
se tiene los diferentes services de llamadas a los endpoints de una o más APIs Rest.
|-- services
|-- api.service.ts|spec.ts
|-- srv1.service.ts|spec.ts
|-- srv2.service.ts|spec.ts
El módulo Shared

SharedModule es donde deben ir todos los componentes, pipes/filters y servicios compartidos.

SharedModule se puede importar en cualquier otro módulo cuando esos elementos se reutilicen. El
módulo compartido no debería depender del resto de la aplicación y, por lo tanto, no debería
depender de ningún otro módulo.
|-- shared
|-- [+] components
|-- [+] directives
|-- [+] pipes

La carpeta de componentes contiene todos los componentes “shared“. Estos son componentes
como loaders y botones, de los cuales se beneficiarían múltiples componentes.
|-- components
|-- loader
|-- loader.component.ts|html|scss|spec.ts
|-- buttons
|-- favorite-button
|-- favorite-button.component.ts|html|scss|spec.ts
|-- collapse-button
|-- collapse-button.component.ts|html|scss|spec.ts

Las carpetas de directives, pipes y models contienen las directives, pipes y modelos utilizados en la
aplicación.
|-- directives
|-- auth.directive.ts|spec.ts

|-- pipes
|-- capitalize.pipe.ts
|-- safe.pipe.ts

|-- models
|-- user.model.ts
|-- server-response.ts

Configs

La carpeta de configs contiene la configuración de la aplicación y otros valores predefinidos.

|-- configs
|-- app-settings.config.ts
|-- dt-norwegian.config.ts
Styling

Los estilos globales del proyecto deben estar ubicados en la carpeta scss siempre y cuando su
proyecto angular este basado en scss, si el proyecto está basado en css debe crearse esta carpeta,
pero siempre esta debe estar dentro de la carpeta assets que angular crea al momento de crear el
proyecto.
|-- scss
|-- partials
|-- _layout.vars.scss
|-- _responsive.partial.scss
|-- _base.scss
|-- styles.scss

Autenticado un API Rest JWT (Json Web Tokens)

Hoy en día las APIs son parte importantísima de nuestro ecosistema de desarrollo, ya que gracias a
ellas tenemos acceso a miles de millones de datos en distintas empresas u organismos, ya que nos
permiten mandar pedir información, o utilizar servicios de terceros de forma sencilla
(normalmente…).

Sin embargo, dejar expuesto un servicio que el punto es que sea bajo demanda, es decir, que para
tener acceso a este haya que pagar por petición, por mes o cosas así, nos hace que estas APIs deban
protegerse, así no cualquiera puede realizar peticiones a nuestros servicios.

Hay distintos métodos para poder dar acceso a un API, por ejemplo, la autenticación a través de
tokens y es la que veremos usando JWT.

Autenticación por tokens

Primero, ¿qué demonios es un servicio basado en autenticación por tokens?, en términos simples
es que, a través de una cadena de caracteres enviadas desde el cliente hacia nuestro API, algo así
como una “contraseña”, entonces nosotros detectamos el token y podemos revisar a qué usuario
pertenece, si es válida o no, mantener registros de peticiones, y mucho más.

¿Cómo funciona?

El funcionamiento de JWT es bastante simple y se basa en 6 pasos:

1. Autentica usando credenciales regulares (usuario-contraseña normalmente).

2. Una vez que ya autenticó en el servidor, genera una cadena de caracteres que contiene el
token de JWT integrada.
3. Ese token es enviado al cliente.
 4. El token se almacena en el lado del cliente.
5. El token se manda al lado del servidor en cada petición que se realiza.
6. El servidor valida el token y otorga (o no) acceso al recurso que el cliente solicita.

Y listo, este es el proceso a forma de texto. Aquí lo vemos a forma de diagrama:

En este caso para dar tiempo de vida a las sesiones, puede incluso llevar datos como el user_id
integrado y al obtenerlo nos pueda ahorrar una solicitud a la base de datos, o muchas otras ventajas,
pero la principal es la seguridad que nos otorgará a nuestro API.
Estructura Autenticación

roles: [‘ADMIN’],

permissions: [‘creaCaso, ‘listaCaso’, ‘informeCaso’]

Por último, quiero recalcar 3 cosas:

• Siempre se debe validar todo en back-end.

• Los permisos se recomiendan sean en “camelCase” y los roles en mayúsculas.
• Deben validar siempre la JWT para evitar que se las alteren.