IMPORTANT : Proposition de migrer la Ğ1 sur une blockchain substrate

IMPORTANT : Proposition de migrer la Ğ1 sur une blockchain substrate

Bonjour à tous,

Avant de répondre à ce post, merci de prendre le temps de tout lire afin de bien comprendre mon point de vue.

Mon objectif long-terme est de contribuer à la mise en place d’une monnaie libre sécurisée, scalable (capable de monter en charge à grande échelle), fiable et robuste (byzantin résistant) avec un paiement le plus rapide et fiable possible et de la gouvernance on-chain pour que la gestion de cette monnaie soit la plus horizontale possible.

Nous ne sommes que 3 000 membres et déjà de plus en plus de problèmes techniques se font sentir avec Duniter, la synchro de la blockchain est déjà devenue quasi impossible, plusieurs anciens membres forgeron (dont @tuxmain) ne le sont plus à cause de ça. On a régulièrement des problèmes de transactions qui ne passent pas lors des ğmarchés, on l’a vécu encore ce week-end à l’université d’été.
Et je ne parle pas des problèmes de synchro des mempool qui transforment l’entrée dans la toile en un véritable parcours du combattant.

Duniter est une PoC (Preuve de Concept), écrite entièrement de zéro, dans un langage pas adapté à la montée en charge, par un développeur qui n’avait jamais développé de blockchain auparavant, et qui a donc fait un bon nombre d’erreur de design, que j’aurais faites aussi à sa place, c’est normal.

Le but n’est pas de critiquer mais d’expliquer pourquoi Duniter n’est plus gérable aujourd’hui et pourquoi il vaut mieux migrer au plus vite vers une autre solution.

@cgeek lui-même n’arrivait plus à faire évoluer Duniter facilement, il se sentait « pris dans la colle » me disait-il en privé il y a déjà quelques années. La Ğ1 a déjà quatre ans et demi, et en quatre ans et demi je suis le seul autre développeur à avoir réussi à rentrer substantiellement dans le code de Duniter, parce que j’avais beaucoup de temps et une motivation et béton armé.

Mais depuis des années je galère à essayer d’améliorer Duniter, et je constate depuis un certains temps que c’est infiniment plus de boulot d’essayer de retaper une vielle maison plutôt que de tout raser et en construire ure nouvelle.

Migrer entièrement Duniter en Rust me prendrait beaucoup trop de temps, et c’est seulement après migration que j’aurais pu apporter les nombreuses améliorations de protocole que je souhaite apporter depuis des années.
Je viens d’y passer un an à plein temps, et cette année à plein temps m’a permis de me prendre en pleine face toutes les limitations dues à l’état actuel de Duniter.

En parallèle de ça, cela fait longtemps que je me disais que ce serait bien que l’on trouve un framework qui puisse gérer pour nous certaines briques pour que l’on ai moins de choses à maintenir, pour que l’on puisse se concentrer sur notre cœur de métier : le dividende universel et la toile de confiance. Mais tous les frameworks que je trouvais ne permettais pas suffisamment de personnalisation pour qu’on puisse y implémenter notre cœur de métier, ou/et n’était pas mature ou/et pas suffisamment maintenu et utilisé.

Il y a trois mois, @nanocryk (avec qui je suis toujours en contact régulier depuis quatre ans), m’a fait découvrir le framework substrate. J’étais alors très sceptique, et convaincu que comme tous les autres frameworks ça n’irait pas pour nos besoins, que ce serait pas assez customisable, etc. J’ai creusé quand même, et plus je creusais plus j’étais surpris. C’est la première fois que je tombe sur un framework blockchain aussi customisable, qui ne limite pas ses utilisateurs avec des hypothèses trop fortes, et qui fournit un cadre d’abstraction aussi propre pour que l’on puisse se concentrer rapidement et efficacement sur notre cœur de métier.

La question a naturellement émergé dans mon esprit : « Serait-il possible techniquement de migrer la Ğ1 sur une blockchain substrate, et si oui, est-ce que ce serait compliqué ?».

J’ai donc décidé de creuser à fond la question de la faisabilité technique, me disant que ça ne servait à rien d’en parler ni de proposer quoi que ce soit tant que je n’étais pas certain de la faisabilité.

J’en ai conclu il y a deux semaines que oui c’est possible et je vois désormais exactement comment faire. Entre-temps j’ai continué à creuser, et j’ai même codé une petite PoC en un week-end ! non seulement c’est possible, mais en plus c’est facile !

