Écrire une appli web en une journée avec SQLPage

Posté par lovasoa (site web personnel) le 04 juillet 2023 à 09:28. Édité par Nÿco, Benoît Sibaud, gUI, BAud et bobble bubble. Modéré par Nÿco. Licence CC By‑SA.

Étiquettes :

juil.

2023

Aujourd'hui, je souhaite vous présenter le logiciel SQLPage, un outil open-source (MIT) qui permet de développer des applications web complètes, avec une belle interface graphique et une base de données, entièrement en SQL.

Le SQL est un langage très simple, qui permet de faire des recherches dans des base de données. Il est utilisé depuis les années 80, et est encore omniprésent aujourd'hui. Contrairement aux langages de programmation traditionnels, on peut apprendre les bases de SQL en une journée, et commencer à faire des requêtes complexes croisant plusieurs tables de données très rapidement.

Dans une application web traditionnelle, on développe aujourd'hui en général trois composants :

un front-end, qui gère uniquement l'interface utilisateur,
un back-end, qui traite les requêtes du front-end et contient le cœur de la logique de l'application lorsque celle-ci est complexe,
une base de données qui va stocker et structurer les données, s'assurant de leur cohérence et de leur bonne organisation.

Les deux premiers éléments sont en général ceux sur lesquels les programmeurs passent le plus de temps lors du développement d'une application. Et pourtant, c'est souvent le dernier, la base de données, qui contient la substantifique moelle de l'application !

Ce que propose SQLPage, c'est de s'abstraire complètement du back-end et du front-end, et générer toute une application entièrement en SQL. Nous allons voir ici comment c'est possible, avec un exemple concret d'application que nous allons construire ensemble en SQL : à la Tricount.com, une petite application qui permet de gérer ses comptes entre amis.

Sommaire

Est-ce de la sorcellerie ?
Comment ça marche ?
Construisons une application
- Notre application : une application opensource pour faire ses comptes entre amis
- Amélioration de l'application, création de nouvelles pages
  - Cerise sur le gâteau : calcul des dettes
Conclusion
- - Pour résumer ce que nous avons vu
  - Pour aller plus loin

Est-ce de la sorcellerie ?

Tout d'abord, mettons les choses au clair : votre application aura bien un backend et un frontend, il n'y a pas de miracle. Mais pour les applications simples, le frontend est souvent juste un assemblage de composants standards, et le backend qu'une sorte de passe-plats entre le frontend et la base de données. Ce que permet SQLPage, et que nous allons étudier ici c'est :

d'invoquer des composants prédéfinis d'interface graphique en donnant simplement leur nom et quelques paramètres,
de faire le lien entre l'interface graphique et la base de données avec de simples fichiers SQL qui sont exécutés automatiquement lorsque l'utilisateur charge une page.

Comment ça marche ?

SQLPage est un simple serveur web : c'est un programme qui tourne en continu, attend des requêtes HTTP, et dès qu'il en reçoit une, fournit une réponse.

Si SQLPage reçoit une requête vers /site/contenu.sql?article=42, il va chercher un fichier nommé contenu.sql, dans un dossier nommé site. Il va ensuite lire le contenu du fichier, et l'interpréter comme une série de requêtes SQL, qui vont être préparées. Elles seront ensuite exécutées une par une. Si l'une de ces requêtes fait référence à une variable nommée $article, la valeur 42 venant de la requête de l'utilisateur lui sera associée.

architecture sqlpage

Les requêtes sont envoyées à la base de données, et celle-ci commence à retourner des lignes de données, une par une.

Les lignes vont ensuite être analysées au fil de l'eau par SQLPage, qui va décider quel composant graphique renvoyer au navigateur web, et quelles données utiliser pour remplir le composant.

Construisons une application

Pour rendre tout ce discours plus concret, créons ensemble une petite application, entièrement en SQL, et en vingt minutes.

Pour vous donner un avant-goût, voilà ce à quoi nous allons arriver au final

Page d'accueil	Gestion d'utilisateurs	Liste de dépenses	Graphique de dettes

Il n'y a pas toutes les fonctionnalités de l'application originelle, mais c'est seulement 83 lignes de code, grâce à tout ce que SQLPage gère automatiquement. Et le résultat est quand même plus joli que l'original.

Notre application : une application opensource pour faire ses comptes entre amis

Nous allons créer une application pour faire ses comptes entre amis. Elle aura les fonctionnalités suivantes :

créer un nouveau compte de dépenses partagé
ajouter des participants et visualiser la liste des participants existants
pour chaque participant :
- ajouter une dépense
- voir les dépenses des autres
- voir combien il doit au reste du groupe ou combien lui est dû

Première étape : choisir un schéma pour notre base de données

Et oui, on ne va pas passer quatre jours à choisir un framework JavaScript, un framework CSS, un ORM, ou autres choses compliquées que l'on fait quand on commence une application web classique. Avec SQLPage, on rentre tout de suite dans le cœur du sujet, et ce qui sera important pour la suite: quelles données stockerons-nous, et sous quelle forme.

Ici, je propose le schéma suivant :

une table expense_group pour nos comptes de dépenses partagés, avec un identifiant numérique et un nom.
une table group_member pour les utilisateurs, avec un identifiant numérique, un nom, et l'identifiant du compte partagé auquel il appartient.
une table expense pour les dépenses, avec l'identifiant de l'utilisateur ayant fait la dépense, une description, et un montant. Pour cet exemple, nous ne prendrons pas en compte le cas où une dépense peut ne concerner qu'une partie du groupe; ce sera simple à ajouter dans un second temps.

Deuxième étape : création de la base de données et lancement de SQLPage

C'est parti ! Téléchargeons SQLPage sur le site officiel.

Créons un dossier pour notre application, et dans ce dossier créons la structure de fichiers suivante:

├── sqlpage
│   ├── migrations
│   │   └── 000_base.sql
│   └── sqlpage.json
└── sqlpage.bin

Nous créons donc les fichiers suivants:

