Gravitee.io : pourquoi j'ai choisi cette API Gateway open source

Vous avez une application mobile utilisée par des milliers d’utilisateurs. Derrière, un monolithe Symfony qui expose une API. La moindre coupure est impensable.

Maintenant, imaginez que vous devez changer le moteur de recherche, migrer une brique technique, ou remplacer un service consommé par le web, le mobile et trois autres APIs.

Sans point d’entrée centralisé, chaque changement devient un exercice de coordination millimétrée. C’est faisable, mais le risque d’erreur est proportionnel au nombre de consommateurs.

C’est exactement le problème qu’une API Gateway résout.

Le problème : des flux invisibles et incontrôlables

Prenons trois situations concrètes que j’ai rencontrées ou accompagnées.

Cas 1 - Le monolithe critique. Une API Symfony qui alimente une application mobile, un site web et des bornes IoT. Des milliers d’appels par minute. Aucune visibilité sur qui consomme quoi, à quelle fréquence, avec quel temps de réponse.

Cas 2 - L’archipel de microservices. 5, 10, 15 APIs qui communiquent entre elles. Chacune a ses propres logs, son propre format d’erreur, sa propre gestion de l’authentification. Quand un appel échoue, bonne chance pour remonter la chaîne.

Cas 3 - Les deux en même temps. Un monolithe historique qu’on découpe progressivement en services, avec des consommateurs externes qui ne doivent rien voir de la transition.

Dans les trois cas, les mêmes questions reviennent :

• Quel endpoint est le plus lent ?
• Quel consommateur génère le plus de trafic ?
• Comment couper proprement l’accès à une ancienne API sans casser les clients ?
• Comment appliquer du rate limiting sans modifier chaque backend ?

Sans API Gateway, ces questions restent souvent sans réponse. Ou pire : on bricole des solutions dans chaque service, avec des comportements incohérents.

Qu’est-ce qu’une API Gateway ?

Une API Gateway est un reverse proxy spécialisé qui se place en frontal de vos APIs. Tous les appels transitent par elle avant d’atteindre les services backend.

Concrètement, elle centralise :

• Le routage : une URL publique unique, redirigée vers le bon service backend. Vous pouvez changer le backend sans que le consommateur ne s’en aperçoive.
• L’authentification : API key, OAuth2, JWT (JSON Web Token) - gérés une seule fois au niveau de la gateway, pas dans chaque service.
• Le rate limiting : limitation du nombre d’appels par consommateur, par endpoint, par tranche de temps. Protection contre les abus et les pics non maîtrisés.
• Les policies : transformations de requêtes/réponses, cache, CORS (Cross-Origin Resource Sharing), IP filtering - le tout configurable sans toucher au code backend.
• Le monitoring : latence, volume, taux d’erreur, par endpoint et par consommateur. En temps réel.

Une API Gateway, c’est un point de contrôle unique pour tous vos flux API. Tout passe par là, donc tout est visible.

Le comparatif : Kong, KrakenD, Tyk, AWS… et Gravitee

En 2020, je cherchais une solution pour un projet chez Camping-Car Park : un monolithe Symfony exposant une API critique consommée par le web, une application mobile et des équipements IoT. Disponibilité impérative 24/7, volume de requêtes important, besoin de visibilité sur la consommation.

J’ai évalué les principales solutions du marché. Voici ce que j’en ai retenu.

Les solutions cloud managées (AWS, GCP)

AWS API Gateway et Google Cloud Endpoints sont des choix évidents si vous êtes déjà sur ces clouds. L’intégration est native, la mise en place rapide.

Le problème : le vendor lock-in. Vos règles de routage, vos policies, votre monitoring - tout est lié au provider. Et la facturation à l’appel peut devenir salée sur des volumes importants. Sur le projet en question, l’infrastructure était hébergée sur Clever Cloud et OVH, pas sur AWS ni GCP. Ces solutions étaient donc hors scope.

Kong

Kong est la référence historique du marché. Open source, basé sur Nginx et OpenResty (Lua), écosystème de plugins très riche.

Points forts :

• Maturité et stabilité éprouvées
• Grande communauté
• Performant en termes de latence ajoutée

Points faibles :