Si j’étais encore au chômage, je pourrais recoder toute la logique métier nécessaire à la Ğ1 en seulement quelques semaines, comme j’ai repris un boulot à plein-temps, ça va me prendre 5-6 week-ends.

Une fois que j’aurais codé ça, on va lancer une monnaie libre de test (avec un taux c très élevé) avec trois validateurs (=membres forgerons) : @tuxmain, @poka et moi.

Grâce à cette monnaie de test, on va pouvoir développer ce qu’il faut côté client, c’est en fait les développements côté client qui vont prendre le plus de temps, ça va être le gros boulot de cet automne. Dès qu’on aura au moins un client près, on pourra déjà essayer de lancer une blockchain reprenant l’état de la Ğtest dans son bloc genesis.

Voici une ébauche d’une roadmap de migration possible, ce n’est qu’en proposition :

  1. Développement d’un runtime substrate qui gère le DU et la toile de confiance (déjà commencé)
  2. lancement d’une monnaie de test
  3. Développement d’au moins un client pour utiliser cette monnaie de test (Ğecko), si des dev d’autres clients veulent nous rejoindre ce serait génial, il y a des bibliothèques JS et Python très complètes pour faire un client d’une blockchain substrate.
  4. Développement d’un programme qui lit l’état d’une DB Duniter et produit une chain-spec pour substrate
  5. Lancement d’une 2ᵉ monnaie de test, qui reprend l’état de la ğ1-test dans son genesis.
  6. Tests intensifs de cette 2ᵉ monnaie de test
  7. Organisation d’une «fausse migration» de la Ğ1, un « essai à blanc », avec un admin central qui peut reset le réseau si besoin.
  8. Refaire des fausses migrations jusqu’à maîtrise parfaite du processus.
  9. Réaliser une pré-migration publique, en communiquant cette fois-ci auprès de toute la communauté et en lançant un appel à utilisateurs volontaires pour tester cette « fake Ğ1 », qui sera identique en tout point à la « nouvelle Ğ1 » à ceci près qu’un admin central pourra tuer le réseau. Avec bien sur gros warning rouge sur les clients indiquant que cette monnaie temporaire va disparaitre, ne vendez pas des vrais biens et services avec.
  10. Poser une date pour la vraie migration de la Ğ1, qui sera techniquement identique en tout point à la fausse migration publique, à l’exception de l’admin central qui ne sera pas présent.

Si on est suffisamment nombreux là-dessus, sachant que @tuxmain et @poka vont m’aider à fond, je pense qu’on peut réaliser ces dix étapes en six mois.

Si cette proposition est acceptée, je me chargerai de la maintenance minimale de Duniter le temps de cette transition.

Je comprends tout à fait que cela implique de quasiment tout refaire côté client, et je comprends que certains aient le sentiment qu’il s’agirait de renier des années de travail, moi-même je vais « jeter à la poubelle » des milliers d’heures de travail sur cinq ans.

D’une part, on n’a pas fait tout ça pour rien, on a appris, on est monté en compétences techniquement. Sur tout ce que vous avez appris pendant ces années de contributions, beaucoup de choses vous seront très utile dans le nouvel environnement technique.
D’autre part, servir l’objectif est le plus important, si jeter l’existant permet de beaucoup mieux servir l’objectif et beaucoup plus vite, alors moralement on se doit de le faire.
Enfin, il n’y a pas forcément besoin de tout jeter, certains outils pourraient rester avec assez peu de modifications (comme ğchange par exemple).

Développer avec substrate permet d’aller bien plus vite car plein de choses sont générées automatiquement à partir du code de notre protocole blockchain (grâce au système de typage évolué de Rust). Par exemple, substrate me génère automatiquement l’API RPC qui permet d’appeler les extrinsics que j’ai codé mais aussi de lire le storage que j’ai défini. Substrate gère également automatiquement les mempool et la couche réseau inter-nœud, je n’ai absolument rien à faire de ce côté !

Et même la logique métier du protocole lui-même, dans Duniter elle est répartie dans quatre endroits différents (génération d’un bloc, validation d’un bloc, application d’un bloc, synchronisation d’un bloc).
Dans substrate tout ça est remplacé par la notion d’exécution d’un bloc. L’exécution d’un bloc étant parfaitement déterministe à partir du code du runtime, pour le vérifié il suffit de l’exécuter.

