Имеет ли смысл иметь серверную часть Node.js, обслуживающую json для внешнего интерфейса для dapp?

В настоящее время архитектура, на которую я смотрю, заключается в том, что смарт-контракт (SC) находится в сети ethereum, но это сложная и многоуровневая контрактная система. Просто навигация по уровням платформы смарт-контрактов требует больших усилий, и я рассматриваю возможность создания серверной службы node.js, которая реализует web3 для выполнения многоуровневых вызовов SC и возврата необходимых данных в ответ JSON RESTful.

Это должно было уменьшить количество сумасшествия, с которым должен был справиться интерфейс (vue.js), чтобы обслуживать пользовательский интерфейс необходимыми данными.

Хотя в блокчейне созданы все события, и я могу использовать web3 для поиска и заполнения пользовательского интерфейса таким образом, но тогда мне также нужно будет перемещаться по многоуровневым SC, чтобы получить нужные мне данные.

Было бы более разумно иметь толстый пользовательский интерфейс внешнего интерфейса, который выполняет синтаксический анализ событий и навигацию по платформе, или иметь бэкэнд nodeJS с открытым исходным кодом, действующий как считыватель блокчейна, который обрабатывает это для меня, а затем обслуживает все в красивом JSON для пользовательского интерфейса ?

Привет .. Я тоже в той же лодке. Не могли бы вы объяснить, как вы в итоге решили эту проблему?
@KitKarson Да, в итоге это было чрезвычайно полезно для многих запросов только для чтения, которые вы хотите выполнять из контрактов. Из-за моего приложения у меня было более одного интерфейса, потребляющего данные для платформы смарт-контрактов Эфириума с несколькими контрактами, поэтому наличие API-интерфейса node.js для навигации по нему и предоставления моим конечным пользователям легко усваиваемого API-интерфейса упростило его. Я открыл исходный код API node.js, поэтому вы можете проверить его на github.com/matryx/MatryxExplorer, если вам нужны идеи. Я использовал IPFS в качестве механизма хранения

Ответы (1)

Да, оказалось, что это было чрезвычайно полезно для многих запросов только для чтения, которые вы хотите выполнять из контрактов. Из-за моего приложения у меня было более одного интерфейса, потребляющего данные для платформы смарт-контрактов Эфириума с несколькими контрактами, поэтому наличие API-интерфейса node.js для навигации по нему и предоставления моим конечным пользователям легко усваиваемого API-интерфейса упростило его. Я открыл исходный код API node.js, поэтому вы можете проверить его на github.com/matryx/MatryxExplorer, если вам нужны идеи. Я использовал IPFS в качестве механизма хранения —