sqlpage/migrations/000_base.sql dans lequel nous définirons la structure de notre base de données
sqlpage/sqlpage.json dans lequel nous mettrons pour l'instant simplement la ligne suivante: {"database_url": "sqlite://:memory:"}. Cela nous permet de travailler avec une base de données temporaire en mémoire. Nous le modifierons plus tard pour nous connecter à une base de données plus pérenne.

Intéressons-nous d'abord à sqlpage/migrations/000_base.sql. Pour créer la structure de base de données définie plus tôt, utilisons quelques instructions de création de table :

CREATE TABLE expense_group(
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  name TEXT
);

CREATE TABLE group_member(
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  group_id INTEGER REFERENCES expense_group(id),
  name TEXT
);

CREATE TABLE expense(
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  spent_by INTEGER REFERENCES group_member(id), -- identifiant du membre qui a fait la dépense
  date TIMESTAMP DEFAULT CURRENT_TIMESTAMP, -- date et heure de la dépense
  name TEXT, -- intitulé
  amount DECIMAL -- montant en euros
);

On peut maintenant lancer l'exécutable sqlpage.bin (ou sqlpage.exe sous Windows 😬) depuis le dossier de notre site.

Il doit se lancer, et afficher dans le terminal le message suivant : Applying migrations from 'sqlpage/migrations [...] Found 1 migrations. Cela signifie qu'il a créé avec succès notre base de données selon le schéma demandé.

En ouvrant la page http://localhost:8080 sur notre navigateur web, nous devrions voir le message suivant:

Screenshot 2023-06-28 at 16-46-40 SQLpage

Troisième étape : création de notre première page web

Le moment tant attendu est arrivé : nous allons créer notre première page web et pouvoir l'ouvrir dans notre navigateur.

Pour cela, créons un fichier nommé index.sql à la racine du dossier de notre site web. À l'intérieur, nous allons écrire une série de requêtes SQL.

SQLPage marche de la manière suivante : on fait une première requête pour invoquer un composant graphique, comme une liste, un formulaire, du texte, ou un graphique. Ensuite, on fait une seconde requête pour définir comment peupler notre composant : les éléments de la liste, les champs du formulaire, les paragraphes de texte, ou les points de notre graphique.

Dans notre cas, notre premier composant sera un formulaire pour créer un nouveau groupe de dépenses à partager entre amis. Pour cela, nous allons invoquer le composant form. Dans index.sql, écrivons :

SELECT 
    'form' as component,
    'Nouveau compte partagé' as title,
    'Créer le compte de dépenses partagé !' as validate;

Cela crée un formulaire, vide, que l'on peut déjà voir dans notre navigateur ! Maintenant, ajoutons un champ dans le formulaire. Immédiatement à la suite de la requête précédente, ajoutons:

SELECT 'Nom du compte' AS label, 'shared_expense_name' AS name;

Rouvrons notre navigateur, et nous devrions maintenant voir cela :

sqlpage form

Insertion de données dans la base de données

Pour l'instant, lorsque l'on clique sur le bouton Créer le compte de dépenses partagées, il ne se passe rien. Corrigeons cela !

Toujours dans index.sql, à la fin de notre fichier, ajoutons une nouvelle requête SQL :

INSERT INTO expense_group(name)
SELECT :shared_expense_name WHERE :shared_expense_name IS NOT NULL;

Ici, on utilise une requête de type INSERT INTO ... SELECT pour insérer une nouvelle ligne dans la table expense_group. On ajoute une clause WHERE pour qu'une ligne ne soit insérée que lorsque l'utilisateur a rempli une valeur dans le formulaire, et pas à chaque fois que la page se charge.

La variable SQL :shared_expense_name sera associée à la valeur que l'utilisateur aura rentré dans le champ de texte que nous avons appelé shared_expense_name à l'étape précédente.

Maintenant, chaque validation de formulaire crée une nouvelle ligne dans notre base de données. Il est temps de créer notre premier composant dynamique, dont le contenu va dépendre de ce qu'il y a dans notre base de données. Toujours à la suite, dans index.sql:

SELECT 'list' as component;
SELECT 
  name AS title,
  'group.sql?id=' || id AS link
FROM expense_group;

Ici, nous utilisons un nouvel élément issu de la bibliothèque standard de SQLPage: le composant list. Après l'avoir sélectionné, nous le peuplons avec des données qui viennent de la table expense_group de notre base de données. Pour chaque élément de la liste, nous spécifions un lien vers lequel l'utilisateur sera emmené lorsqu'il cliquera dessus. Pour créer ce lien, nous concaténons le nom d'un nouveau fichier SQL que nous allons créer, avec une variable qui contient l'identifiant du groupe à afficher.

Liste dynamique avec SQLPage

Amélioration de l'application, création de nouvelles pages

Nous avons maintenant vu tous les éléments nécessaires à la construction d'une application. Il ne nous reste plus qu'à les appliquer à la création des pages restantes de notre application opensource.

Dans group.sql, réutilisons les composants from et list que nous connaissons maintenant :

SELECT 'title' as component, name as contents
FROM expense_group WHERE id = $id;

INSERT INTO group_member(group_id, name)
SELECT $id, :new_member_name WHERE :new_member_name IS NOT NULL;

SELECT 'list' as component, 'Membres' as title;
SELECT name AS title FROM group_member WHERE group_id=$id;

SELECT 'form' as component, 'Ajouter un membre au groupe' as validate;
SELECT 'Nom du membre' AS 'label', 'new_member_name' AS name;

SELECT 'title' as component, 'Dépenses' as contents;

SELECT 'form' as component, 'Ajouter une dépense' as title, 'Ajouter' as validate;
SELECT 'Description' AS name;
SELECT 'Montant' AS name, 'number' AS type;
SELECT 'select' as type, 'Dépensé par' AS name,
    json_group_array(json_object("label", name, "value", id)) as options
FROM group_member WHERE group_id = $id;

INSERT INTO expense(spent_by, name, amount)
SELECT :"Dépensé par", :Description, :Montant WHERE :Montant IS NOT NULL;

