Modèles de conception: App vs Dapp

Nous avons entrepris de créer une application simple pour enregistrer un nom sur la blockchain d'Ethereum. Nous pensions que la mise en place de ce site simple serait un jeu d'enfant. On peut apprendre les concepts de base de la blockchain en quelques semaines, la taille de la plupart des applications de blockchain est assez petite pour être exploitable en un week-end, et l'application que nous avions décidé de créer était une application de commerce électronique éprouvée et authentique. nom de domaine et achetez-le. Ça ne peut pas être plus simple que ça. Mais c'est là que l'histoire devient laide. Notre petite application de démonstration Ethereum est tombée 5 fois en 5 semaines. Et nous n'avions aucun trafic - je pense que notre charge de pointe était lorsque mon meilleur ami et son chat ont visité notre site au même moment. Le problème? Il s'avère que notre infrastructure, notre base de données et notre modèle de données clients étaient tout à fait erronés.

Première leçon: Utilisez un fournisseur de services de nœud hébergé au lieu d'héberger vos propres nœuds pour créer des applications en chaîne. Lorsque vous devenez grand, vous pouvez (et devriez) gérer votre propre flotte de nœuds et embaucher quelqu'un à plein temps pour le faire, mais pour commencer, utilisez simplement un point de terminaison api. Beaucoup plus facile. Wow beaucoup.

J'aime gérer les choses localement - ça fait du bien d'être proche de ses propres systèmes et données. Nous courions notre propre noeud. Cela signifiait essentiellement que nous devions dépenser 50 $ de plus par mois sur notre serveur, qui était une énorme mémoire et que nous devions constamment mettre à jour le logiciel de nœud, qui était parfois un peu buggé (et ce n’est pas grave, c’est une technologie de pointe). Mais pour le développement d’une application blockchain - du moins à ses débuts - c’est exagéré. Si vous souhaitez passer votre temps sur votre application, et non sur dev-ops pour votre nœud local, utilisez un service Ethereum-node hébergé et bien géré, qui peut prendre en charge toutes les nuances pour vous.

Deuxième leçon: Débarrassez-vous de votre base de données. Si vous stockez l'état quelque part dans votre application, vous vous trompez probablement. Une application décentralisée devrait vivre sur la blockchain (et IPFS, etc., l'avenir est à venir).

Notre base de données a été mal pensée. Nous avons fini par reproduire l'état de notre côté dans notre propre base de données. Et comme tout le monde peut vous le dire, une fois que vous avez deux instances d’Etat (notre base de données et la blockchain), vous êtes assuré de passer du mauvais temps. Chaque fois que notre nœud tombe en panne ou se déconnecte, nous nous identifions à une foule d'erreurs. Nous avons fait des scripts pour le nettoyer. Et puis manuellement est retourné pour vérifier. Mais à la fin, ils se sont regardés et ont dit: «Que faisons-nous? pourquoi ne pas simplement nous débarrasser de la base de données et utiliser la blockchain pour state et partir de là? pourquoi stockons-nous les données? »Nous avons vidé notre base de données. Et cela ressemblait à une révélation. Pourquoi cela a-t-il pris si longtemps à comprendre? Je ne pense pas que je saurai jamais.

Troisième leçon: S'engager à gérer les données appartenant à l'utilisateur. Les utilisateurs doivent apprendre à stocker et à protéger correctement leurs données - dans le cas qui nous concerne, leurs clés privées Ethereum - et vous devez vous efforcer de rendre cette opération aussi simple que possible pour vos utilisateurs. Mais ça vaut le coup.

Ensuite, nous avons eu ce problème de garde - nous achetions des noms pour le compte d’utilisateurs. L'avenir des applications blockchain réside dans le fait que les utilisateurs possèdent leurs propres données, ce qui leur ouvre de nombreuses possibilités. Dans notre cas, cela signifie que les utilisateurs bénéficient d'un niveau de confidentialité plus élevé, qu'ils ne doivent pas s'inquiéter du défaut de conservation et qu'ils peuvent se déplacer ailleurs lorsqu'ils le souhaitent, car nous ne conservons pas leurs données (contrairement au DNS classique qui peut prendre une semaine). transférer). Les données détenues par les utilisateurs sont attrayantes pour les utilisateurs car ils ne doivent pas compter sur vous. Elles sont également intéressantes pour les entreprises car vous pouvez vous décharger de vos problèmes de garde et vous concentrer sur votre application. Mieux vaut construire pour le futur que le passé.

Nous avons eu du mal à mettre en place l’infrastructure, à abandonner la gestion de notre état localement et à nous engager dans la propriété des données de l’utilisateur. Nous avons commis des erreurs en cours de route, mais avons fini avec une dapp dont nous sommes fiers. Et nous ne stockons aucune donnée utilisateur, ne possédons pas de base de données interne ni de flotte de noeuds auto-hébergés (pour le moment!). La cause fondamentale n’était pas la difficulté de la nouvelle technologie, la taille de la tâche à accomplir ou la nouveauté de la technologie. C'était la "philosophie" du développement d'applications blockchain. Mais pas plus. Nous sommes tous dans la blockchain en tant que source ou état unique, contrôle utilisateur total et données appartenant à l'utilisateur. Nous ne regardons pas en arrière. Nous nous amusons énormément et nous avons hâte de poursuivre notre route vers le fond du terrier de lapin.