• La version Community est limitée : pas de dashboard graphique natif, pas d’analytics intégrées. Il faut assembler Kong + Konga (ou Kong Manager) + un stack de monitoring externe.
• Configuration via API REST ou fichiers YAML - pas d’interface de gestion intuitive en version gratuite.
• Les fonctionnalités avancées (RBAC, analytics, developer portal) sont réservées à la version Enterprise, payante.

KrakenD

KrakenD adopte une approche différente : c’est une gateway stateless, configurée entièrement via un fichier JSON. Pas de base de données, pas d’état interne.

Points forts :

• Performances excellentes (écrit en Go, très faible overhead)
• Configuration as code, versionnée dans Git
• Idéal pour des architectures microservices standardisées

Points faibles :

• Pas de dashboard de monitoring intégré
• Pas de gestion dynamique des APIs (chaque changement nécessite un redéploiement)
• Moins adapté si vous avez besoin de modifier les règles de routage à chaud

Tyk

Tyk est une alternative solide, écrite en Go, avec un dashboard inclus dans la version open source (contrairement à Kong).

Points forts :

• Dashboard natif en version open source
• Support de GraphQL
• Bonne documentation

Points faibles :

• L’installation est plus lourde que les autres solutions (Redis obligatoire, composants multiples)
• La version open source a des restrictions sur certaines fonctionnalités avancées
• Communauté plus restreinte que Kong ou Gravitee

Gravitee.io

Gravitee.io est une solution open source née à Lille en 2015, qui a depuis levé plusieurs millions d’euros. C’est celle que j’ai retenue, et que j’utilise en production depuis 2020.

Points forts :

• Interface de gestion complète incluse dans la version open source : dashboard, analytics, logs, configuration des APIs - tout est là, sans plugin supplémentaire
• Installation simple : Docker Compose et c’est opérationnel en quelques minutes
• Documentation solide et communauté active
• Cohérence d’ensemble : gateway, management, analytics - tout est pensé comme un produit intégré, pas comme un assemblage de briques

Points faibles :

• Moins performant que KrakenD en termes de latence brute (la gateway est en Java)
• Écosystème de plugins moins étendu que Kong
• Elasticsearch requis pour les analytics (à dimensionner correctement)

L’architecture de Gravitee.io

Gravitee se compose de quatre briques principales qui fonctionnent ensemble.

Gateway

C’est le composant central. Il reçoit les requêtes des consommateurs, applique les policies configurées (auth, rate limiting, cache, transformation…) et redirige vers le backend approprié.

La gateway est écrite en Java, basée sur Vert.x (framework réactif asynchrone). Elle gère les connexions de manière non bloquante, ce qui lui permet de supporter un volume important de requêtes concurrentes malgré la JVM.

Management API

Une API REST qui permet de gérer toute la configuration : créer des APIs, définir des plans d’accès, configurer des policies, gérer les utilisateurs. C’est le backend de l’interface d’administration.

Management Console (UI)

L’interface web d’administration. C’est là que tout se pilote au quotidien :

• Création et configuration des APIs
• Gestion des plans (API key, OAuth2, keyless)
• Configuration des policies par API
• Visualisation des logs et analytics
• Gestion des utilisateurs et des droits

C’est un vrai différenciateur par rapport à Kong Community : vous avez une interface graphique complète, sans payer de licence.

Analytics (Elasticsearch)

Gravitee s’appuie sur Elasticsearch pour stocker l’historique des appels, les logs de requêtes/réponses, les métriques de performance. C’est ce qui alimente les dashboards d’analytics dans la console.

Le schéma type d’une requête :

Client → Gateway → [policies] → Backend API
                ↓
         Elasticsearch (logs + analytics)
                ↓
         Management Console (dashboards)

Les fonctionnalités qui changent la donne

Routage et versioning d’API

Gravitee permet de définir des context paths pour chaque API exposée. Vous pouvez faire pointer /api/v1/produits vers un backend Symfony et /api/v2/produits vers un nouveau service en Go - de manière transparente pour les consommateurs.

C’est exactement ce dont j’avais besoin pour faire évoluer le SI sans casser les clients existants. On déploie la nouvelle version en parallèle, on bascule le routage quand elle est prête, on garde l’ancienne en fallback.

Plans et authentification

Chaque API peut proposer plusieurs plans d’accès :