SELECT 'card' as component, 'Dépenses' as title;
SELECT
    expense.name as title,
    'Par ' || group_member.name || ', le ' || expense.date as description,
    expense.amount || ' €' as footer,
    CASE WHEN expense.amount > 100 THEN 'red' WHEN expense.amount > 50 THEN 'orange' ELSE 'blue' END AS color 
FROM expense
INNER JOIN group_member on expense.spent_by = group_member.id
WHERE group_member.group_id = $id;

Nous avons ici créé une seule page, qui contient plusieurs listes et plusieurs formulaires, juste en écrivant nos requêtes SQL les unes après les autres dans notre fichier.

Le seul point particulier à noter, qui est différent de ce que nous avons vu avant, est l'utilisation de la fonction sql json_group_array pour remplir la valeur du champ de formulaire à choix multiple, qui prend un tableau json comme valeur.

Nous arrivons au résultat suivant :

screenshot sqlpage

Cerise sur le gâteau : calcul des dettes

Une fonctionnalité pratique de l'application originelle est le calcul du tableau de dette. L'application fait elle-même le calcul final de qui doit combien. C'est un peu moins trivial que les requêtes classiques de listage de données que l'on a vues jusqu'ici, mais on peut aussi implémenter cela entièrement en SQL.

On crée quelques vues qui nous seront utiles pour nos calculs.

Dans SQLPage, on ne crée en général pas de fonctions, et on n'importe pas des bibliothèques. Pour construire une fonctionnalité complexe, le plus simple est de construire des vues successives de nos données, dans lesquelles on les groupe et les filtre comme on le suite. Ici, on construit les trois vues simples suivantes, chacune avec sa fonction SQL :

members_with_expenses, qui va lier nos tables entre elles pour associer les noms des membres à leurs montants de dépenses.
average_debt_per_person qui va diviser le montant total dépensé par le groupe par le nombre de participants.
individual_debts qui va soustraire la dépense moyenne aux dépenses personnelles de chacun, pour savoir combien il doit ou combien on lui doit.

Ici c'est du SQL classique, il n'y a rien qui soit propre à SQLPage. Je vous laisse lire les 27 lignes de code sur github.

Conclusion

Nous avons vu comment construire une application web complète entièrement en SQL grâce à SQLPage. Nous pouvons maintenant la faire tourner sur un tout petit serveur chez nous, dans le cloud, ou même en mode sans-serveur. SQLPage est écrit dans le langage de programmation rust et consomme très peu de resources par rapport à une application web classique, l'application sera donc très peu chère à héberger.

Pour résumer ce que nous avons vu

Nous avons tout d'abord créé une structure de base de données grâce aux migrations.

Ensuite, nous avons affiché des composants graphiques grâce à la bibliothèque de composants intégrés de SQLPage.

Enfin, nous avons inséré des données dynamiquement dans notre base de données grâce au système de variables de SQLPage.

Pour aller plus loin

SQLPage est un logiciel libre et gratuit. Si vous rencontrez des problèmes lors de son utilisation, n'hésitez pas à rapporter un bug ou demander une fonctionnalité sur github, ou à discuter de son utilisation sur les pages de discussion.

Et si vous cherchez une idée pour vous entraîner… Pourquoi pas un TapTempo entièrement en SQL ?

Aller plus loin

Site officiel du projet SQLPage (444 clics)
Code source du projet sur Github (166 clics)

# Lé résultat: notre mini-tricount

Posté par lovasoa (site web personnel) le 04 juillet 2023 à 10:32. Évalué à 7.

Si vous voulez voir le résultat, j'ai hébergé une instance de démo de l'application ici: https://tinyurl.com/minitricount (attention, les données ne sont pas persistantes et sont réinitialisées régulièrement).

Et le code source est disponible ici: https://github.com/lovasoa/SQLpage/tree/main/examples/splitwise
- [^] # Re: Lé résultat: notre mini-tricount
  
  Posté par lovasoa (site web personnel) le 04 juillet 2023 à 11:15. Évalué à 3.
  
  D'ailleurs, n'hésitez pas à me dire si vous seriez intéressé par une version de l'application de gestion de dépenses hébergée de manière pérenne, et avec un peu plus de fonctionnalités :)
# Merci pour l'info

Posté par Christophe B. (site web personnel) le 04 juillet 2023 à 11:18. Évalué à 8.

Exactement le genre de choses qui peut être utile quand on connait mal le dev WEB

merci
# Clin d'œil

Posté par Epy le 04 juillet 2023 à 17:35. Évalué à 4.

Le nom du logiciel est un clin d'œil à Frontpage ? ^{_^} (front-end/back-end/sql)
- [^] # Re: Clin d'œil
  
  Posté par lovasoa (site web personnel) le 04 juillet 2023 à 17:49. Évalué à 3.
  Ah, je ne connaissais pas Microsoft FrontPage !
  
  Mais en lisant un peu, j'ai l'impression que l'objectif de FrontPage était presque le contraire de ce que fait SQLPage.
  - FrontPage incitait à passer du temps sur l'interface graphique, et le rendu visuel d'un site statique.
  - SQLPage génère des sites dynamique, et est inspiré par le Data-Oriented Design. Il pousse à réfléchir à la structure de la donnée que l'on manipule plus qu'aux petits détails visuels.
# Morts aux ORM, vive ELM

Posté par gerfaut83 (site web personnel) le 04 juillet 2023 à 18:37. Évalué à 6.

Merci pour cet article très intéressant. Je me suis posé récemment le même type de questions en cherchant un backend léger et sûr (du point de vue typage) pour des frontends écrits en Elm. Et en étudiant des architectures de backend, j'avais l'impression qu'entre la BD et la partie ORM du backend, il y a souvent beaucoup de redite.

Je suis alors tombé sur des projets (l'un en haskell) PostgREST et (l'autre en JS) Graphile, selon que l'on préfère les architectures REST ou GraphQL.

