lovasoa a écrit 158 commentaires

Voilà, c'est déployé : https://lv4cq4l44sce5attr3puax45rm0yiebw.lambda-url.eu-west-3.on.aws

C'est une instance de démo, sur laquelle aucune donnée ne persiste.

Ces captures d'écran me font venir une idée: Puisqu'il y a l'air d'y avoir des gens intéressés, @DSMejantel, est-ce que tu voudrais que je déploie une version de démo d'école inclusive, sans persistance et avec de fausses données, pour permettre à tout le monde de tester l'application ?

Avec un peu de chance, ça permettrait même de "crowdsourcer" facilement la recherche de vulnérabilités éventuelles dans l'application…

Si vous avez besoin d'aide pour vous lancer, n'hésitez pas à venir faire un tour sur le forum de la communauté SQLPage; les sqlpagers sont en général très ouverts et aidant, et aiment partager leurs projets et leurs idées!

Si je peux me permettre une petite pub pour un autre logiciel libre, chouette à utiliser sur ce genre de projets: SQLPage, et son composant map, est très pratique pour afficher des données d'une base PostGIS sur une carte, avec la possibilité de créer ses propres options de filtrages et de visualisation.

• Avantages: c'est beaucoup plus rapide à construire, plus simple à mettre en place et à maintenir.
• Inconvénients: c'est moins flexible que de tout réaliser à la main avec un backend sur-mesure en node et un frontend sur-mesure en vue.

Il y a eu une dépêche détaillée : https://linuxfr.org/news/ecrire-une-appli-web-en-une-journee-avec-sqlpage

Le protocole de communication avec SQL server est un peu complexe, mais il est bien documenté, et il est stable. De mon expérience pour le moment, il ne pose pas particulièrement plus de problèmes qu'un autre.

Et c'est un gros plus pour les utilisateurs de SQLPage de pouvoir juste télécharger le logiciel, et qu'il se connecte tout de suite à leur base de données, quelle qu'elle soit. Et l'utilisateur le plus actif sur le forum communautaire de SQLPage, f8dca, est d'ailleurs un utilisateur de SQL Server.

Si il n'y a pas de nouvelles fonctionnalités, et que les dépendances sont stables, c'est raisonnable.

C'est une bonne remarque. Pour un pilote indépendant cela signifie:

• soit beaucoup de travail de maintenance juste pour se tenir à jour, même quand les fonctionnalités ne changent pas
• soit d'obliger ses utilisateurs à rester sur une ancienne version de sqlx, qui peut elle-même avoir des problèmes de sécurité

Non, la décision avait été annoncée avant la scission.

Oui, on a le droit de le faire. Mais la question était plutôt: était-ce une bonne chose de le faire? Était-ce, dans ce cas, bénéfique?

Ce que je précise à la fin de la dépêche, c'est qu'il comptait publier un nouveau pilote sous licence AGPL. Libre donc, mais sous des conditions plus restrictives.

C'est vrai que je n'ai pas insisté dessus dans la dépêche, mais la nouvelle architecture de la bibliothèque rendait la migration difficile, et supprimait des fonctionnalités de l'ancienne version, qui n'étaient pas implementables dans un design où le cœur de la bibliothèque n'avait pas connaissance de la liste des pilotes.

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.

La réponse a été publiée sur developpez.com sur sous le nom 3 solutions au problème des 3 couches

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"

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.

Et si vous avez votre propre idée de site ou d'application web, évitez d'utiliser le genre de technos qui créent des sites énormes, lents, voire hostile.

Pour un petit site web ultra-léger et facile à faire, SQLPage est super !

Ce qui est intéressant, c'est justement que ce n'est pas du rust, mais du SQL !

La logique du serveur elle-même (ici, juste la redirection), est en SQL.

La logique bas-niveau est en rust, tout comme la logique bas-niveau de Python et de Bjoern est en C, mais ce qui est vraiment cool, c'est que l'on puisse avoir de super performances avec un langage de très haut niveau comme SQL.

Wouw, c'est tout de suite un autre ordre de grandeur !

Mais il y a quand même une grosse différence: ce serveur ne log rien du tout ! La version en SQL et celle en flask précédente affichaient une ligne de log dans la console pour chaque requête reçue.

Voilà donc une nouvelle comparaison, sur mon ordi, sans aucun logging dans aucune des applications:

Sans logging, on arrive à ~40 000 requêtes par secondes avec SQLPage.

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.

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.

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

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.

Je viens de terminer le premier exemple de gestion d'utilisateurs et d'authentification entièrement en SQL avec PostgreSQL.

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.