Derzeit ist die Architektur, die ich mir ansehe, dass der Smart Contract (SC) im Ethereum-Netzwerk sitzt, aber es ist ein komplexes und mehrstufiges Vertragssystem. Allein das Navigieren durch die Ebenen der Smart-Contract-Plattform ist sehr mühsam, und ich erwäge, einen node.js-Backend-Dienst zu erstellen, der web3 implementiert, um die mehrstufigen SC-Aufrufe durchzuführen und meine benötigten Daten in einer JSON-RESTful-Antwort zurückzugeben.
Dies sollte die Menge an Verrücktheit reduzieren, die das Frontend (vue.js) bewältigen müsste, um der Benutzeroberfläche die benötigten Daten bereitzustellen.
Die Blockchain hat zwar alle Ereignisse erstellt und ich kann web3 verwenden, um die Benutzeroberfläche auf diese Weise zurückzusuchen und zu füllen, aber dann müsste ich auch durch mehrstufige SCs navigieren, um die Daten zu erhalten, die ich benötige.
Wäre es sinnvoller, eine fette Frontend-Benutzeroberfläche zu haben, die Ereignisanalyse und Plattformnavigation durchführt, oder ein NodeJS-Backend zu haben, das Open Source ist und als Blockchain-Reader fungiert, der das für mich erledigt und dann alles in einem hübschen JSON für die Benutzeroberfläche bereitstellt? ?
Ja, es hat sich herausgestellt, dass dies für viele schreibgeschützte Anfragen, die Sie aus Verträgen machen möchten, äußerst nützlich war. Aufgrund meiner Anwendung hatte ich mehr als eine Schnittstelle, die die Daten für eine Ethereum-Smart-Contract-Plattform mit mehreren Verträgen verbrauchte, so dass es viel einfacher war, die node.js-API zu haben, um darin zu navigieren und meinen Endbenutzern eine leicht verständliche API bereitzustellen. Ich habe die node.js-API als Open Source bereitgestellt, sodass Sie sie unter github.com/matryx/MatryxExplorer ausprobieren können, wenn Sie Ideen benötigen. Ich habe IPFS als Speichermechanismus verwendet –
KitKarson
AquamanSam