En fait il y a plein de concepts de substrate long à expliquer qu’il faut étudier et comprendre pour comprendre à quel point ça permet d’aller beaucoup plus vite et avec un code beaucoup plus optimisé et sécurisé, je n’ai pas le temps de tout expliquer là, ça viendra au fur et à mesure dans les semaines et mois à venir, je ferai au moins une conférence pour expliquer une partie de tout ça (voir plusieurs).

Je comprends que ma proposition chamboule tout, mais si je propose de migrer la Ğ1 sur substrate c’est parce que je pense sincèrement que c’est ce que l’on a de mieux a faire pour fiabiliser et pérenniser la Ğ1.

Il ne m’a fallu que trois jours pour développer une blockchain substrate qui gère déjà le Dividende Universel et les identités (sans certifications pour le moment) :

Dépôt de la poc : https://git.duniter.org/nodes/rust/lc-core-substrate
Vidéo démo de la poc : kDrive

Une évidence que je n’ai pas dit dans la vidéo : le client que j’utilise est réservé aux développeurs et testeurs avancés, c’est plus une sorte de postman amélioré, ce n’est évidemment pas destiné aux utilisateurs lambda !

Les prochains week-ends je vais implémenter les certifications, écrire plus de tests pour fiabiliser tout ça (oui j’en ai déjà écrit quelques-uns), et préparer ce qu’il faut pour lancer une première monnaie de test avec @tuxmain, @poka et tous ceux qui voudront :slight_smile:

Côté client, il y a des bibliothèques officielles pour JavaScript, Python, Go, Rust, etc :

Une fois la monnaie de test lancée, on va travailler sur ğecko avec @poka (et peut-être @tuxmain s’il veut bien nous aider sur le binding Rust), pour avoir un client qui fonctionne avec cette nouvelle blockchain.

Je pense en profiter pour pousser quelques changements de protocole en même temps, j’en dirai plus dans d’autres sujets dans les semaines à venir :slight_smile:

31 Likes

De mon côté, sachez bien que cela ne pose aucun problème. Je n’ai jamais fait Cesium en pensant qu’il durerait déjà aussi longtemps :slight_smile: Par ailleurs j’avais déjà prévu de le réécrire (Cesium 2).

C’est vrai que la promesse est alléchante : plus de rapidité, de scalabilité, de maintenabilité, etc. Ca vend bien le truc :slight_smile:

Il faudra cependant garder (idéalement) toutes les fonctionnalités utiles, sans rien perdre. Par exemple, les graphiques génèrés par Cesium utilisent les Pod Cesium+ (en cours de réécriture - c’est le bon moment !) ; Wot Wizard utilise la BDD d Duniter 1.7, etc. WotMap utilise je ne sais quoi. Bref, beaucoup d’outils sont liés à Duniter… il faudra donc les adapter, ou les réécrire…

Je penses aussi pouvoir vous aider autant que je peux, sur les clients ou en faisant tourner des noeuds.
Cependant, je trouves que ces délais sont très (mais alors très) optimistes. Tant mieux si on y arrive, mais je trouve plus sage d’annoncer plus long. J’ai besoin d’avancer sereinement, et de batir sur le long terme.

D’un autre côté, c’est vrai que maintenant nous avons déjà des ergonomies déjà existantes en tête, et donc que les différentes notions seront plus faciles à coder, car nous avons des repères à reprendre ou améliorer. Egalement, les technos clientes ont aussi beaucoup progressé, ce qui facilite la réécriture.
J’ai déjà plein d’idées que j’aimerai réaliser dans Cesium² (mode déconnecté, full P2P, etc.).

L’idéal pour moi est de pouvoir disposer régulièrement de version exécutable, pour ne pas coder dans le vide, mais je ne suis pas inquiet la dessus (tu as déjà publier du code testable sur Substrate).

Sinon, je penses qu’avoir plusieurs clients restent une bonne idée. Chaque développeur est plus libre pour coder en suivant ses propres idées ergonomiques, et malgré tout on avance en se motivant aussi. Par ailleurs on peut reprendre les idées des autres clients que l’on aime bien, etc. Bref, ca fait foisonner les idées, et cela encourage.

Petite question : est-il possible de faire une API graphQL, par dessus l’API générée par Substrate ? GraphQL étant très agnostique, ca me parait jouable, non ? A moins que les lib clientes Substrate soient vraiment complètes et performantes ? Je vais regarder ca dans les prochains jours.