Je ne connaissais pas cette solution purement SQL, mais je trouve intéressant d'explorer les capacités de gestion des données directement par le SGBD, plutôt qu'en faisant (ou refaisant) les choses côté backend. Forcément, l'approche a ses limites : il faut souvent recourir à des notions de workers ou autre pour certaines actions… Mais le SGBD est bien souvent capable de réaliser des optimisations difficilement envisageables avec une couche ORM, pour peu qu'on décrive précisément ce qu'on souhaite faire.

J'apprécie beaucoup le côté déclaratif de SQL, qui sous-traite (généralement de manière assez efficace) au moteur du SGBD le soin de trouver le meilleur schéma d'exécution. Et, quand ce n'est pas le cas, c'est une très bonne occasion de se poser quelques questions sur la représentation/normalisation de nos données, et de réfléchir à l'utilité de créer tel ou tel index, vue matérialisée, etc.

Bref, quel est alors le lien avec le langage Elm, aucun, sinon un jeu de mot franco-anglophone qui me démangeait pour le titre de mon commentaire.
- [^] # Re: Morts aux ORM, vive ELM
  
  Posté par lovasoa (site web personnel) le 04 juillet 2023 à 18:55. Évalué à 1.
  
  Je suis tout à fait d'accord: mort aux packages Java de 2000 lignes qui ne font que retranscrire un modèle de données, et aux ORM!
  
  La création d'APIs directement en SQLPage est aussi prévue dans la roadmap, pour obtenir un remplacement ultra-léger et performant de postgREST. https://github.com/lovasoa/SQLpage/issues/6
  
  Et pour graphql, il y a aussi hasura, que j'utilise et dont je suis très content.
  
  On peut aussi mentionner pocketbase, pour une API REST automatique sur une base SQLite.
  - [^] # Re: Morts aux ORM, vive ELM
    
    Posté par YBoy360 (site web personnel) le 09 août 2023 à 04:52. Évalué à 4.
```
Je suis tout à fait d'accord: mort aux packages Java de 2000 lignes qui ne font que retranscrire un modèle de données, et aux ORM!
```
    Pfff tu peux expliquer ?
    
    Perso, j'utilise GORM (Grails ORM) depuis 10 bonnes années, et oui, j'ai fait 12 ans de SQL avant, sans compter beaucoup, beaucoup de code natif, d'optimisation CPU bien au delà de ce que la littérature d'aujourd'hui pourrait apporter, de l'optimisation GPU, je me suis occupé d'Heisenbug de compilateur pendant plusieurs années de ma vie, à une époque ou je n'avais pas d'accès internet à mon bureau …
    
    Bref, j'en apprends tous les jours malgré tout, mais j'en ai ma claque des gars qui critiquent systématiquement ce qui vient de Java, sans aucun argument, qui prouvent surtout leur incompétence et leur susceptibilité, proposant des solutions qui refont la même chose systématiquement moins bien.
    
    Ce n'est pas le cas de SQLPage, mais les ORM, n'ont rien à voir avec le sujet…
    - [^] # Re: Morts aux ORM, vive ELM
      
      Posté par lovasoa (site web personnel) le 09 août 2023 à 09:19. Évalué à 3. Dernière modification le 09 août 2023 à 09:20.
      
      Le ton de mon commentaire n'était effectivement pas adapté. Ce que j'essayais d'exprimer, c'est le sentiment de fatigue et de frustration (qui me semble commun autour de moi) en utilisant un ORM, ou en écrivant une longue classe (en java ou autre) qui ne fait que retranscrire un modèle de données qui est déjà présent ailleurs.
      
      En particulier avec les ORMs, mon expérience est surtout d'avoir passé beaucoup de temps à simplement retrouver dans la documentation de l'ORM comment traduire telle ou telle structure qui est standard en SQL. Et souvent, à retirer beaucoup trop de données de la base de données pour les traiter dans une boucle sur le serveur d'application au lieu de faire le travail directement en base.
      - [^] # Re: Morts aux ORM, vive ELM
        
        Posté par YBoy360 (site web personnel) le 10 août 2023 à 12:48. Évalué à 3.
        
        Excuse-moi pour le ton. Je dois travailler la forme de mes propos.
# Sympa !

Posté par bux (site web personnel, Mastodon) le 05 juillet 2023 à 10:29. Évalué à 2.

Sympa ce logiciel ! Je mets en marque page :)

🦀🐍 http://github.com/buxx 🖥 https://algoo.fr 📋 https://tracim.fr
# Informix 4G

Posté par ll0zz (Mastodon) le 05 juillet 2023 à 13:33. Évalué à 2.

J'ai toujours gardé un souvenir ému d'Informix 4GL qui permettait des interfaces en mode texte en quelques minutes (en plus du SQL).
C'était au millénaire dernier (job d'été eu Futuroscope en… 1998 ?)

Et donc, je retrouve ici la même approche, mais un poil plus moderne (en web), ça promet (en attente d'un test).
- [^] # Re: Informix 4G
  
  Posté par Cédric Pellerin le 06 juillet 2023 à 17:03. Évalué à 2.
  
  Et pour les plus anciens on a eu dBase II et III, Clipper puis Foxpro :)
  - [^] # Re: Informix 4G
    
    Posté par Claude SIMON (site web personnel) le 06 juillet 2023 à 18:25. Évalué à 3.
    
    Il y avait aussi ce qui s'appelait à l'époque Progress 4GL.
    
    Ils sont aussi passé au web depuis…
    
    Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
- [^] # Re: Informix 4G
  
  Posté par Christophe B. (site web personnel) le 07 juillet 2023 à 10:45. Évalué à 2. Dernière modification le 07 juillet 2023 à 10:48.
  
  Dans les années 90 c'était la révolution des "langages de 4eme génération" : L4G
  avec même des concours pour se confronter au COBOL
  
  Le L4G Adonix très spécialisé dans l'info de Gestion, édité par la sté SPEMI et pondu par Bertrand YVINEC, Luc VERNA et Freddy SALAMA était très innovant pour l'époque.
  
  Tous des Joueur de Bridge, Freddy tenait même la rubrique "Bridge" du regretté Magazine "Jeux et Stratégie"
  
  Une des premières applications avait été de gérer les tournois de Bridge :)
  
  Puis c’est devenu SPEMI qui est devenu ADONIX, avec notamment l'ERP ADONIX ENTREPRISE qui est à l'origine de SAGE X3
  
  Toute une époque !
