lovasoa a écrit 164 commentaires

Les boutons delete et edit pourraient être de minuscules formulaire qui envoient une requête post. Visuellement, on aurait toujours exactement le même résultat, ce serait compatible avec le code existant, mais on éviterait le problème que tu mentionnes. Motivé pour faire une petite PR ?

Le fichier à modifier serait: https://github.com/sqlpage/SQLPage/blob/main/sqlpage/templates/list.handlebars

Les infos utiles pour contribuer: https://github.com/sqlpage/SQLPage/blob/main/CONTRIBUTING.md

Honnêtement, pour ce genre d'applications, il n'y a pas de vrais problèmes avec le fonctionnement actuel.

Pour éviter de traiter des requêtes qui ne viendraient pas de la page qui contient le bouton de suppression, on peut générer un token csrf et l'inclure dans l'url de la page qui fait le DELETE. Mais je pense que pour ce genre d'application, c'est over-kill.

Oui, c'est un logiciel libre, tu peux télécharger les binaires directement depuis le site web, et même le compiler toi-même sur ta machine. Pas besoin de compte où que ce soit !

https://sql-page.com/your-first-sql-website/
https://github.com/sqlpage/SQLPage

Je pense que le but ici c'est de pouvoir tout faire simplement avec son navigateur, sans javascript, sans avoir à créer une API…

Oui, on peut stocker

• soit une data-uri dans la base de données (avec read_file_as_data_url),
• soit simplement le chemin du fichier enregistré (avec persist_uploaded_file).

Si, SerenityOS passe au second plan, et n'est pas concerné par le don de 1M$: https://awesomekling.substack.com/p/forking-ladybird-and-stepping-down-serenityos

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.