Allez hop, faut que je me remette au boulot pour coder ! Dur dur mais je lâcherai rien, pour aider la monnaie libre :slight_smile:

15 Likes

Je vois qu’il ya déjà des “explorer” (écrit en python) compatible avec les chains Substrate, comme ici : https://polkascan.io/ Il y a quasiment tout ! Sympa !

EDIT : par contre certains graphiques sont super lents… enfin je trouve

5 Likes

Oui, as-tu vue sa dernière vidéo ?

Je suis en cours.

Ok, j’ai vu la démo. C’est juste énorme !
Le code a l’air hyper condensé, retiré de toutes les dimensions de gestion de blocs, gestion réseaux, API, etc.
C’est effectivement assez bluffant… j’attends avec impatience la suite !

2 Likes

Oui bien entendu c’est le but :slight_smile:

Je comprends tout à fait ta réaction, j’aurais la même si je ne connaissais pas substrate, il met en place tout un tas d’outils et de concepts qui permettent d’aller très vite !

Oui c’est l’idée, je vais itérer régulièrement :slight_smile:

L’API RPC exposée par substrate est bien plus performante que du GraphQL, c’est déjà optimisé à mort, ils ont carrément créé leur propre codec pour ça, c’est utilisé en prod par des grosses cryptos qui doivent gérer des millions d’utilisateurs, dont en tête polkadot qui est dans le top 10 des cryptos-monnaies les plus ulilisées.

Perso je ne vais pas faire d’API GraphQL, mais je crois que @tuxmain avais vu un projet qui permet de générer une API GraphQL pour substrate, si c’est facile à intégrer alors pourquoi pas.

Exactement, c’est tout l’intérêt, on aurait plus besoin de gérer ces parties-là :slight_smile:

6 Likes

Non c’est @ManUtopiK avec Hasura (qu’on utilise pour générer l’API de Discourse en graphql désormais, en dev) !

:slight_smile:

2 Likes

J’ai fais ce pad ya 10j avec quelques infos intéressantes:

https://pad.p2p.legal/s/axiom_substrate-infos

Notamment le client substrate sur mobile: https://polkawallet.io
C’est du Flutter/dart !! GitHub - polkawallet-io/app: [Main] Polkawallet app.

2 Likes

Effectivement, j’ai lu la doc de l’API Js et cela a l’air très efficace et simple.
Reste a voir comment faire ce que gère en plus les lib GraphQL (le cache notamment)

3 Likes

Je trouve l’idée et le chemin à parcourir très bien détaillés et tout à fait respectables !
J’ai été développeur mais dans une autre vie … Fortran, Cobol, …
Je suis maintenant sous Linux avec très peu de compétences mais je sais tester et tester à fond !
Si je puis vous aider en quoi que ce soit, notifiez moi :slight_smile:
Bravo à tous ceux qui se mettent et vont se mettre à la tâche et un grand MERCI par avance !
PS: pensez à nous indiquer la clé publique de don à vous faire pour vous soutenir :wink:

9 Likes

Le compte pour les contributeurs techniques: 78ZwwgpgdH5uLZLbThUQH7LKwPgjMunYfLiCfUCySkM8

4 Likes
2 Likes

Très bon ! C’est une excellente proposition qui va dans le sens de l’histoire.

Tous les bons projets durables passent forcément par des étapes de refonte, pour adapter la solution aux innovations. C’est ainsi que Mozilla a carrément créé le RUST pour ensuite recoder Firefox, il est donc tout à fait cohérent d’envisager de recoder le logiciel Ğ1 en Rust, et de bénéficier de l’apport considérable des développements Rust déjà réalisés par la communauté du Libre.

Substrate est un framework écrit en RUST, ce qui démontre la robustesse et l’engouement autour de RUST, qui est 1°) Rassurant en terme de pérennité et 2°) Peut générer l’intérêt et l’engagement des développeurs anciens et nouveaux pour le projet qui leur permettra aussi de développer leurs compétences sur un outil potentiellement très porteur.

Une preuve en est que Jbar est intéressé, ce qui est déjà en soi la démonstration que la piste est très prometteuse !

C’est aussi l’occasion de regrouper autour de cette nouvelle étape de nouveaux développeurs enthousiastes à l’idée de développer la monnaie libre, et l’occasion pour les anciens de regrouper les compétences autour d’un langage de programmation commun.