# Superbe projet

Posté par BohwaZ (site web personnel, Mastodon) le 07 juillet 2023 à 00:05. Évalué à 4.

Je trouve l'idée et l'application excellente, même si je ne vois pas trop comment utiliser ça pour le moment :)

Mais sur le fond je suis complètement d'accord, je déteste les ORM, je ne comprends pas l'intérêt de réécrire une requête SQL, mais en Java, en PHP, ou autre, avec une surcouche qu'on ne maîtrise pas et dont on ne sait pas s'il ne va pas créer des requêtes toutes pourries. Alors que faire du SQL en direct ben c'est simple, lisible et portable.

Pour revenir sur tricount, il existe une super alternative libre, qui peut être installée sur le téléphone en webapp et qui fonctionne même hors ligne : https://splittypie.com/

« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
- [^] # Re: Superbe projet
  
  Posté par lovasoa (site web personnel) le 07 juillet 2023 à 09:58. Évalué à 2.
  
  Je ne connaissais pas splittypie, merci pour la découverte !
  
  Moi j'ai plein d'idées de trucs à faire avec SQLPage… Je pense que mon prochain journal va être sur un taptempo en SQL, parce que je trouve l'idée très marrante !
- [^] # Re: Superbe projet
  
  Posté par steph1978 le 07 juillet 2023 à 17:29. Évalué à 4.
  
  Super projet en effet, c'est clean
  
  Je partage le sentiment qu'il y a trop de couches à gérer manuellement dans les applications web dites "modernes". Et qui dans une grande majorité des cas n'apporte pas de valeur, seulement de la complexité. Je pense que cela titille pas mal de développeurs.
  
  Les ORM sont une plaie à utiliser et à débugger. J'ai subit Hibernate en début de carrière. Aujourd'hui j'utilise Ecto qui est un peu plus maîtrisable et qui permet d'écrire du SQL directement en Elixir et donc de bénéficier de l'aide du compilateur et d'avoir un langage de programmation généraliste et plutôt agréable.
  
  Mais quitte a écrire du SQL alors en effet pourquoi pas l'utiliser pour tout!
  
  Je ne sais pas si un développement en SQLApp peut passer à l'échelle. Cela demande de changer de mindset ; utiliser les vues par exemple. Mais c'est super pour un PoC ou une application simple.
  
  Ce qui va être rapidement indispensable c'est de pouvoir gérer les droits (admins, membre, visiteurs) et donc l'authentification (OAuth2) sinon le nombre de cas d'usage va être très restreint, surtout en entreprise.
  - [^] # Re: Superbe projet
    
    Posté par lovasoa (site web personnel) le 07 juillet 2023 à 18:11. Évalué à 4.
    
    À propos de sveltebase: j'adore svelte, mais ça demande quand même de mettre en place toute une stack de développement web. C'est fatiguant, et ça s'adresse à une audience qui est déjà familière avec le développement web…
    
    Pour le passage à l'échelle: c'est vrai que ça demande de faire une structure de base de données propre, définir des vues propres… Mais je pense que ça en vaut la peine. Si l'application marche bien et que l'on décide de passer à un framework backend traditionnel sur le long terme, ce travail ne sera pas perdu, et on gagnera du temps et s'évitera de la complexité dans le code.
    
    Pour l'authentification: effectivement, c'est la priorité pour la prochaine version. En attendant, on peut le gérer manuellement en postgres, je suis en train de rédiger un exemple sur le dépôt: user-authentication example.
    - [^] # Re: Superbe projet
      
      Posté par Luc-Skywalker le 07 juillet 2023 à 18:55. Évalué à 2.
      
      Tout cela me semble très pertinent, astucieux et efficace.
      
      En effet la structuration et les outils de manipulation et de vue des données sont en place rapidement. Une bonne partie du boulot est déjà fait si l'on souhaite accéder aux données avec une autre application.
      
      Je vais essayer de tester ça rapidement.
      
      "Si tous les cons volaient, il ferait nuit" F. Dard
      - [^] # Re: Superbe projet
        
        Posté par lovasoa (site web personnel) le 07 juillet 2023 à 20:23. Évalué à 3.
        
        Je viens de terminer le premier exemple de gestion d'utilisateurs et d'authentification entièrement en SQL avec PostgreSQL.
