Express et Koa de TJ Holowaychuk : backends Node minimalistes

Pourquoi les frameworks de TJ Holowaychuk comptent encore

TJ Holowaychuk est l'un des bâtisseurs précoces les plus influents de la communauté Node.js. Il a créé Express, popularisé des patterns qui ont façonné la manière d'écrire des apps web Node, puis a introduit Koa pour repenser ce que devrait être le cœur d'un framework web.

Même si vous n'avez jamais utilisé son code directement, vous avez presque certainement ressenti son impact : de nombreux frameworks Node.js, tutoriels et backends de production ont hérité d'idées qu'Express et Koa ont rendues courantes.

Fondations minimalistes (en clair)

Express et Koa sont « minimalistes » d'une façon précise : ils n'essaient pas de prendre chaque décision à votre place. Plutôt que de livrer un ensemble complet d'opinions — authentification, règles de base de données, jobs asynchrones, panneaux d'administration — ils se concentrent sur un noyau réduit et fiable pour traiter les requêtes et réponses HTTP.

Pensez-y comme une boîte à outils bien conçue plutôt qu'une maison entièrement meublée. Le framework vous donne un endroit clair pour brancher des fonctionnalités (routage, validation, cookies, sessions), mais c'est vous qui décidez des pièces nécessaires et de leur agencement.

Ce que vous apprendrez dans cet article

Ce billet est une visite pratique de ce qui a rendu Express et Koa durables :

• Les concepts clés derrière leur conception, notamment le pattern middleware.
• Les compromis d'un cœur minimal : flexibilité et clarté, mais aussi plus de choix et de responsabilités.
• Comment Express et Koa diffèrent dans des projets réels (structure, flux de contrôle, conventions).
• Quand un backend minimaliste est un bon choix — et quand préférer un framework Node plus « batteries-incluses ».

À la fin, vous devriez pouvoir évaluer les besoins d'un projet (taille de l'équipe, complexité, maintenance long terme) et choisir une approche avec moins de surprises.

L'ère web early de Node.js et le besoin de simplicité

Node.js a changé la façon dont beaucoup d'équipes percevaient le développement backend. Plutôt que d'alterner entre JavaScript dans le navigateur et un autre langage côté serveur, on pouvait tout construire dans un seul langage, partager des modèles mentaux et passer rapidement de l'idée à un endpoint fonctionnel.

Cela a rendu le développement non seulement plus rapide, mais aussi plus accessible. Un développeur orienté frontend pouvait lire le code serveur sans apprendre tout un nouvel écosystème, et les petites équipes pouvaient livrer des prototypes et des outils internes avec moins d'échanges.

Ce que Node a rendu possible

Le modèle événementiel de Node et son écosystème de paquets (npm) ont favorisé l'itération rapide. On pouvait démarrer avec un petit serveur, ajouter une dépendance à la fois et faire grandir les fonctionnalités au fur et à mesure que les besoins réels apparaissaient.

Mais Node early exposait aussi une lacune : le module HTTP intégré était puissant, mais très bas niveau. Gérer le routage, parser les corps de requêtes, les cookies, les sessions et les réponses d'erreur revenait à réécrire la même plomberie dans chaque projet.

Le besoin initial : un framework compréhensible en une après‑midi

Les développeurs ne voulaient pas d'un framework lourd « tout inclus ». Ils cherchaient un moyen simple de :

• mapper les URLs au code (routage)
• uniformiser le comportement requête/réponse
• ajouter des fonctionnalités communes sans copier-coller du boilerplate

L'outil idéal était assez petit pour être appris vite, mais assez structuré pour empêcher chaque app de devenir un imbroglio de handlers isolés.

Où Express s'insère

Express est arrivé au bon moment avec un noyau réduit et des conventions claires. Il offrait aux équipes un endroit simple pour placer routes et middlewares, sans imposer une architecture complexe dès le départ.

Tout aussi important, Express n'a pas cherché à tout résoudre. En restant minimal, il a laissé la place à la communauté pour construire les parties « optionnelles » sous forme d'extensions — stratégies d'auth, helpers de validation, logging, templating, et plus tard des outils orientés API.

Ce choix de conception a aidé Express à devenir un point de départ courant pour d'innombrables backends Node, des projets du week-end aux services en production.

Express en une page : ce que c'est et ce que ça fait