Cela pourrait ainsi être aussi l’occasion de mettre en place une plus grande cohérence globale en terme de langage fondamental, sur un plus grand ensemble des outils dédiés à la Ğ1.

C’est enthousiasmant !

15 Likes

@elois Est-ce que tu as étudié d’autres frameworks pour blockchain ? Je pense notamment à Exonum en Rust, mais il y en a d’autres en open source : Hyperledger, Openchain, Graphene, Corda, MultiChain…
C’est juste pour savoir. Une réponse oui/non me conviendra très bien :slight_smile:
De plus, le fait que tu travailles pour Parity est évidemment un gros point positif à prendre en compte dans la balance.

Aussi, j’avais une question qui s’est noyé dans une autre discussion :
Est-ce que polkadot-js sera utilisable en l’état ou est-ce qu’il faudra réimplémenter une api client spécifique à nos besoins (certifs,…) ?

@kimamila Pour du graphql, il y ce dépôt qui utilise Hasura. J’utilise Hasura depuis plus de 2 ans et c’est vraiment un outil génial. Je ne sais pas du tout ce que vaut l’intégration avec substrate. A tester…
Par contre, Hasura permet de merger plusieurs api graphQL, donc on pourrait implémenter notre propre api spécifique (gestion des certifs par ex) et l’intégrer à Hasura pour ne plus avoir qu’un seul endpoint graphql. C’est ce que je fais généralement en utilisant fastify/mercurius pour créer mon api spécifique…

2 Likes

De ce que j’ai lu, les “palettes” spécifiques sont accessibles directement dans l’API client RPC.
En fait c’est configurable avec le fichier JSON dont elois parle dans sa vidéo. Ce sont les déclaration des fonctions et types et méthodes exposées.

A priori c’est du PostgreSQL derrière, qui indexe les données à partir d’un noeud.
Je risque de regretter un peu ElastiSearch, en terme de perf :frowning:

Autre point à voir : la question de la compatibilité P2P des libs cliente Substrate. De ce que j’ai vu ici, l’API JS communique avec un seul noeud.
Pour ne pas retomber sur les travers actuels, comment faire pour :

  • répartir la charge sur le réseau ?
  • garantir que le noed requetés est à jour.

Je continue à creuser…

5 Likes

Je pense aussi, d’autant que des développeurs expérimentés sur substrate il y en a, j’en connais quelques uns :smiley:

Oui ça fait des années que je regarde plein de framework blockchain, j’avais nottament regardé Exonum, Hyperledger et Openchain, il n’y en à aucun qui arrive ne serait-ce qu’a la cheville de substrate par rapport à mes critères, qui sont:

  1. Doit être suffisamment customisable pour qu’on puisse l’utiliser sans le forker (rien que ce critère exclu déjà 80% des framework blockchain)
  2. Doit être ready to production (mature)
  3. Doit être maintenu par une entité ayant suffisamment de visibilité pour le maintenir sur le long terme, et donc doit être déjà massivement utilisé, notamment par des gros projets, pour garantir que ça va pas mourir dans 3 ans.
  4. Doit apporter suffisamment d’avantages pour que le « coût » d’une migration en vaille la chandelle.
  5. Dois fournir le plus possible de briques que l’on peut reprendre tel quel
  6. Dois être écris dans un langage performant et fiable

Outre ces critères, substrate apporte de nombreux concepts très puissant que je n’ai vu nulle part ailleurs, comme la notion de runtime wasm qui peut être mis à jours de manière forkless, y a plein de notions puissantes dont je vous ai pas encore parlé, car je suis lent pour structurer ma pensée à l’écrit, ça viendra au fils du temps, mais le format vidéo est plus rapide pour moi, je pense donc faire d’autres vidéos ainsi que des visios :slight_smile:

Alors je bosse pas pour Parity, mais pour une boite qui développe un gros projet sur substrate oui (bien plus gros et plus complexe que Duniter). Donc je dois de toute manière monter en compétences sur substrate dans le cadre du boulot UNL, ça me permet de faire d’une pierre deux coups.

Rien n’empêche de développer un serveur proxy ElastiSearch qui lui même tape l’api RPC de substrate pour indexer les données. Comme le font les pod Cs+ avec Duniter.

Tout comme on pouvais faire un client multi-nœud basé sur l’API BMA ou GVA, ou peut tout à fait faire un client multi-noeud basé sur l’API RPC de substrate, et c’est ce qu’on va essayer de faire dans ğecko.

