J’ai découvert SQLPage dernièrement en faisant une recherche sur Google sur le thème de CFML. Je dois dire que je suis très enthousiaste vis-à-vis de ce projet open source car il correspond exactement à ce que je voulais et je dirais même à ce dont je rêvais et voilà que ça se matérialise sous mes yeux et que je peux le télécharger (depuis https://sql-page.com/) et l’essayer dans la foulée !
La page d’accueil du site du projet
De quoi s’agit-il en fait ?
SQLPage est un “Serveur d’applications Web open source low-code” (faut pas voir peur de ce jargon technique car le mot d’ordre de SQLPage est avant tout la sim-pli-ci-té…) qui permet de créer des applications Web sans effort avec uniquement des compétences SQL.
SQLPage transforme vos requêtes SQL en de superbes sites Web. SQLPage est un outil qui vous permet de créer des sites Web en utilisant uniquement des requêtes SQL (mais oui !). Vous écrivez des fichiers texte simples contenant des requêtes SQL, SQLPage les exécute sur votre base de données et affiche les résultats sous forme de site Web, page par page.
Vous pouvez afficher les informations que vous sélectionnez dans votre base de données dans des listes, des tableaux, des graphiques, des cartes, des formulaires et de nombreux autres composants d’interface utilisateur. Mais vous pouvez également insérer, mettre à jour et supprimer (tout cela via des requêtes “Select”, “insert”, “update” ou “delete” habituelles du SQL) des données de votre base de données à l’aide de SQLPage et ainsi créer une application Web complète.
Techniquement, c’est juste un bon vieux serveur web
Les principes derrière SQLPage ne sont pas très éloignés de ceux qui ont alimenté les débuts d’Internet. Comme PHP (lors de ses débuts), SQLPage reçoit simplement une requête, trouve le fichier à exécuter, l’exécute et renvoie une page Web que le navigateur doit afficher.
SQLPage est un serveur web écrit dans un langage de programmation rapide : Rust. SQLPage est extrêmement simple à utiliser : vous téléchargez un seul fichier exécutable, écrivez un fichier .sql (par page HTML désiré) et le tour est joué.
Lorsque SQLPage reçoit une requête avec une URL se terminant par .sql, il trouve le fichier SQL correspondant, l’exécute sur la base de données (s’il y a des données à récupérer ou à écrire), en lui transmettant les informations de la requête Web en tant que paramètres d’instruction SQL de manière sécurisée. Lorsque la base de données commence à renvoyer des lignes pour la requête, SQLPage fait correspondre chaque élément d’information de la ligne à un paramètre du modèle d’un composant prédéfini (c’est ainsi que SQLPage gère la présentation dans les pages HTML résultantes) et renvoie le résultat au navigateur de l’utilisateur.
L’architecture de SQLPage en une image…
Voilà pour les aspects techniques, de manière très simplifiée, évidemment !
Si vous en voulez plus et une démonstration live, c’est facile : il suffit de regarder la vidéo réalisée par Ophir Lojkine (c’est le développeur qui est à l’origine de ce projet génial) sur YouTube…
Oui, la vidéo est en anglais mais facile à comprendre (Ophir s’exprime encore mieux en français, j’en témoigne !). Et en voici une autre (également en anglais) :
La simplicité est clé
Ceci dit et j’insiste sur ce point, tout cela est possible de manière vraiment simple. La simplicité, c’est vraiment la clé et ce qui distingue SQLPage des autres solutions en la matière. OK, c’est simple, on a compris… Mais peux-tu nous montrer à quoi ressemble ce fameux code ?
Car voir sur pièce, c’est mieux… Mais pas de problème monseigneur, tout de suite monseigneur !
Voici deux pages d’exemples de code SQLPage :
Le code et le résultat !
Comme on peut s’en rendre compte, c’est simple et lisible. Et encore, j’ai pris ici une page bien fournie, la grande majorité des pages .sql sont bien plus frugales que cela.
Le retour de la simplicité au premier plan
Selon moi, SQLPage serait un signe du retour de la simplicité dans un contexte où c’est trop souvent le “toujours plus” qui triomphe. C’est d’ailleurs tout à fait fascinant de constater que l’évolution technique en matière de programmation oscille continuellement entre simplicité et sophistication. Des solutions techniques apparaissent, elles sont d’abord simples (comme les toutes premières versions de ColdFusion des frères Allaire au milieu des années 90 ou PHP lors de ces débuts) pour ensuite dériver et devenir plus complexes, moins “lisibles”, plus difficiles à mettre en œuvre… Mais capables de gérer des problèmes plus complexes, aussi…
Il y a toujours un compromis et des choix à faire entre les solutions techniques “larges & profondes” qui permettent de résoudre des problèmes complexes et les solutions techniques plus simples, mais moins adaptées à la réalisation de développements sophistiqués. Sur cette échelle SQLPage se situe quelque part entre Airtable et PHP.
L’expérience (positive) du “no code”
Dernièrement, on a connu les tendances du Low Code/no code dans les outils de développement intégrés et j’en ai parlé largement dans cette chronique. Je suis un utilisateur assidu de Airtable et j’en suis très satisfait la plupart du temps. Cependant, j’aimerais bien pouvoir aller plus loin avec Airtable dans certains cas, écrire mes propres requêtes en SQL par exemple… Mais, avec ce genre d’outil, si ce n’est pas prévu au départ, c’est simplement impossible. Et si demain Airtable disparaît (ou se met à évoluer d’une façon qui ne me convient pas ou même triple ses tarifs !), eh bien tout mon “investissement” dans cet outil sera perdu, encore heureux si j’arrive à sauvegarder mes données à temps !
C’est là où SQLPage offre une alternative intéressante, pour moi en tout cas. Cet outil définit une nouvelle catégorie à lui tout seul : celle du code simple. OK, il faut coder, tout coder de A à Z mais ça reste dans un langage standard (le SQL existe depuis les années 70 !) et avec une syntaxe sans surprise. Et, croyez-le ou non mais il existe toute une frange d’utilisateurs qui attendaient précisément une solution de cet acabit.
Moins c’est plus…
Il y a une tendance bizarre dans notre domaine à rejeter la simplicité et ne pas comprendre que, très souvent, “moins c’est plus et plus, c’est moins finalement…”. Ici, il faut comprendre “plus” comme “trop”. Trop de fonctionnalités, trop de sophistication, trop de trucs différents à apprendre et ainsi de suite. Ce n’est d’ailleurs pas propre aux environnements de développement, c’est pareil dans les applications de bureautique : la dernière version d’Excel (par exemple) est capable de faire plein de trucs que vous n’utiliserez jamais et si, par hasard, vous vous retrouviez avec la version 95 d’Excel (celle diffusée avec le bundle d’Office95 en 1995, justement, à l’occasion du lancement de Windows 95… Oui, tout cela ne nous rajeunit pas, certes), vous ne seriez ni dérouté ni limité (à moins d’être un consultant qui raffole des macros Excel trop compliquées !).
Le “pourquoi faire simple quand on peut faire compliqué” (et la facturation qui va avec !) est un raisonnement bien trop répandu dans le milieu informatique et depuis trop longtemps.
Bien évidemment, les développeurs “top gun” vont trouver SQLPage trop simple, pas pour eux, je dirais même “indigne d’eux et de leur niveau technique stratosphérique” (OK, je me moque un peu là) mais, ça tombe bien, ce n’est justement pas pour eux qu’Ophir s’est lancé dans ce projet mais pour des gens comme moi. Mais justement, quand et pourquoi s’est-il lancé dans cette “quête” ?
Génèse du projet SQLPage
Il y a quelques années, Ophir avait des amis qui commençaient à travailler dans des sociétés de conseils et ils lui racontaient comment ils s’échinaient à tenter d’améliorer les processus des organisations clientes. Pour ce faire, ils employaient beaucoup d’Excel avec des formules et macros compliquées !
Voyant cela, Ophir réplique que tous ces efforts seraient bien plus efficaces en recourant à du vrai coding et non pas à triturer Excel dans tous les sens. Mais, en réponse, il constata une grosse réticence vis-à-vis du code informatique alors que les formules et macros Excel étaient, en réalité, bien compliquées que du code, surtout pour ce qui était de l’accès à une ou des bases de données.
Cette réticence s’expliquait facilement : ses amis étaient effrayés par l’apprentissage nécessaire avant d’arriver à se débrouiller avec SQL, HTML, Python et j’en passe…
Ophir se fit donc la réflexion qu’Il faudrait arriver à faire tout cela mais avec un seul langage (au lieu de tout cet empilement hétérogène. Ainsi l’apprentissage serait grandement simplifié et les réticences s’évanouissaient. D’accord mais quels étaient les langages à éliminer en premier lieu ?
Après pas mal de “jus de cerveau”, la réponse s’imposa d’elle-même : virer tous les langages procéduraux pour ne garder que la déclaration des données à afficher dans l’interface. Et, dans cette perspective simplifiée, un et un seul langage s’imposait vraiment : le vénérable, omniprésent et bien connu SQL !
Créé en 1974, normalisé en 1986, SQL, le langage d’interrogation des bases de données relationnelles a traversé les époques informatiques, s’est adapté à toutes formes de bases de données (pas seulement le sacro-saint modèle relationnel) et demeure –50 ans après sa naissance– toujours aussi incontournable.
Après la crise covid
Ophir a mené cette réflexion initiale en 2022 après la crise covid.
Le but de ce nouveau projet serait de pouvoir écrire des applications Web mais sans avoir à écrire de HTML et sans avoir à écrire de logique, uniquement l’accès au données et aux composants d’affichage.
Le projet est officiellement lancé en août 2022 où on peut voir le tout premier “commit” sur GitHub :
Commit sur GitHub
La toute première présentation du projet (qui, au tout début, s’appelait “SQL Site”… Mais suite à un conflit de nom existant, fut renommé rapidement en SQLPage) a eu lieu sur Hackernews puis sur Linuxfr.
Sur Hackernews
Sur LinuxFR
Un accueil initial accompagné d’un certain scepticisme…
Le projet reçut un relatif bon accueil mais certains sceptiques dénigrèrent un peu l’intention, surtout parmi les plus techniques : ça leur paraissait tiré par les cheveux et pas assez ambitieux ou trop rustique selon les cas. Ces débuts mitigés ne sont pas complètement surprenants car beaucoup préfèrent critiquer que de faire… De plus, un projet axé sur la simplicité est presque une provocation pour les techniciens qui croient vivre par la technique et pour la technique !
Ophir ne se décourage pas et met en place le site web du projet (lui même écrit en SQLPage d’ailleurs) apparaît fin 2022. La popularité du site monte progressivement grâce aux moteurs de recherche (c’est mon cas, c’est comme cela que j’ai découvert ce projet !) et le projet commence à trouver son allure de croisière grâce à des vrais utilisateurs qui s’emparent de ce potentiel bienvenu.
Des utilisateurs réels sont apparus et ont développé des vrais app.
Pour illustrer l’entrée en scène des vrais utilisateurs, ceux qui transforment effectivement une idée en projet, commençons par de l’exotisme et transportons-nous en Afrique du Sud. Là, nous trouvons un certain William Cronje qui travaille dans le call center d’une entreprise de transport qui s’est dotée d’une grosse base de données qui permet de stocker les données des capteurs dont sont bardés les camions de l’entreprise. Des capteurs à tous les étages… mais pour quoi faire ?
Eh bien, il y a les usages évidents, genre surveiller la température du fourgon des camions frigorifiques mais il y a aussi les usages moins habituels et propres au contexte de l’Afrique du Sud… Ainsi, on trouve des capteurs pour assurer le tracking de camions afin de pouvoir déclencher des interventions rapides avec des équipes armées (carrément !) pour récupérer le camion lorsque ce dernier est victime d’une attaque (fréquente à ce qu’il parait !). La base de données, c’est bien mais avec des applications au-dessus afin d’en tirer le plein potentiel, c’est mieux !
Le chef de William repère SQLPage et lui propose de le tester. A la suite de ce test (positif), il a développé une demi-douzaine d’applis basées sur SQLPage.
Donc après ces premiers retours d’expériences, Ophir s’est dit « il y a bien quelque chose, surtout du côté des utilisateurs peu techniques ». Puis au tour des archéologues de s’emparer de SQLPage (un projet raconté en long et en large ici). Il y a aussi eu un directeur de collège dans le sud de la France qui s’est emparé de SQLPage pour le suivi de ses élèves handicapés. La mayonnaise commence effectivement à prendre du côté des low-techs et c’est bien la cible qu’il faut viser car il y a déjà pléthore pour ceux qui veulent toujours plus de sophistication…
Voici un aperçu de l’application développée par David, le principal du collège évoqué plus haut.
Rester dans la simplicité est un combat !
Ophir est conscient que la maîtrise de l’évolution de son projet ne va pas être facile. Rester dans les fondamentaux de SQLPage veut dire aussi résister à ceux qui en demandent toujours plus : étendre les fonctions, étendre les capacités et ainsi de suite. Il suffit de voir la teneur des discussions à ce propos sur GitHub, ce sont toujours les plus “tech” qui s’expriment en premier, haut et fort. Ce n’est pas un reproche, c’est une constatation. Et d’ailleurs, c’est normal. L’utilisateur de base, celui qui est juste à l’aise pour manipuler Airtable (par exemple), son premier réflexe n’est pas de créer son compte sur GitHub (si même il sait de quoi il s’agit !).
Ceci dit, lors de l’échange récent par visio que j’ai eu avec Ophir, il m’est apparu qu’il avait une vision claire et, je dirais même saine, de l’avenir de son projet. Il n’est pas fermé à l’extension des capacités de SQPage mais en prenant en compte des SGBD pas encore traité par exemple. Ou en permettant l’utilisations simultanée de plusieurs sources de données au sein d’une même application (exemple : j’accède à des données en lecture sur une base hébergée par MySQL et, ensuite, je procède à une mise à jour de données stockées dans PostgreSQL ou autres). Et, sur le plan de l’accessibilité, Ophir et Alexis Rouge Carrassat (l’ami d’Ophir et contributeur émérite du projet) sont en train de travailler à une offre cloud qui éviterait à des utilisateurs de base comme moi de se heurter au mur de la configuration qui semble “peanuts” au pro de la ligne de commande mais n’est pas si facile à contourner quand vous n’êtes pas familier avec le maniement de la “ligne de commande”, justement.
Conclusion, vers un avenir radieux ?
Vous l’aurez compris, je suis très enthousiaste vis-à-vis de ce projet et j’espère bien qu’il va connaître le succès, une large audience et évoluer dans le bon sens. Un avenir radieux quoi…
Mais j’ai aussi suffisamment d’expérience pour savoir que ce n’est pas gagné d’avance, quelles que soient les qualités de ce projet. En effet, ce n’est qu’un (relativement) nouveau projet open source comme il y en a plein tout le temps. Et la grande majorité ne décolle pas, rappel !
Il faudra donc un peu de chance à SQLPage. Mais j’y crois et je suis prêt à parier que ça sera le cas. Je vous encourage à tester SQLPage et à me faire part de vos expériences en commentaires.