Express est un framework web léger pour Node.js. Considérez‑le comme une fine couche qui vous aide à accepter des requêtes HTTP (comme GET /products) et renvoyer des réponses (JSON, HTML, redirection), sans vous forcer dans une structure lourde et opinionnée.

Il n'essaie pas de définir toute votre application. Il vous fournit quelques blocs de base — un objet app, du routage, et des middlewares — pour que vous puissiez assembler exactement le serveur dont vous avez besoin.

Notions de routage : des URLs aux handlers

Au centre d'Express se trouve le routage : mapper une méthode HTTP et un chemin à une fonction.

Un handler est simplement du code qui s'exécute quand une requête correspond. Par exemple, vous pouvez dire : quand quelqu'un fait GET /health, exécutez une fonction qui renvoie « ok ». Pour POST /login, exécutez une autre fonction qui vérifie les identifiants et définit un cookie.

Cette approche « mapper des routes à des fonctions » est simple à raisonner parce qu'on peut lire le serveur comme une table des matières : voici les endpoints, voici ce que fait chacun.

Cycle de vie requête/réponse (sans jargon)

Quand une requête arrive, Express vous donne principalement deux objets :

• Request : ce que le client a envoyé (URL, headers, body, cookies)
• Response : ce que vous allez renvoyer (code de statut, headers, corps)

Votre travail est d'examiner la requête, décider de l'action, et terminer en envoyant une réponse. Si vous n'en envoyez pas, le client attend.

Entre les deux, Express peut exécuter une chaîne d'aides (middlewares) : logging, parsing JSON, vérification d'auth, gestion d'erreurs, etc. Chaque étape peut faire un travail puis céder la main à la suivante.

Pourquoi Express paraissait abordable

Express est devenu populaire parce que sa surface est petite : quelques concepts suffisent pour obtenir une API fonctionnelle rapidement. Les conventions sont claires (routes, middleware, req/res) et on peut commencer simple — un fichier, quelques routes — puis organiser en dossiers/modules à mesure que le projet grandit.

Cette sensation « commencer petit, évoluer au besoin » explique en grande partie pourquoi Express est devenu le choix par défaut pour tant de backends Node.

Le pattern middleware : la vraie fondation

Express et Koa sont souvent décrits comme « minimaux », mais leur véritable apport est une manière de penser : le middleware. Le middleware considère une requête web comme une série de petites étapes qui la transforment, l'enrichissent ou la rejettent avant qu'une réponse ne soit renvoyée.

Middleware comme « petites étapes »

Plutôt que d'avoir un seul handler énorme qui fait tout, on construit une chaîne de fonctions ciblées. Chacune a un travail unique — ajouter du contexte, valider quelque chose, gérer un cas limite — puis transmet le contrôle. L'app devient un pipeline : requête entrant, réponse sortante.

Ce que fait généralement le middleware

La plupart des backends en production reposent sur un ensemble familier d'étapes :

• Logging (méthode, chemin, temps, codes de statut)
• Authentification/autorisation (qui est l'utilisateur, que peut-il faire)
• Parsing JSON et formulaires (transformer des octets bruts en données exploitables)
• Gestion d'erreur (intercepter les échecs et construire des réponses cohérentes)

C'est pourquoi des frameworks « minimaux » peuvent malgré tout alimenter des APIs sérieuses : on ajoute uniquement les comportements nécessaires, dans l'ordre voulu.

Pourquoi le modèle scale dans de vraies équipes

Le middleware scale parce qu'il encourage la composition mix-and-match. Quand les besoins changent — nouvelle stratégie d'auth, validation plus stricte, logging différent — on peut remplacer une étape plutôt que de réécrire l'app.

Il facilite aussi le partage de patterns entre services : « toutes les API ont ces cinq middlewares » devient une norme d'équipe.

Autre point important, le middleware façonne le style de code et la structure des dossiers. Les équipes organisent souvent par couches (par ex. /middleware, /routes, /controllers) ou par fonctionnalités (chaque dossier de fonctionnalité contient sa route + middlewares). Dans tous les cas, la frontière middleware pousse vers des unités petites, testables et une circulation cohérente que les nouveaux développeurs apprennent vite.

L'objectif de Koa : un cœur plus mince et un flux de contrôle plus clair

Koa est la seconde tentative de TJ Holowaychuk pour un framework web Node minimal. Il a été créé après qu'Express a démontré que le modèle « cœur réduit + middleware » pouvait servir des apps en production — mais aussi après que certaines contraintes de conception initiales sont devenues visibles.

Pourquoi Koa a été créé

Express a grandi à une époque où les APIs callback-heavy étaient la norme et où l'ergonomie venait souvent d'aides pratiques incluses dans le framework.

Koa visait à faire un pas en arrière et à rendre le cœur encore plus petit, laissant davantage de décisions à l'application. Le résultat est un framework qui ressemble moins à une boîte à outils fournie et plus à une fondation propre.

Koa évite délibérément d'expédier beaucoup de fonctionnalités « standards » (routage, parsing de corps, templating). Ce n'est pas une omission accidentelle — c'est une incitation à choisir des briques explicites pour chaque projet.

Flux de contrôle plus clair avec async/await

L'une des améliorations pratiques de Koa est la façon dont il modélise le flux des requêtes. Conceptuellement, au lieu d'imbrication de callbacks pour « passer le contrôle », Koa encourage des middlewares qui peuvent suspendre et reprendre le travail :

• exécuter du code avant de céder au middleware suivant
• await le travail en aval
• exécuter du code après qu'il soit terminé (idéal pour logging, timing, gestion d'erreur)