- [^] # Re: Superbe projet
  
  Posté par barmic 🦦 le 08 juillet 2023 à 00:40. Évalué à 3.
  
  Tu fais de la merde en ORM si tu ne comprends pas SQL, tu fais de la merde en SQL si tu ne comprends pas ton query planner, tu fais un code natif de merde si tu ne comprend pas ton CPU, tu fais code non natif de merde si tu ne comprends pas ta vm, tu fais du web de merde si tu comprends pas le navigateur,…
  
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: Superbe projet
    
    Posté par lovasoa (site web personnel) le 08 juillet 2023 à 13:32. Évalué à 5.
    
    Le problème n'est pas vraiment que tu fais "de la merde", mais que la majorité du temps, tu ne fais juste rien du tout. Aujourd'hui, il y a tellement de technologies différentes à maîtriser pour créer une application web qui respecte les standards de développement modernes, que c'est devenu tout simplement hors de portée pour la majorité des gens qui n'ont pas des années d'expérience dans le domaine et dont ce n'est pas le métier.
    
    Au début du web, on voyait beaucoup plus souvent de simples amateurs débrouillards avec une bonne idée construire eux-mêmes ce qu'ils voulaient.
    
    L'alternative moderne pour les débrouillards non-experts avec une bonne idée, ce sont les outils no-code comme bubble ou webflow. Mais c'est une grosse régression par rapport à ce qui existait avant: ces applications propriétaires emprisonnent leurs utilisateurs dans leur modèle, d'une manière qui rend très difficile d'en sortir plus tard.
    
    Ce que SQLPage propose, c'est de redonner du pouvoir à tous ceux qui n'ont pas des années d'expérience avec les outils de développement web modernes, mais qui ont une bonne idée et qui veulent en faire une application dans la journée. Et sans se fermer des portes pour plus tard en s'enfermant dans une technologie propriétaire.
    - [^] # Re: Superbe projet
      
      Posté par Moonz le 08 juillet 2023 à 14:58. Évalué à 6.
      
      Aucun des outils qui existaient à cette époque n’a disparu. Tu peux toujours faire des pages PHP sans framework ni ORM. Simplement, quand tu écris pour la 56e fois une variante autour de $product = mysql_fetch_assoc(mysql_query("SELECT * FROM products WHERE product_id = " . $_GET["product_id"])), un moment si tu n’es pas stupide tu te rends compte qu’un outil qui t’automatise ça (et qui te permet d’éviter les injections SQL… comme celle que je viens d’introduire. Cher lecteur, t’en es-tu rendu compte ?), c’est utile. D’où le concept d’ORM.
      
      Je suis d’accord sur le fait que le dev web aujourd’hui est complexe. Mais c’est globalement parce que les standards ont augmenté, et ce sur tous les axes (UX, DX, opérationnel). Développer sans framework ni ORM est tout à fait possible et je dirai même souhaitable, pour un débutant, à condition de garder en tête que c'est pour apprendre les bases nécessaires, que cette méthode a de sérieuses limitations, et qu’il faudra un moment "step up" (l’étape n°1 est souvent d’écrire un framework maison pour comprendre l’intérêt d’un framework, l’étape n°2 est de se rendre compte qu’il existe probablement des frameworks existants mieux faits que le framework maison).
      
      Et ce sera ma première grosse critique de SQLpage : il ne m’a pas l’air d’offrir de chemin naturel vers cette évolution. SQL est une horrible base pour ça. SQL est un langage important pour le développement web que tout développeur expérimenté se doit de connaître ; pour autant 90% (à la louche et en étant extrêmement généreux) de l’usage de SQL dans une application moderne se fait via un ORM/QB (et ce pour de très bonnes raisons).
      - [^] # Re: Superbe projet
        
        Posté par lovasoa (site web personnel) le 08 juillet 2023 à 15:49. Évalué à 3. Dernière modification le 08 juillet 2023 à 15:52.
        
        Je ne voulais pas dire qu'il faudrait retourner maintenant aux outils de l'époque! Pour faire "à la main", en PHP, la même chose que l'on ferait avec SQLPage, il faudrait quand même au grand minimum passer quelques semaines à apprendre à utiliser Apache, PHP, SQL, HTML, et CSS. Et le résultat aura certainement l'air d'un site amateur, pas très pratique ni très joli, et avec des failles de sécurité XSS et SQLi (comme tu le mentionnes).
        
        J'ai l'impression que si le développement web d'aujourd'hui est si complexe, c'est surtout parce qu'il s'est développé par strates progressives au dessus d'outils historiques, plus que parce que le niveau d'attente des utilisateurs a augmenté. Et la professionnalisation du milieu a aussi poussé à la création d'outils "en silo", avec des outils très spécialisés et des équipes qui ne sont chacune expertes que d'une petite partie d'une application. C'est un modèle qui permet de faire des choses à une échelle qui était impensable autrefois, et dans lequel la complexité globale des systèmes pose moins de problèmes, puisqu'elle est répartie entre plusieurs équipes d'experts.
        
        Mais c'est aussi un modèle qui est subi par les créatifs, et les innovateurs qui n'ont pas beaucoup de temps, pas de connaissances pointues dans plusieurs langages de programmation, mais ont toujours de bonnes idées.
        
        Concernant le dernier point, vous écrivez ORM/QB, comme si c'était la même chose:
        
        sur les ORM: mon avis est qu'ils devraient tout simplement disparaître. C'est un sujet qui a été longuement discuté et étudié, et j'ai l'impression que le consensus est grandissant depuis plusieurs années déjà.
        
        Par contre, les constructeurs de requêtes (query builders) sont utiles. Mais contrairement à ce que vous semblez vouloir dire, passer d'une requête en SQL brut dans SQLPage à une requête construite avec un query builder n'est pas compliqué. On peut commencer par tout simplement copier-coller la requête brute, puis refactoriser au fur et à mesure, si le besoin apparaît.
      - [^] # Re: Superbe projet
        
        Posté par steph1978 le 09 juillet 2023 à 22:32. Évalué à 2.
        
        Heureusement qu'il n'est pas nécessaire de recourir à un ORM pour faire du nettoyage d'input.
    - [^] # Re: Superbe projet
      
      Posté par barmic 🦦 le 08 juillet 2023 à 16:25. Évalué à 3.
      
      Au début du web, on voyait beaucoup plus souvent de simples amateurs débrouillards avec une bonne idée construire eux-mêmes ce qu'ils voulaient.
      
      Si tu ne les vois plus c'est peut être moins parce qu'ils n'existent plus ou moins que parce que les moteurs de recherches te ressortent les plus gros sites et pas les millions de petits sites.
      
      L'alternative moderne pour les débrouillards non-experts avec une bonne idée, ce sont les outils no-code comme bubble ou webflow. Mais c'est une grosse régression par rapport à ce qui existait avant: ces applications propriétaires emprisonnent leurs utilisateurs dans leur modèle, d'une manière qui rend très difficile d'en sortir plus tard.
      
      Il y a des milliers de façon de faire le no-code, le low-code, le statique, le j'écris du python ou le langage que je veux et ça fait de la magie, du wordpress et consort, des petites idées comme SQLPage,… Il y a plus de façons d'écrire du web que n'importe quel autre domaine. C'est très bien chacun prend l'approche qui lui plaît le plus.
      
      Je ne dirais toute fois pas que sqlpage est LA solution. C'est une solution pour les fans de SQL de faire quelque chose (de la même manière qu'on a un autre journal qui parle de faire du sql avec des onglets par exemple).
      
      La question de est-ce que c'est bien ou pas n'a pas de sens. C'est foisonnant et c'est très bien. Ça plaît à des gens, c'est parfait. Il n'y a pas besoin de casser du sucre sur le dos des autres façons de faire pour dire que ça répond à un besoin et que c'est cool.
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
- [^] # Re: Superbe projet
  
  Posté par ff9097 le 09 août 2023 à 14:51. Évalué à 2.
  
  Mais sur le fond je suis complètement d'accord, je déteste les ORM, je ne comprends pas l'intérêt de réécrire une requête SQL, mais en Java, en PHP, ou autre, avec une surcouche qu'on ne maîtrise pas et dont on ne sait pas s'il ne va pas créer des requêtes toutes pourries
  
  N'importe quel ORM te permet de logger les requêtes SQL générés
