1 Arquitecturas¶

Migración de un proyecto¶

Hasta hora en los proyectos realizados se ha utiliza el commonJS. Tal y como se vio en el Tema 1 existe dos formas de utilizar los módulos en Javascript, commonJS, la versión antigua ;y ESModules la versión actual.

Para poder crear o migrar un proyecto de Node haciendo uso del ESModules, debemos indicarlo en el package.json. El atributo type por defecto esta en commonJS, si queremos que acepte los archivos javascript como ESModules, debemos indicar dicho atributo como modules:

{
  "name": "api-rest-with-express",
  "version": "1.0.0",
  "description": "Api REST with Express",
  "main": "index.js",
  "type": "module",
  "scripts": {
    "dev": "node --watch app.js",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "irudev",
  "license": "ISC",
  "dependencies": {
    "cors": "2.8.5",
    "express": "4.18.2",
    "zod": "3.22.4"
  }
}

Una vez realizado este paso, debemos importar las librerías haciendo uso de la estructura import a from path donde a son los elementos que se importan del path. Observa en el siguiente ejemplo a comparación de require:

import fs from 'node:fs'
import {validateObject} from './validate.js'

const fs = require('node:fs')
const {validateObject} = require('./validate')

Cuando se desea importar como un archivo, como ocurre con un JSON hay que indicar el tipo de archivo, además de su extensión:

import movies from './movies.json' assert {type: 'json'}

El problema de dicha importación es que no hay un versión estable y probablemente no la haya. Por lo que, hay una nueva indicación withla cual aún no está disponible pero sí será estable:

import movies from './movies.json' with {type: 'json'}

Mientras tanto, para poder leer un JSON en Node se podría hacer de dos maneras

• Haciendo uso del módulo fs y su método readFileSync:

  const movies = JSON.parse(fs.readFileSync('./movies.json', 'uft-8'))
  

• Creando nuestro propio require. El require usado en commonJS es una función que recibe el path de la librería, por lo que aunque no podamos usar el require de commonJS podemos crear el nuestro propio para recibir el una path compatible con ESModule, haciendo uso del método createRequire del módulo nativo module de Node:

  import {createRequire} from 'node:module'
  const require = createRequire(import.meta.url)
  
  const movies = require('./movies.json')
  

  Incluso dicha creación puede ser exportado y reutilizado en cualquier archivo javascript de nuestro proyecto.

Arquitecturas de un proyecto¶

Cuando creamos un proyecto es conveniente estructurar nuestro proyecto de manera que podamos separar conceptos. Esto consigue que nuestro proyecto sea más eficiente y escalable.

Una arquitectura estándar para un proyecto en Node, que hayamos podido realizar hasta ahora, podría ser la siguiente:

project/
    |_ node_modules/
    |_ src/
        |_ middlewares/
        |_ utils/
        |_ schemas/

La estructura anterior define una carpeta para nuestros middlewares, que contendrá los middlewares que usemos en nuestra aplicación, utils que contendrá los archivos javascript que sirvan de utilidad, y schemas que define los schemas de los tipos de datos a usar.

Patrones de arquitectura y de diseño¶

Un patrón de arquitectura es una solución a un problema común de diseño de software que es reutilizable. Los patrones de arquitectura se centran en el nivel más alto de abstracción del diseño de software, proporcionando una visión general de cómo se relacionan los componentes de un sistema.

Algunos ejemplos de patrones de arquitectura incluyen:

• Arquitectura cliente-servidor: Este patrón divide un sistema en dos componentes principales: un cliente que solicita servicios a un servidor.
• Arquitectura de tres capas: Este patrón divide un sistema en tres capas: presentación, lógica de negocio y datos.
• Arquitectura orientada a servicios: Este patrón divide un sistema en un conjunto de servicios independientes que pueden comunicarse entre sí.

Un patrón de diseño es una solución a un problema común de implementación de software que es reutilizable. Los patrones de diseño se centran en el nivel de abstracción más bajo del diseño de software, proporcionando detalles sobre cómo implementar un componente o subsistema de un sistema.

Algunos ejemplos de patrones de diseño incluyen:

• Patrón singleton: Este patrón asegura que solo exista una instancia de una clase en un momento dado.
• Patrón decorador: Este patrón permite agregar funcionalidad a un objeto sin modificar su código.
• Patrón adaptador: Este patrón permite que dos clases incompatibles se comuniquen entre sí.

La principal diferencia entre patrones de arquitectura y patrones de diseño es el nivel de abstracción en el que operan. Los patrones de arquitectura se centran en el nivel más alto de abstracción, proporcionando una visión general de cómo se relacionan los componentes de un sistema. Los patrones de diseño, por otro lado, se centran en el nivel de abstracción más bajo, proporcionando detalles sobre cómo implementar un componente o subsistema de un sistema.

Otra diferencia entre patrones de arquitectura y patrones de diseño es su alcance. Los patrones de arquitectura suelen ser aplicables a una amplia gama de sistemas, mientras que los patrones de diseño suelen ser más específicos para un tipo particular de sistema o aplicación.

Finalmente, los patrones de arquitectura suelen ser más difíciles de aplicar que los patrones de diseño. Esto se debe a que los patrones de arquitectura suelen implicar cambios en la estructura de un sistema, mientras que los patrones de diseño suelen implicar cambios en la implementación de un componente o subsistema.