Ceci facilite la compréhension de « ce qui se passe avant et après » un handler, sans gymnastique mentale.

Ce qui reste identique

Koa conserve la philosophie qui a rendu Express efficace :

• la composition par middleware reste l'abstraction principale
• le framework reste minimal, centré sur les bases de la couche HTTP
• l'écosystème comble le reste

Koa n'est donc pas « Express mais plus moderne ». C'est l'idée minimaliste d'Express poussée plus loin : un cœur plus fin et une manière plus structurée de contrôler le cycle de la requête.

Express vs Koa : différences pratiques pour des projets réels

Express et Koa partagent le même ADN minimaliste, mais ils donnent une sensation très différente quand on construit quelque chose de non trivial. La différence clé n'est pas « nouveau vs vieux » : c'est la quantité de structure que chaque framework fournit par défaut.

Courbe d'apprentissage : démarrage rapide vs « apportez vos propres pièces »

Express est facile à prendre en main car il propose un modèle mental familier : définir des routes, attacher des middlewares, envoyer une réponse. La plupart des tutoriels et exemples se ressemblent, donc les nouveaux membres d'équipe deviennent productifs vite.

Koa est plus simple au cœur, mais cela signifie aussi que vous assemblez plus de choses vous‑même. L'approche async/await peut sembler plus propre, mais vous prendrez plus de décisions initiales (routage, validation, style de gestion d'erreur) avant que l'app ait l'air « complète ».

Taille de la communauté et attentes « batteries incluses »

Express a une communauté plus large, davantage d'extraits copiables et plus de façons « standards » de faire des tâches courantes. Beaucoup de bibliothèques partent du principe des conventions Express.

L'écosystème Koa est sain, mais il attend que vous choisissiez vos modules préférés. C'est excellent quand vous voulez du contrôle, mais cela peut ralentir des équipes qui veulent une stack évidente.

Cas d'utilisation typiques

Express convient :

• aux petites APIs et prototypes où la vitesse de développement compte
• aux services en production où l'on veut faciliter l'embauche et l'onboarding
• aux apps qui profitent du volume de middleware et d'exemples existants

Koa convient :

• aux services où l'on veut une fondation plus fine et des briques choisies avec soin
• aux équipes qui tiennent à un flux async cohérent et une propagation d'erreur plus propre
• aux APIs internes où l'on peut standardiser ses propres conventions

Guide de décision

Choisissez Express quand le pragmatisme l'emporte : vous voulez le chemin le plus court vers un service opérationnel, des patterns prévisibles et peu de débats sur les outils.

Choisissez Koa quand vous êtes prêt à « concevoir votre framework » un peu : vous voulez un cœur propre, un contrôle serré sur la pile middleware et moins d'héritage de conventions anciennes.

Effets sur l'écosystème : pourquoi des cœurs minimaux créent de grandes communautés

