Un prompt peut-il remplacer WeWeb ?

Construis un constructeur de frontend visuel qui se connecte à une API backend externe que tu as déjà — le véritable choix distinctif de WeWeb, par opposition à un constructeur d’appli avec sa propre base de données intégrée comme les fiches Bubble ou Glide de ce catalogue. Utilise Next.js/TypeScript pour le constructeur lui-même. Implémente un petit ensemble de composants liés aux données : une liste/répéteur lié à la réponse en tableau d’un point de terminaison d’API REST, rendant une carte par élément ; une vue détail liée à un point de terminaison d’enregistrement unique ; un formulaire qui poste vers un point de terminaison configuré à la soumission ; et des éléments basiques de texte, bouton et image. Laisse l’utilisateur configurer la source de données de chaque composant, une URL, une méthode HTTP, et un en-tête d’authentification optionnel, et lier des champs de réponse spécifiques à afficher, via un panneau de réglages plutôt que du code. Stocke la mise en page de page en JSON, un arbre de composants plus des liaisons, et rends-la à la fois dans un aperçu de constructeur et comme une page statique publiée. Ne construis pas une grande bibliothèque de composants, un système de style visuel sans CSS au-delà de préréglages de couleur et d’espacement basiques, ni un écosystème de plugins — c’est hors périmètre ; ceci connecte une poignée de composants à ta propre API, rien de plus. Nécessite un hébergement pour le constructeur et les pages publiées ; le backend auquel tu te connectes, Supabase, une API personnalisée, tout ce qui a un point de terminaison REST, est séparé et ne fait pas partie de ce projet.