- Je l’utilise depuis environ un an, et j’ai migré vers EdgeDB autant de projets que possible
- EdgeDB est une base de données graphe/relationnelle construite au-dessus de Postgres
→ le moteur sous-jacent reste le même, mais du point de vue de l’utilisateur, tout a changé. Les plus grands changements concernent le langage de requête et l’outillage
Langage de requête
- EdgeDB n’utilise pas SQL mais son propre langage, EdgeQL, et c’est un véritable game changer
- Après l’avoir utilisé, je n’ai plus jamais eu envie de revenir à SQL
→ typage puissant, orienté objet, requêtes profondes très faciles, et une très bonne correspondance avec la manière dont les humains pensent les requêtes sur les données (personne ne réfléchit naturellement en termes de JOIN)
- Je n’étais déjà pas un grand fan de SQL auparavant, mais il n’y avait pas vraiment d’alternative
- Après quelques jours d’apprentissage et de pratique avec leur fantastique tutoriel au format livre, j’ai découvert que la modélisation de schémas de base de données pouvait être quelque chose d’agréable et de léger
→ la complexité de SQL a disparu, et j’ai réalisé à quel point SQL est inefficace et étrange en tant que langage de requête
- EdgeQL est facile à apprendre, et le quickstart ainsi que l’overview suffisent pour en maîtriser environ 80 %
- J’aime tellement EdgeQL que j’aimerais qu’il devienne un standard indépendant. J’aimerais par exemple voir apparaître quelque chose comme EdgeDBLite, qui permettrait d’utiliser EdgeQL sur une base de données orientée fichier
Outillage
- Il suit le modèle moderne du binaire unique capable de tout exécuter (comme Go ou Flutter)
→ installation et mise à jour du serveur, création/suppression de bases, REPL, migrations, sauvegardes et gestion de projet, etc.
→ et, dans la plupart des cas, « It Just Works »
- EdgeDB a réinventé la manière d’interagir avec une base de données
→ avec le concept de « Project », il se connecte automatiquement à la base et tout fonctionne sans se soucier du DSN ou de la configuration
→ comparé au fait de chercher pendant plus de 10 ans la commande SQL exacte pour donner les droits root sur localhost, c’est extrêmement rafraîchissant
Fonctionnalités
- Modélisation très simple des relations many-to-many
- GraphQL embarqué (connexion directe possible depuis le frontend)
- Propriétés calculées
rating := math::mean(.ratings.score)
- backlinks : remonter les liens à l’envers
→ select User.<author; recherche dans les tables liées à User via un champ nommé author
- uuid, collection, scalar, abstract et de nombreux autres types (mon préféré étant
cal::local_datetime)
- inheritance, constraints et d’autres choses impressionnantes comme l’introspection
Mon expérience jusqu’ici
- Je l’utilise depuis environ un an. J’ai d’abord migré un petit projet personnel, puis plus tard l’un des projets de mon entreprise
- La plupart de mes travaux sont de petits services pratiques destinés aux utilisateurs, ce qui me donne parfois le luxe de travailler seul et de pouvoir choisir l’outil le plus adapté
- Avec EdgeDB, l’expérience a surtout été du type « It Just Works »
- La plupart des informations se trouvent facilement, et la documentation est excellente, donc tout est simple à retrouver (honnêtement, c’est l’un des meilleurs sites de documentation que j’aie vus)
Est-ce adapté à la production ?
- Je l’utilise « en production » depuis l’automne dernier
- Certains donnent au terme « utilisé en production » plus de poids que le simple fait de « l’utiliser réellement », mais bon…
- J’ai dû légèrement adapter mes scripts d’automatisation lors du refactoring de l’outil en ligne de commande, mais ce n’était pas grave
- Mentalement, j’étais prêt à payer le prix du risque lié au statut d’early adopter, mais jusqu’ici je n’ai eu aucun problème
L’expressivité d’EdgeQL
- J’ai enfin arrêté de passer mon temps à chercher sur Google des solutions SQL, des limitations d’ORM et des façons de les contourner
- EdgeQL permet d’exprimer exactement ce que je veux obtenir de la base de données, et c’est réellement lisible et compréhensible (même par d’autres développeurs)
- Grâce à EdgeQL, on peut parfois même éviter les transactions. Il est possible d’effectuer plusieurs mises à jour imbriquées dans une seule requête.
→ « Simplicity is complicated »
Migrations
- L’un des aspects les plus remarquables est que la gestion des migrations est intégrée
- On modifie le schéma, on appelle
edgedb migration create, ce qui génère un fichier de migration,
puis il suffit d’exécuter edgedb migration apply sur le serveur pour l’appliquer immédiatement
- Les migrations sont chaînées par hash, ce qui évite d’en appliquer une aléatoirement et de tout casser
- Lors de la création d’une nouvelle migration, le mode par défaut est interactif, et toutes les modifications doivent être confirmées dans la ligne de commande
Performances
- Je ne traite pas de très gros volumes de données, donc je n’ai pas besoin d’une base de données ultra-performante
- Mais comme EdgeDB repose sur Postgres, cela ne pose pas de problème de performances par rapport à d’autres bases
- EdgeDB lui-même est écrit en Python (j’aurais préféré Go, mais les développeurs semblent plus familiers avec Python)
Bibliothèque cliente Go
- Comme j’utilise Go, j’apprécie l’existence d’une bibliothèque Go native pour EdgeQL
- Il existe des bibliothèques officielles pour Typescript/Javascript, Python et Go, tandis que .Net et Elixir sont pris en charge par la communauté
Mises à niveau
- EdgeDB abstrait la complexité des versions serveur et des mises à jour
- Le CLI EdgeDB s’en charge en grande partie automatiquement. S’il y a une nouvelle mise à jour, il la signale et procède à l’upgrade.
→ c’est étonnamment fluide
- La 2.0 RC est sortie, mais cela ne m’inquiète pas du tout. Mon expérience jusqu’ici me fait penser que tout se passera de manière sûre et simple
Communication et support
- En tant qu’early adopter, je suis très satisfait de la rapidité des réponses et de l’aide reçue sur les canaux officiels d’EdgeDB
EdgeDB 2.0
- La version 2.0, qui sort demain, ajoute de bonnes fonctionnalités
- EdgeDB UI : application web incluant un éditeur visuel de schéma, un REPL, etc.
- Group queries, variables globales de schéma, sécurité au niveau objet, Direct EdgeQL over HTTP, etc.
Ce que je n’aime pas ou ce qui m’inquiète
- La promesse de compatibilité
- Jusqu’ici, tout va bien. Les mises à jour mineures n’ont pas cassé la compatibilité
- J’aimerais qu’il y ait un engagement clair sur ce point
- L’ensemble de fonctionnalités qui continue de grandir
- Il y a déjà plus de fonctionnalités que ce que je recherche, et pourtant cela continue d’augmenter
- Plus EdgeQL devient puissant, plus la frontière entre base de données et serveur devient floue, au point de se demander : « Est-ce que ça doit aller dans le backend, ou dans un schéma de base de données intelligent ? »
- En utilisant un serveur HTTP embarqué, il semble raisonnable de pousser vers le remplacement complet du serveur backend dans la plupart des projets… mais moi, je veux surtout une base de données stable avec ce formidable langage de requête et ce moteur
- Quoi qu’il en soit, j’espère qu’EdgeDB restera stable et cohérent, sans accumuler trop de fonctionnalités. L’ensemble actuel est déjà excellent
Conclusion
- Pour mes futurs projets, je ne pense plus envisager les SGBD relationnels traditionnels
- Revenir à SQL, ce serait comme passer de Flutter à Ncurses, ou de Go à l’assembleur
- Pour moi, EdgeDB représente la plus grande avancée dans le domaine des bases de données depuis 20 ans
- Mon avis changera peut-être avec davantage d’expérience, mais après plus d’un an d’utilisation, rien n’est venu gâcher cet enthousiasme
- Plus je l’utilise, plus j’ai confiance en EdgeDB
- Tout ce que l’équipe EdgeDB a accompli avec EdgeDB lui-même, le langage, le site web, les outils et la communauté est extrêmement impressionnant
→ « Mad respect to the team »
- Et on dirait bien qu’ils ne font que s’échauffer
10 commentaires
Grâce à vous, j'ai découvert EdgeDB et je l'utilise avec satisfaction ! Merci~
On dirait qu’ils suivent une trajectoire similaire à Prisma. J’utilise bien Prisma, mais il y a pas mal de points décevants côté performances, donc les résultats du benchmark m’intriguent un peu.
La syntaxe n’est pas vraiment à mon goût non plus… (j’utilise aussi Protocol Buffers, et même les exemples de code de conversion sont un peu…)
Les autres, vous préférez ce type de syntaxe à la GraphQL ? Au final, le backend reste du RDS, donc il faudra bien faire une conversion au milieu ; si ce n’est pas clairement visible, j’ai tendance à être plutôt réticent…
Ce post m’a intéressé, donc je continue à l’étudier.
Cela dit, comme c’est encore assez récent, quand on se retrouve bloqué, il n’y a pas encore beaucoup de résultats de recherche.
Il y a bien un canal Discord, mais je me suis dit que ce serait bien que les développeurs francophones puissent poser leurs questions et y répondre plus facilement, alors j’ai créé un salon de discussion ouvert.
https://open.kakao.com/o/gtGY0Gve
J’ai aussi pris des notes parce que j’aimerais l’essayer.
Après avoir lu cet article et suivi le tutoriel jusqu’au bout, j’en suis encore plus convaincu.
Intéressant. On ne peut vraiment plus revenir à un monde sans SQL...
Ça m’intéresse.
Impressionnant !
Parmi les bases de données de type graphdb, je m'intéressais particulièrement à ArangoDB, mais je pense qu'il vaudrait aussi la peine de jeter un œil à EdgeDB.
C’est un éloge incroyable. Ils annoncent la 2.0 le 28/07 à 10 h (PT).
Sortie d’EdgeDB 1.0
EdgeDB - l’ORDB open source de nouvelle génération pour les développeurs