Express et Koa restent petits volontairement : ils traitent le cycle requête/réponse HTTP, les bases du routage et le pipeline middleware. En n'intégrant pas toutes les fonctionnalités, ils laissent de l'espace à la communauté pour construire le reste.

Petit noyau, grande surface

Un framework minimal devient un « point d'attache » stable. Une fois que de nombreuses équipes s'appuient sur les mêmes primitives simples (objets request, signatures middleware, conventions de gestion d'erreur), il devient facile de publier des add-ons qui se greffent proprement.

C'est pourquoi Express et Koa occupent le centre d'immenses écosystèmes npm — même si les frameworks eux‑mêmes paraissent minuscules.

Catégories d'extensions courantes :

• Authentification & sessions (cookies, OAuth, helpers JWT)
• Validation & parsing (validation de schéma, uploads multipart, parseurs de corps)
• Limitation de débit & protection contre les abus (throttling IP, détection de bots, quotas)
• Documentation & outils (générateurs OpenAPI/Swagger, logging, métriques)

L'avantage : choix et flexibilité

Ce modèle « apportez vos propres briques » permet d'ajuster un backend au produit. Une API interne simple peut n'avoir besoin que de logging et d'auth, tandis qu'une API publique ajoutera validation, rate limiting, cache et observabilité.

Les cœurs minimaux facilitent l'adoption seulement de ce dont vous avez besoin, et le remplacement de composants quand les exigences évoluent.

L'inconvénient : vous gérez l'intégration

La même liberté crée des risques :

• Qualité inconsistent des paquets (maintenance, tests, pratiques de sécurité)
• Breaking changes quand un middleware populaire fait une mise à jour majeure
• Explosion des dépendances, où une app simple tire des dizaines (ou centaines) de dépendances transitives

En pratique, les écosystèmes Express/Koa récompensent les équipes qui soignent une « stack standard », épinglent les versions et audite les dépendances — car le framework ne le fera pas pour vous.

Fiabilité et sécurité : ce que les frameworks minimaux ne font pas pour vous

Express et Koa sont délibérément petits : ils routent les requêtes, aident à structurer les handlers et permettent les middlewares. C'est une force — mais cela signifie aussi qu'ils ne vous fourniront pas automatiquement les « safe defaults » que certaines personnes s'attendent à trouver dans un framework web.

Bases de sécurité à ajouter explicitement

Un backend minimal nécessite une checklist de sécurité consciente. Au minimum :

• Validation d'entrée : considérez chaque paramètre et chaque corps JSON comme non fiable. Validez types, plages, champs requis et rejetez les champs inconnus quand pertinent.
• Authentification & autorisation : le framework ne déterminera pas qui est l'utilisateur ni ce qu'il peut faire. Vous aurez besoin d'une approche claire (sessions, tokens, clés API) et de contrôles d'autorisation cohérents.
• Limitation de débit : sans elle, un client peut dégrader les performances ou forcer des endpoints. Ajoutez des limites par IP/utilisateur/token et envisagez des limites séparées pour les routes coûteuses.

Gestion des erreurs pour la fiabilité

Les erreurs sont inévitables ; l'important est la cohérence de leur traitement.

En Express, on centralise typiquement la gestion d'erreur avec un middleware d'erreur (celui à quatre arguments). En Koa, on enveloppe généralement la requête dans un try/catch près du haut de la pile et on await next().

Bonnes pratiques dans les deux environnements :

• Renvoyer des codes de statut clairs et prévisibles (400 vs 401 vs 403 vs 404 vs 500).
• Éviter de divulguer des traces de pile ou messages internes aux clients.
• Créer une forme d'erreur fiable (ex. { code, message, details }) pour que les clients n'aient pas à deviner.

Préoccupations opérationnelles : les choses « ennuyeuses » qui gardent les services en vie

Les frameworks minimaux ne configurent pas pour vous les essentiels opérationnels :

• Logging structuré (ID de requête, ID utilisateur, latence, code de statut) pour diagnostiquer les incidents.
• Health checks (ex. /health) qui vérifient les dépendances critiques comme les bases de données.
• Timeouts pour les appels en amont (HTTP, BD) afin d'éviter que les requêtes bloquées ne consomment toute la capacité.

Choisir des dépendances sans importer le risque

La plupart des problèmes de sécurité réels proviennent des paquets, pas du routeur.

Privilégiez des modules bien maintenus avec des releases récentes, une responsabilité claire et une bonne documentation. Limitez la taille de votre liste de dépendances, évitez les paquets utilitaires d'une ligne et auditez régulièrement pour les vulnérabilités connues.

Quand vous ajoutez un middleware, traitez‑le comme du code de production : relisez les valeurs par défaut, configurez‑le explicitement et maintenez‑le à jour.

Maintenir un backend minimaliste au fil de la croissance

Les frameworks minimaux comme Express et Koa facilitent le démarrage, mais ils n'imposent pas de bonnes frontières. « Maintenable » ne veut pas dire avoir le moins de lignes possible : cela signifie que la prochaine modification est prévisible.

Ce que « maintenable » devrait vouloir dire

Un backend maintenable est :

• Lisible : un nouveau collègue peut suivre une requête depuis l'entrée jusqu'à la règle métier sans deviner.
• Testable : les comportements importants peuvent être validés sans lancer tout le serveur.
• Facile à modifier : ajouter un endpoint ou changer une règle n'oblige pas à toucher des fichiers sans rapport.

Si vous ne savez pas répondre « où vivrait ce code ? », le projet dérive déjà.

Garder les chaînes de middleware compréhensibles

Le middleware est puissant, mais de longues chaînes peuvent devenir de l'« action à distance », où un header ou une réponse d'erreur est fixé loin de la route qui l'a déclenché.

Quelques habitudes pour éviter la confusion :

• Rendre chaque middleware spécifique (auth, validation, rate limiting) et nommez‑le en conséquence.
• Éviter les branchements cachés : préférez renvoyer des erreurs explicites plutôt que de passer silencieusement outre.
• Rendre l'ordre intentionnel : documentez pourquoi un middleware doit précéder un autre (surtout pour le parsing, l'auth et la gestion d'erreur).
• Utiliser une gestion d'erreur centralisée avec une forme d'erreur cohérente pour éviter que chaque route réinvente la réponse.

Dans Koa, faites particulièrement attention à l'emplacement de await next(); dans Express, soyez strict sur l'appel de next(err) vs le renvoi d'une réponse.

Structurer le projet autour des fonctionnalités, pas de la technologie

Une structure simple qui tient la route :

• /web pour les préoccupations HTTP (routes, controllers, parsing des requêtes)
• /domain pour la logique métier (services / use-cases)
• /data pour la persistance (repositories, requêtes)

Groupez le code par fonctionnalité (ex. billing, users) dans ces couches. Ainsi, « ajouter une règle de facturation » ne signifie pas fouiller dans un labyrinthe de « controllers/services/utils/misc ».

La frontière clé : le code web traduit HTTP → entrées domaine, et le domaine renvoie des résultats que la couche web traduit en HTTP.

Un mix de tests adapté aux frontières

• Tests unitaires : concentrez‑vous sur la logique métier et les cas limites (sans serveur, sans réseau).
• Tests d'intégration : testez les routes de bout en bout avec une instance d'app en mémoire, validant le comportement des middlewares, les codes de statut et les corps de réponse.

Cette séparation garde les tests rapides tout en attrapant les problèmes de wiring — exactement ce que les frameworks minimaux laissent à votre charge.

Où se situent Express et Koa parmi les frameworks Node modernes

Express et Koa restent pertinents en 2025 parce qu'ils incarnent l'extrémité « cœur réduit » du spectre des frameworks Node. Ils ne cherchent pas à définir toute votre application — seulement la couche requête/réponse HTTP — et sont souvent utilisés directement pour des APIs ou comme coquille légère autour de vos propres modules.

Comparaison avec des options plus récentes

Si vous voulez quelque chose qui rappelle Express mais est orienté performance et ergonomie plus moderne, Fastify est un choix fréquent. Il conserve l'esprit « framework minimal », mais ajoute un système de plugins plus solide, une validation orientée schéma et une approche plus opinionnée de la sérialisation.

Si vous voulez une plateforme applicative plus complète, NestJS est à l'autre extrémité : il apporte des conventions pour controllers/services, l'injection de dépendances, des modules communs et une structure de projet cohérente.

Des équipes utilisent aussi des stacks « batteries-incluses » (par ex. les routes API de Next.js) quand le backend est étroitement lié au frontend et au workflow de déploiement.

Ce que vous gagnez avec plus de structure

Les frameworks plus structurés offrent généralement :

• Des conventions claires (où placer les fichiers, comment organiser les fonctionnalités)
• Des générateurs/CLIs pour scaffolder rapidement des modules
• Des modules intégrés (patterns de validation, DI, helpers de test, parfois des intégrations auth)

Cela réduit la fatigue décisionnelle et accélère l'onboarding.

Ce que vous perdez

Le compromis est une flexibilité réduite et une surface d'apprentissage plus grande. Vous pouvez hériter de patterns que vous n'utilisez pas, et les mises à jour peuvent impliquer plus de pièces.

Avec Express ou Koa, vous choisissez exactement ce que vous ajoutez — mais vous en assumez la responsabilité.

Façon pratique de choisir

Optez pour Express/Koa quand vous avez besoin d'une API légère rapidement, qu'une équipe est à l'aise pour prendre des décisions architecturales, ou quand vous construisez un service aux exigences particulières.

Choisissez un framework plus opinionné quand les délais imposent de la cohérence, que vous prévoyez des rotations fréquentes de développeurs, ou que vous voulez une « façon standard » sur plusieurs équipes.

Conclusions : bâtir sur des fondations simples

Express et Koa perdurent parce qu'ils misent sur quelques idées durables plutôt que sur une longue liste de fonctionnalités. La contribution centrale de TJ Holowaychuk n'était pas « un autre routeur » : c'était la façon de garder le serveur petit, prévisible et facile à étendre.

Les idées qui rapportent encore

Un cœur minimal force la clarté. Quand un framework fait moins par défaut, vous prenez moins de décisions accidentelles (templating, style d'ORM, approche de validation) et pouvez vous adapter à différents produits — d'un simple webhook à une API publique plus large.

Le pattern middleware est la vraie force. En composant des petites étapes à but unique (logging, auth, parsing, rate limiting), on obtient une application qui se lit comme un pipeline. Express a popularisé cette composition ; Koa l'a affinée avec un flux de contrôle plus clair qui facilite la compréhension du « ce qui suit ».

Enfin, les extensions communautaires sont une fonctionnalité, pas un contournement. Les frameworks minimaux invitent les écosystèmes : routeurs, adaptateurs d'auth, validation, observabilité, jobs en arrière‑plan. Les meilleures équipes considèrent ces éléments comme des briques choisies volontairement, pas des add‑ons aléatoires.

Choisir — et concevoir — votre backend

Prenez le framework qui correspond aux préférences de votre équipe et au risque du projet :

• Choisissez Express si vous voulez la familiarité maximale, des exemples abondants et une voie « ça marche tout de suite » pour les services HTTP courants.
• Choisissez Koa si vous privilégiez un cœur plus fin et un contrôle plus strict du flux et de la gestion d'erreur.

Dans tous les cas, vos décisions architecturales réelles se situent au‑dessus du framework : comment vous validez les entrées, structurez les modules, gérez les erreurs et surveillez la production.

Si l'idée minimaliste vous plaît mais que vous souhaitez livrer plus vite, une plateforme vibe-coding comme Koder.ai peut compléter utilement. Décrivez une API en langage naturel, générez un scaffold web + backend fonctionnel, puis appliquez les principes Express/Koa — petites couches middleware, frontières claires, dépendances explicites — sans partir d'un dossier vide. Koder.ai propose aussi export de code, snapshots/rollback et déploiement/hosting, ce qui peut réduire la charge opérationnelle que les frameworks minimaux laissent intentionnellement à votre charge.

Lectures suivantes

Si vous planifiez un service Node, consultez d'autres guides dans /blog. Si vous évaluez des outils ou options d'accompagnement pour expédier un backend, voyez /pricing.

Checklist simple pour votre prochain service Node

• Définissez une responsabilité claire pour le service (et ce qu'il ne fera pas).
• Gardez les middlewares ciblés : une préoccupation par couche.
• Standardisez la gestion d'erreur et les formes de réponse tôt.
• Validez les entrées à la frontière (params/body), pas profondément à l'intérieur.
• Ajoutez du logging structuré et des métriques de base avant le lancement.
• Suivez les dépendances : supprimez ce que vous n'utilisez pas ; épinglez ce dont vous dépendez.
• Rédigez un petit doc « comment exécuter et déployer » pour le futur vous.