# outil DB Browser for SQLite

Posté par vev le 07 juillet 2023 à 11:12. Évalué à 3.

Je partage cet outil: https://sqlitebrowser.org/
- [^] # Re: outil DB Browser for SQLite
  
  Posté par steph1978 le 07 juillet 2023 à 17:36. Évalué à 3.
  
  Je l'utilise depuis toujours.
  Rien à envier à un DBBeaver ou un SquirelSQL si ce n'est qu'il ne gère que du SQLite.
  Surtout beaucoup plus léger.
  
  Je l'avais ouvert en // de faire le tuto proposé par l'OP. Ça permet de voir ce qui se passe dans la base tant que toutes les fonctionnalités ne sont pas là.
  - [^] # Re: outil DB Browser for SQLite
    
    Posté par lovasoa (site web personnel) le 07 juillet 2023 à 17:54. Évalué à 3.
    C'est vrai que c'est pratique !
    
    Un petit truc, qui n'est pas (encore) documenté: on peut à n'importe quel endroit remplacer le nom d'un composant par 'debug' pour voir les données qui lui sont passées.
```
SELECT 'shell' AS component, 'Users' AS title;

SELECT 'list' AS component, 'Users' AS title;
SELECT username AS title, 'user' AS icon FROM user_info;
```
```
SELECT 'shell' AS component, 'Users' AS title;

SELECT 'debug' AS component, 'Users' AS title;
SELECT username AS title, 'user' AS icon FROM user_info;
```
  - [^] # Re: outil DB Browser for SQLite
    
    Posté par Luc-Skywalker le 07 juillet 2023 à 18:45. Évalué à 1.
    
    sqlite est génial, sqlightbrowser est génial. Et le projet présenté à l'air bien sympa aussi.
    
    Question de noob, l’exécutable se lance tel quel ou il a besoin de bibliothèques spécifiques ?
    
    "Si tous les cons volaient, il ferait nuit" F. Dard
    - [^] # Re: outil DB Browser for SQLite
      
      Posté par lovasoa (site web personnel) le 07 juillet 2023 à 20:19. Évalué à 3. Dernière modification le 07 juillet 2023 à 20:20.
      
      Non, l'exécutable ne dépend de rien d'autre que libc, qui devrait être disponible par défaut quelle que soit votre distribution. SQLite est compilé statiquement (il est inclus dans le programme distribué), donc il n'y a rien à faire. Vous pouvez juste télécharger l'exécutable et le lancer.
      - [^] # Re: outil DB Browser for SQLite
        
        Posté par Luc-Skywalker le 07 juillet 2023 à 23:02. Évalué à 2.
        
        Merci. Je viens de le télécharger, et ça marche tout seul en effet. (Super). Je vais prendre un peu plus de temps ultérieurement pour explorer plus en détail.
        
        Mais déjà je remarque:
        
        qu'en tâche de fond, le logiciel n'est pas trop gourmand (Super aussi).
        
        qu'il y a du handelbars pour générer du HTML rendu côté client (cool, ça va me rappeler de vieux souvenirs)
        
        que le front end est plutôt joli par défaut (cerise sur le gâteau :-)
        
        Le billet ici, l'application et la démo installée par défaut, le site, le dépôt Github; franchement, bravo pour le boulot.
        
        Comme je n'ai pas trop envie de me plonger dans le code source, là maintenant, je me permets une autre question de noob:
        
        Prenons le cas d'un menu de navigation. On voit bien la requête SQL pour obtenir les items. Est ce que le composant "List" suffit (associé éventuellement avec un fichier handelbars qui va bien pour rendre un menu déroulant horizontal par exemple que l'on pourrait passer en paramètre quelque part, voire sinon, juste une simple classe css), ou alors il faut écrire son propre composant (en RUST j'imagine du coup - que je ne connais absolument pas et qu'il faudra sans doute compiler-) + la vue handelbar associée ?
        
        "Si tous les cons volaient, il ferait nuit" F. Dard
        
        [^] # Re: outil DB Browser for SQLite
        
        Posté par lovasoa (site web personnel) le 08 juillet 2023 à 01:40. Évalué à 5.
        
        Pour créer son propre composant, on met juste un fichier .handlebars dans une dossier que l'on appelle sqlpage/templates. Pas besoin de recompiler sqlpage, pas besoin d'écrire du rust.
        
        Pour faire un menu simple en haut des pages, on peut utiliser le composant shell.
        
        Par exemple, la page principale du site officiel commence par
        
        select 'shell' as component, 'SQLPage' as title, 'database' as icon, '/' as link, 'get started' as menu_item, 'documentation' as menu_item;
        
        ce qui donne
        
        et sur mobile
        
        puis quand on ouvre le menu
        
        Ensuite on peut créer ses pages get started.sql et documentation.sql.
        
        SQLPage essaye d'encourager l'utilisation et la composition de composants préexistants plutôt que le définition de nouveaux composants. C'est cela qui permet de se concentrer en priorité sur la fonctionnalité de son site plutôt que son aspect visuel, et de programmer un site extrêmement rapidement.
        
        [^] # Re: outil DB Browser for SQLite
        
        Posté par Luc-Skywalker le 08 juillet 2023 à 08:17. Évalué à 2.
        
        Top ! Merci
        
        "Si tous les cons volaient, il ferait nuit" F. Dard
    - [^] # Re: outil DB Browser for SQLite
      
      Posté par steph1978 le 08 juillet 2023 à 00:24. Évalué à 3.
      
      C'est énervant, ça marche même sous windows. Je l'ai testé au taf.
      C'est bien pour ça Rust (comme Go et Zig), ça cross compile facilement.
      - [^] # Re: outil DB Browser for SQLite
        
        Posté par lovasoa (site web personnel) le 08 juillet 2023 à 01:43. Évalué à 2.
        
        La version windows est compilée sur une vraie machine (virtuelle) windows, pas cross-compilée 😬
        
        https://github.com/lovasoa/SQLpage/blob/main/.github/workflows/release.yml#L18