• Keyless : accès libre, sans authentification. Utile pour des APIs publiques ou internes.
• API Key : chaque consommateur reçoit une clé unique. Permet de tracer et limiter l’usage par consommateur.
• OAuth2 / JWT : intégration avec un serveur d’autorisation externe (Keycloak, Auth0, etc.)

Les plans sont indépendants les uns des autres. Vous pouvez avoir un plan keyless pour le monitoring interne et un plan API Key pour les partenaires, sur la même API.

Policies

Les policies sont des règles appliquées sur les requêtes entrantes ou les réponses sortantes. Quelques exemples concrets :

• Rate limiting : limiter un consommateur à 100 requêtes par minute. Indispensable pour protéger un backend qui ne scale pas à l’infini.
• Cache : mettre en cache les réponses d’endpoints peu volatils côté gateway. Le backend n’est même pas sollicité.
• Transform headers : ajouter ou modifier des headers avant de transmettre au backend.
• IP filtering : restreindre l’accès à certaines plages IP.
• Circuit breaker : couper automatiquement les appels vers un backend en erreur pour éviter l’effet cascade.

Toutes ces policies se configurent via l’interface graphique. Pas de code, pas de redéploiement.

Monitoring et analytics

C’est probablement la fonctionnalité que j’utilise le plus au quotidien. Le dashboard Gravitee affiche en temps réel :

• Le nombre de requêtes par API, par plan, par consommateur
• La latence moyenne et les percentiles (p95, p99)
• Le taux d’erreur (4xx, 5xx) par endpoint
• Les tops : endpoints les plus appelés, les plus lents, les plus en erreur

Quand un client signale une lenteur, je peux retrouver la requête exacte dans les logs Gravitee, voir le temps de réponse du backend, les headers échangés, le payload. Ça fait gagner un temps considérable en debugging.

Retour d’expérience : 4 ans en production

Déploiement sur Clever Cloud

J’ai déployé Gravitee.io sur Clever Cloud pour le projet Camping-Car Park. L’architecture en production :

• Gateway : une application Java déployée en tant que JAR. Clever Cloud gère le scaling et le redémarrage automatique.
• Management API : une seconde application Java - c’est le backend (API Rest) de la console d’administration (gestion des APIs, plans, policies, utilisateurs). Elle n’est pas exposée publiquement.
• Management Console : une application Node.js servie en statique.
• Elasticsearch : un add-on Elastic dédié sur Clever Cloud.
• MongoDB : un add-on MongoDB pour le stockage de la configuration (APIs, plans, utilisateurs).

L’installation initiale m’a pris à l’époque un peu plus d’une journée car j’avais rencontré quelques difficultés qui alors n’étaient pas documentées. La documentation de Gravitee est aujourd’hui claire et plus complète, les fichiers de configuration (gravitee.yml) bien documentés.

Dimensionnement d’Elasticsearch

C’est le point d’attention principal. Elasticsearch est le composant le plus gourmand de la stack, et de loin.

Chaque requête passant par la gateway génère une entrée dans Elasticsearch. Sur un projet avec plusieurs milliers d’appels par jour, l’index grossit vite. Sans politique de rétention, vous vous retrouvez avec des centaines de gigaoctets en quelques mois.

Ce qu’il faut mettre en place par exemple :

• Rétention à 30 jours pour les logs détaillés (request/response)
• Rétention à 90 jours pour les métriques agrégées (analytics)
• Curator (ou ILM - Index Lifecycle Management) pour supprimer automatiquement les anciens index
• Monitoring de l’espace disque Elasticsearch via Grafana

# Exemple de configuration ILM dans Elasticsearch
# Politique de rétention pour les index Gravitee
PUT _ilm/policy/gravitee-retention
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "5GB",
            "max_age": "7d"
          }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

Résilience : quand Elasticsearch tombe

Un point qui m’a agréablement surpris. Lors d’un incident Elasticsearch en production (crash du cluster suite à un manque d’espace disque), la gateway a continué de fonctionner normalement.

Les requêtes API étaient toujours routées, les policies appliquées, les consommateurs servis. On perdait juste les logs et les analytics le temps de remonter Elasticsearch.