On peut facilement customiser l’API RPC: https://substrate.dev/recipes/custom-rpc.html
Donc on peut très bien y ajouter ce qu’il faut pour récupérer une liste de nœuds connus, etc :slight_smile:

Bref on peut faire ce qu’on veut, on est pas limité (sauf par le temps de vie dont on dispose) ^^

1 Like

J’ai gratté vite-fait un conteneur qui a l’air de se lancer :

$ docker run --rm -it --entrypoint lc-core lc-core-substrate
2021-07-15 21:32:25 Substrate Node    
2021-07-15 21:32:25 ✌️  version 3.0.0-unknown-x86_64-linux-musl    
2021-07-15 21:32:25 ❤️  by Substrate DevHub <https://github.com/substrate-developer-hub>, 2017-2021    
2021-07-15 21:32:25 📋 Chain specification: Local Testnet    
2021-07-15 21:32:25 🏷 Node name: uncovered-shop-7452    
2021-07-15 21:32:25 👤 Role: FULL    
2021-07-15 21:32:25 💾 Database: RocksDb at /root/.local/share/lc-core/chains/local_testnet/db    
2021-07-15 21:32:25 ⛓  Native runtime: lc-core-100 (lc-core-1.tx1.au1)    
2021-07-15 21:32:25 🔨 Initializing Genesis block/state (state: 0x1977…6482, header-hash: 0xead5…6f97)    
2021-07-15 21:32:25 👴 Loading GRANDPA authority set from genesis on what appears to be first startup.    
2021-07-15 21:32:25 ⏱  Loaded block-time = 6s from block 0xead586daa5151fc8b7ef3e8cca37bd2dafe27e7eb477438d526b77a8a70b6f97    
2021-07-15 21:32:25 Using default protocol ID "sup" because none is configured in the chain specs    
2021-07-15 21:32:25 🏷 Local node identity is: 12D3KooWLGWZXa8GGrqUQwLbGFsDmSZyhfMZAGtFzQefHpjuFRv3    
2021-07-15 21:32:25 📦 Highest known block at #0    
2021-07-15 21:32:25 〽️ Prometheus server started at 127.0.0.1:9615    
2021-07-15 21:32:25 Listening for new connections on 127.0.0.1:9944.    
2021-07-15 21:32:30 💤 Idle (0 peers), best: #0 (0xead5…6f97), finalized #0 (0xead5…6f97), ⬇ 0 ⬆ 0    
2021-07-15 21:32:35 💤 Idle (0 peers), best: #0 (0xead5…6f97), finalized #0 (0xead5…6f97), ⬇ 0 ⬆ 0    
2021-07-15 21:32:40 💤 Idle (0 peers), best: #0 (0xead5…6f97), finalized #0 (0xead5…6f97), ⬇ 0 ⬆ 0    
2021-07-15 21:32:45 💤 Idle (0 peers), best: #0 (0xead5…6f97), finalized #0 (0xead5…6f97), ⬇ 0 ⬆ 0  

Mais je ne sais pas trop quoi faire avec ensuite :slight_smile:

1 Like

Woah, merci @elois pour ta réponse !
On devrait éditer le 1er post pour lister les questions/réponses comme ça…

3, 4, 10 coups même ! En tant que dev qui a envie de bien faire, ce n’est pas super motivant d’avoir à bricoler de l’existant pour arriver à ses fins alors que l’on sait que l’on pourrait faire mieux et plus simple en repartant d’une bonne base. Et en plus ça va profiter à toute la communauté, c’est enthousiasment !

Oui, Hasura construit une api graphql sur une ou plusieurs bases de données postgresql mais aussi des bdd sql. Moi je ne vais pas regretter du tout ElasticSearch. C’est un moteur de recherche est je n’ai jamais compris l’intérêt de l’utiliser comme base de données. En termes de perf, Hasura peut tenir un million de connexions websocket. On a de quoi voir venir. J’ai des fonctions postgresql pour faire de la recherche en langage naturel, et de la recherche par géolocalisation. Hasura transforme n’importe quelle vue et fonction postgresql en api graphql… Avec les remote schemas, c’est un outil vraiment génial pour construire une architecture en microservices. Si vous voulez tester en 2 min, il y a https://cloud.hasura.io/ ou sur heroku.

2 Likes