# Bel outil

Posté par gwado le 09 juillet 2023 à 23:04. Évalué à 3. Dernière modification le 09 juillet 2023 à 23:05.

Bonjour,

Lovasoa, juste bravo, déjà. J'aime ton approche du web comme outil (affichage de texte, médias et formulaires) et non comme marché (énième framework).
SQLPage est extrêmement simple (un seul fichier), il permet de faire du web rapidement et de manière durable en se concentrant sur le contenu.

Comme dit plus haut, le foisonnement des outils proposés est une excellente chose, l'existence de SQLPage y a toute sa place parce qu'il semble remplir une case vide (celle de la réelle simplicité) parmi la multitude d'outils de développement.

Pour autant, on ne peut pas (encore ?) téléverser de fichiers. ;)
- [^] # Re: Bel outil
  
  Posté par lovasoa (site web personnel) le 07 août 2023 à 21:59. Évalué à 2.
  Merci :) Effectivement, l'objectif de SQLPage est de se concentrer sur le contenu. Passer zéro secondes à étudier l'espacement entre deux boutons, mais se demander seulement:
  - quelle est la nature des données que je traite ?
  - quelle est l'information que je veux en extraire ?
  Je pense que ce sont les bonnes questions à se poser quand on commence un projet, qu'elles permettent d'avancer rapidement tout en garantissant une base solide à son projet et en ne se fermant pas de portes pour plus tard.
  
  Pour le support du téléversement, j'ai toujours bien en tête votre demande de fonctionnalité, c'est effectivement quelque chose qui permettrait d'étendre encore plus loin les possibilités de développement. Est-ce que vous avez une application concrète que vous voudriez développer et pour laquelle c'est bloquant ? N'hésitez pas à m'écrire en privé sur contact at ophir.dev.
# Matière à réflexion

Posté par rsn le 02 août 2023 à 17:50. Évalué à 4.

Un article sur developpez.com qui reprend et étend les arguments de l'auteur, en citant SQLPage, et qui m'a convaincu de revenir à cet article, entre-temps bien commenté, pour y jeter un oeil.

Pourquoi il faut repenser l'architecture logicielle pour les développeurs solo et les petites équipes, Yurii Rashkovskii estime que le modèle à trois niveaux freine le développement d'applications web

J'aime beaucoup l'idée aussi. Peut répondre à de nombreux cas d'usage.

Les problèmes d'évolution à mon avis ne sont pas pires qu'avec des gros framework farcis à l'ORM. Il faut considérer la "taille de l'organisation" qui utilise le logiciel et le cycle de vie du produit… Que souvent les organisations rechignent très souvent à mettre à jour. On se retrouve donc souvent à faire de grosses évol et à ce compte-là, souvent à envisager des réécritures complètes qu'on (client ou direction du presta) ne se permet que trop rarement à cause de tout ce que cela semble impliquer de plus qu'une "simple montée de version".

Et en complément, ce podcast édifiant sur la puissance des SGBD et leur avenir possible Mettre le feu aux bases de données « Le futur de la base de données passera par la convergence de leurs types (NoSQL/SQL, In-memory/Persistent, Transactionnel/Analytics) et l’exécution du code dans la base. » par M.Rongier où j'ai redécouvert que SQL était "Turing-complete", entre autres nombreuses choses.
- [^] # Re: Matière à réflexion
  
  Posté par lovasoa (site web personnel) le 07 août 2023 à 22:16. Évalué à 3.
  
  J'ai remarqué seulement hier que notre article avait été traduit et posté sur developpez.com! J'en suis très content, mais je pense que certains détails se sont un peu "perdus dans la traduction". J'ai parlé à Stéphane le calme qui a publié la traduction, et je vais proposer une petite note de clarification. À suivre, donc…
  
  Je pense que l'idée d'exploiter toutes les capacités des systèmes de gestion de bases de données modernes plutôt que de les utiliser comme un simple outil de stockage a beaucoup d'avenir. Yurii a la même vision, et je suis convaincu que dans quelques années, que ce soit à travers nos outils ou d'autres, la quantité d'efforts à déployer pour écrire et maintenir une application web interactive sera au moins divisée par 10.
  
  En attendant, j'ai déjà remarqué que le fait d'avoir SQLPage à disposition changeait réellement la frontière entre "tiens c'est une idée rigolote, mais la flemme de coder ça" et "oh oui, tiens, je vais faire ça cet aprèm pour voir"
  - [^] # Re: Matière à réflexion
    
    Posté par lovasoa (site web personnel) le 08 août 2023 à 18:02. Évalué à 2.
    
    La réponse a été publiée sur developpez.com sur sous le nom 3 solutions au problème des 3 couches
# Super !

Posté par Philippe Martin le 07 août 2023 à 18:52. Évalué à 2.

J'aime beaucoup ce concept de baser le plus gros du dév sur le SQL. Dans le même genre, j'ai travaillé pas mal d'années en me basant sur une lib perso qui permet d'appeler des fonctions PL/PgSQL depuis du code PHP ou Go : https://github.com/feloy/pgprocedures (PHP) et https://github.com/feloy/pgproc (Go)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.