Express es bastante popular, y ciertamente puedes escribir una API bastante buena con el marco. Sin embargo, sugeriría encarecidamente Hapi.js por dos razones:
1. Mejor estructura de aplicación.
Express usa el middleware Connect para extender la canalización de solicitudes para manejar cosas como la autenticación, el filtrado, etc. Además de eso, tiene una estructura bastante flexible, lo que le brinda mucha flexibilidad, pero también puede ser una molestia en el culo. a largo plazo (cuando aprendes de todos tus errores).
- ¿Qué tecnologías y en qué orden debo aprender a convertirme en un desarrollador web de pila completa? Apreciaré escuchar sobre algunos libros y recursos para aprender.
- ¿Edge es un "buen" navegador?
- ¿Por qué PHP y sus marcos y paquetes asociados se consideran defectuosos en comparación con otros marcos como node.js?
- ¿Por qué usamos un concepto de token en PHP?
- Cómo transferir archivos del sitio web con FileZilla
Hapi.js es significativamente más testarudo sobre cómo debe estructurarse su aplicación, y esas opiniones fueron formadas por personas increíblemente inteligentes (estoy bastante seguro de que comprenderá la brillantez de esas decisiones cuando comience a usarla). Algunas de las características estructurales más significativas son:
Complementos
Los complementos en Hapi.js representan un paquete de funcionalidades. No solo se utilizan para utilidades como la autenticación, sino también para modularizar sus propias rutas o vincular servicios al servidor. Otro beneficio es que los complementos se registran en el servidor antes de que el servidor se inicialice, y el servidor no está disponible para solicitudes hasta que se hayan inicializado todos los complementos (llamando a la devolución de llamada).
La definición de complementos es súper fácil:
module.exports.register = (servidor, opciones, siguiente) => {
server.route ({
método: ‘OBTENER’,
ruta: ‘/ ping’,
manejador: función (solicitud, respuesta) {
respuesta (‘pong);
}
});
siguiente();
};
module.exports.register.attributes = {
nombre: ‘ELB Health Route’,
versión: ‘1.0.0’
};
Y luego lo registras así:
server.register ([{
registrarse: require (‘módulo de salud’),
opciones: config
}], (err) => {
server.start (() => {
server.log (
[‘info’],
`Servidor que se ejecuta en: $ {server.info.uri}`);
});
});
Nota: es una variedad de módulos para registrar, que incluirá complementos de la comunidad, sus módulos, etc.
Manejadores + Metadatos
Otra cosa que realmente me gusta de Hapi es que coloca metadatos de ruta con el controlador. Entonces, cuando desee agregar cosas como “roles” válidos para una ruta, validación de parámetro / consulta / cuerpo de solicitud, etc., está allí (no está bloqueado en algunos middleware de Connect, dios sabe en qué parte de su aplicación). Además, es una configuración hermosa y declarativa, no una función en una cadena de controladores.
Aquí hay un ejemplo de la documentación de Hapi.js sobre cómo configurar el almacenamiento en caché para una ruta individual:
server.route ({
ruta: ‘/ hapi / {ttl?}’,
método: ‘OBTENER’,
manejador: función (solicitud, respuesta) {
respuesta constante = respuesta ({be: ‘hapi’});
if (request.params.ttl) {
response.ttl (request.params.ttl);
}
},
config: {
caché: {
expira en: 30 * 1000,
privacidad: ‘privado’
}
}
});
Métodos de servidor
Finalmente, me gustaría tocar algo que es un problema universal que he visto con los proyectos Node: la gestión de dependencias . Muchos marcos, como Express, te dejan esto para que lo resuelvas. Por lo general, verá que muchos proyectos de Nodo importan sus dependencias directamente en sus módulos (lo que hace que sea muy difícil realizar una prueba unitaria) o construirán un gráfico de objetos en el módulo raíz (por ejemplo, index.js) y escribirán submódulos como funciones que se invocarán con dependencias cuando se importen.
Hapi tiene una mejor estrategia y se llaman métodos de servidor . Básicamente, son una forma de agregar funcionalidad al objeto Servidor , pero de una manera aprobada / segura:
server.method (‘lookupUser’, (userId, callback) => {
db.lookup (userId, (err, user) => {
si (err)
server.log ([‘error’], `No se pudo buscar usuario: $ {err}`);
devolución de llamada (err, usuario);
});
}, {});
Y para llamar a este método:
// ¡Buenos manejadores de respuestas!
let Boom = require (‘boom’);
server.route ({
método: ‘OBTENER’,
ruta: ‘/ user / {userId}’,
manejador: función (solicitud, respuesta) {
server.methods.lookupUser (
request.params.userId, (err, user) => {
si (err)
return reply (Boom.badImplementation (‘¡Uy!’, err));
responder (usuario);
});
}
});
Si bien no es una inyección de dependencias (una especie de patrón de localizador de servicios), es significativamente mejor que las dependencias de codificación en los controladores de su enrutador. Lo bueno es que puede empaquetar estas dependencias en un complemento e intercambiarlas con cosas como “simulacros” si desea probar unitariamente sus controladores.
2. Menos ruido .
Hay menos módulos y extensiones en Hapi que Express, pero la mayoría son de muy alta calidad. Por lo tanto, no se enfrenta a una abrumadora cantidad de opciones. Además, la comunidad Hapi, que en realidad es bastante grande, ha demostrado mucha moderación al mejorar los complementos que existen en lugar de crear sus propias versiones de cosas.