C’est une architecture bien pensée : la gateway ne dépend pas d’Elasticsearch pour son fonctionnement critique. Elle écrit les logs de manière asynchrone. Si Elasticsearch est indisponible, les logs sont perdus, mais les utilisateurs ne sont pas impactés.

Mises à jour

En quatre ans, j’ai effectué plusieurs montées de version majeures. Le processus est bien documenté, les migrations de schéma de base sont gérées automatiquement.

Un seul conseil : toujours tester sur un environnement de staging avant la production. J’ai eu une fois une incompatibilité de policy après une mise à jour qui aurait pu couper l’accès à certaines APIs si je n’avais pas testé avant.

Gains concrets

Quelques exemples de ce que Gravitee nous a apporté au quotidien :

• Debugging accéléré : temps moyen de diagnostic d’un problème API divisé par trois. Les logs centralisés avec les temps de réponse backend, c’est un gain massif.
• Optimisation ciblée : identification immédiate des endpoints les plus lents. On a pu prioriser les optimisations Symfony sur les routes qui comptaient vraiment.
• Basculement transparent : lors de la migration d’un service de recherche, on a basculé le routage dans Gravitee sans toucher aux clients. Zéro downtime, zéro coordination avec les équipes mobile.
• Protection contre les abus : rate limiting sur les endpoints publics. Avant Gravitee, un script mal configuré chez un partenaire pouvait saturer le backend.

Limites et points d’attention

Gravitee n’est pas la solution à tous les problèmes. Voici ce qu’il faut savoir avant de se lancer.

Overhead de latence

La gateway ajoute quelques millisecondes à chaque requête (passage par la JVM, application des policies, écriture des logs). Sur la majorité des cas d’usage, c’est négligeable. Mais si votre API a des contraintes de latence sub-milliseconde, une gateway en Go (KrakenD) sera plus adaptée.

En pratique, sur le projet Camping-Car Park, l’overhead mesuré était de 3 à 8 ms par requête. Acceptable pour une API avec des temps de réponse backend de 50 à 200 ms.

Consommation de ressources

La gateway Java consomme plus de RAM qu’une solution en Go ou en Rust. Comptez 512 Mo minimum pour la gateway seule, et 1 Go recommandé en production avec du trafic soutenu. Ajoutez Elasticsearch, MongoDB, la Management API et la Console, et vous avez une stack qui demande des ressources non négligeables.

Complexité pour les petits projets

Si vous avez une seule API consommée par un seul client, Gravitee est probablement overkill. Un simple reverse proxy Nginx avec quelques règles de rate limiting fera le travail. Gravitee prend tout son sens à partir du moment où vous avez plusieurs APIs, plusieurs consommateurs, et un besoin de visibilité centralisée.

Version Community vs Enterprise

La version open source couvre la grande majorité des besoins. Mais certaines fonctionnalités sont réservées à la version Enterprise :

• Alert Engine : alertes avancées avec conditions complexes
• Developer Portal avancé : portail en libre-service pour les consommateurs d’API
• Support SLA : support garanti avec temps de réponse contractuel

Pour la plupart des projets que j’accompagne, la version Community suffit largement.

Quand mettre en place une API Gateway ?

Si vous cochez au moins deux de ces critères, la question mérite d’être posée sérieusement :

• Votre application expose une API consommée par plusieurs clients (web, mobile, partenaires, IoT)
• Vous avez besoin de visibilité sur la consommation de vos APIs (qui appelle quoi, à quelle fréquence, avec quelle latence)
• Vous prévoyez de faire évoluer votre architecture (découpage en microservices, migration de backend, versioning d’API)
• Vous devez protéger vos APIs contre les abus (rate limiting, authentification centralisée)
• Vous voulez pouvoir débugger un problème API sans fouiller dans les logs de dix services différents

Et si vous hésitez entre les solutions, mon conseil après avoir testé les principales : commencez par regarder Gravitee.io. L’interface de gestion incluse dans la version open source fait vraiment la différence au quotidien.

Liens utiles :

• Site officiel : gravitee.io
• Documentation : docs.gravitee.io
• GitHub : github.com/gravitee-io

Vous pensez avoir besoin d’une API Gateway, ou vous voulez de l’aide pour installer et configurer Gravitee.io ? Prenons contact - je peux vous accompagner du choix de la solution au déploiement en production.