Loading article...
Loading article...
Les applications de cartographie web ont longtemps souffert d'un défaut architectural récurrent : soit elles reposent sur des APIs tierces coûteuses et opaques,
Les applications de cartographie web ont longtemps souffert d'un défaut architectural récurrent : soit elles reposent sur des APIs tierces coûteuses et opaques, soit elles exposent un backend JSON anémique découplé d'un frontend qui réinvente ses propres conventions. Cet article emprunte une troisième voie.
Nous allons construire une application complète de gestion de zones géographiques en exploitant une pile délibérément cohérente — Rails 8, Inertia.js, React 18 avec TypeScript, Leaflet.js et Nominatim. Pas d'API REST séparée, pas de GraphQL, pas de service de tuiles payant. Inertia joue ici son rôle naturel : maintenir les conventions de routage et de contrôleur de Rails tout en déléguant intégralement le rendu à React, sans sacrifier la navigation côté client ni la gestion d'état du formulaire.
Techniquement, le défi est à plusieurs niveaux. Côté base de données, les coordonnées géographiques sont stockées en JSONB dans PostgreSQL — un choix pragmatique qui évite la dépendance à PostGIS pour une première itération, mais qui impose une validation applicative rigoureuse que ni ActiveRecord ni les Strong Parameters ne gèrent nativement pour les structures imbriquées. Côté frontend, Leaflet est une bibliothèque impérative dans un monde déclaratif : sa gestion correcte dans le cycle de vie React nécessite de distinguer précisément ce qui appartient aux refs et ce qui appartient au state, sous peine de re-rendus intempestifs à chaque clic sur la carte. Côté geocodage enfin, l'API Nominatim d'OpenStreetMap offre une alternative sérieuse aux solutions commerciales, à condition de respecter quelques contraintes d'utilisation et de gérer intelligemment le zoom via les boundingbox retournés par l'API.