C'est une grande question et nécessite une longue réponse pour être complète, donc je vais simplement aborder un sous-ensemble des différences les plus importantes. Toutes mes excuses, c'est encore une longue réponse.
En quoi sont-ils similaires?
Vous avez absolument raison quand vous dites:
Pour des exemples de base, ils semblent similaires
Les deux frameworks résolvent le même problème de base: fournir une API pratique pour créer des serveurs HTTP dans le nœud. C'est-à-dire plus pratique que d'utiliser httpseul le module natif de niveau inférieur . Le httpmodule peut faire tout ce que nous voulons mais c'est fastidieux d'écrire des applications avec.
Pour ce faire, ils utilisent tous les deux des concepts qui existent depuis longtemps dans les frameworks Web de haut niveau: routage, gestionnaires, plugins, modules d'authentification. Ils n'ont peut-être pas toujours eu les mêmes noms, mais ils sont à peu près équivalents.
La plupart des exemples de base ressemblent à ceci:
- Créer un itinéraire
- Exécuter une fonction lorsque l'itinéraire est demandé, préparer la réponse
- Répondre à la demande
Express:
app.get('/', function (req, res) {
getSomeValue(function (obj) {
res.json({an: 'object'});
});
});
hapi:
server.route({
method: 'GET',
path: '/',
handler: function (request, reply) {
getSomeValue(function (obj) {
reply(obj);
});
}
});
La différence n'est pas vraiment révolutionnaire ici, non? Alors pourquoi choisir l'un plutôt que l'autre?
Comment sont-ils différents?
La réponse simple est que hapi est beaucoup plus et il fait beaucoup plus prêt à l'emploi. Cela peut ne pas être clair si vous regardez simplement l'exemple ci-dessus. En fait, c'est intentionnel. Les cas simples restent simples. Examinons donc quelques-unes des grandes différences:
Philosophie
Express est conçu pour être très minimal. En vous donnant une petite API avec juste une fine couche de poussière en plus http, vous êtes toujours très seul en termes d'ajout de fonctionnalités supplémentaires. Si vous souhaitez lire le corps d'une requête entrante (tâche assez courante), vous devez installer un module séparé . Si vous vous attendez à ce que divers types de contenu soient envoyés vers cette route, vous devez également vérifier l'en- Content-typetête pour vérifier de quoi il s'agit et l'analyser en conséquence (form-data vs JSON vs multi-part par exemple), souvent en utilisant des modules séparés .
hapi dispose d'un riche ensemble de fonctionnalités, souvent exposé via des options de configuration, plutôt que d'exiger l'écriture de code. Par exemple, si nous voulons nous assurer qu'un corps de requête (charge utile) est entièrement lu en mémoire et correctement analysé (automatiquement en fonction du type de contenu) avant que le gestionnaire ne soit exécuté, il s'agit simplement d'une option simple :
server.route({
config: {
payload: {
output: 'data',
parse: true
}
},
method: 'GET',
path: '/',
handler: function (request, reply) {
reply(request.payload);
}
});
Caractéristiques
Il vous suffit de comparer la documentation de l'API sur les deux projets pour voir que hapi offre un plus grand ensemble de fonctionnalités.
hapi inclut certaines des fonctionnalités intégrées suivantes qu'Express ne propose pas (pour autant que je sache):
Extensibilité et modularité
hapi et Express abordent l'extensibilité d'une manière tout à fait différente. Avec Express, vous disposez de fonctions middleware . Les fonctions middleware sont un peu comme des filtres que vous empilez et toutes les requêtes les traversent avant de toucher votre gestionnaire.
hapi a le cycle de vie de la requête et offre des points d'extension , qui sont comparables aux fonctions middleware mais existent à plusieurs points définis dans le cycle de vie de la requête.
L'une des raisons pour lesquelles Walmart a créé hapi et a cessé d'utiliser Express était la frustration de la difficulté à diviser une application Express en plusieurs parties et à faire travailler différents membres de l'équipe en toute sécurité sur leur partie. Pour cette raison, ils ont créé le système de plugins dans hapi.
Un plugin est comme une sous-application, vous pouvez faire tout ce que vous pouvez dans une application hapi, ajouter des itinéraires, des points d'extensions etc. Dans un plugin, vous pouvez être sûr que vous ne cassez pas une autre partie de l'application, car l'ordre de les enregistrements d'itinéraires n'ont pas d'importance et vous ne pouvez pas créer d'itinéraires conflictuels. Vous pouvez ensuite combiner ces plugins dans un serveur et le déployer.
Écosystème
Parce qu'Express vous donne si peu de choses hors de la boîte, vous devez regarder à l'extérieur lorsque vous avez besoin d'ajouter quelque chose à votre projet. La plupart du temps, lorsque vous travaillez avec hapi, la fonctionnalité dont vous avez besoin est soit intégrée, soit un module créé par l'équipe principale.
Minimal sonne bien. Mais si vous créez une application de production sérieuse, il y a de fortes chances que vous ayez besoin de tout cela par la suite.
Sécurité
hapi a été conçu par l'équipe de Walmart pour gérer le trafic du Black Friday, de sorte que la sécurité et la stabilité ont toujours été une préoccupation majeure. Pour cette raison, le framework fait beaucoup de choses supplémentaires, comme limiter la taille de la charge utile entrante pour éviter d'épuiser la mémoire de votre processus. Il a également des options pour des choses comme le délai maximal de boucle d'événements, la mémoire RSS maximale utilisée et la taille maximale du tas v8, au-delà de laquelle votre serveur répondra avec un délai d'expiration de 503 plutôt que de simplement planter.
Résumé
Évaluez-les tous les deux vous-même. Pensez à vos besoins et lequel des deux répond à vos plus grandes préoccupations. Faites un plongeon dans les deux communautés (IRC, Gitter, Github), voyez laquelle vous préférez. Ne me croyez pas sur parole. Et bon piratage!
DISCLAIMER: Je suis partial en tant qu'auteur d'un livre sur hapi et ce qui précède est en grande partie mon opinion personnelle.