TL;DR, вот проект: https://invoice.build
ссылки на все остальное, что есть в открытом доступе, указаны в конце этого поста.
Я открываю исходный код, дорожную карту, аналитику, *все.
Для тех из вас, кто чувствует себя комфортно в мире открытого исходного кода, это, вероятно, не кажется чем-то большим, но для меня это так. Я разработчик-самоучка, поэтому у меня затяжной синдром самозванца и неуверенность в себе по поводу кода, который я пишу. Я занимаюсь онлайн-проектами не менее 6 лет, и это никуда не делось.
Я также склонен держать свои проекты в секрете, пока у меня не появится что-то разумно отшлифованное, чтобы поделиться им. Так что выставлять все напоказ — это просто немного страшно… Но что самое худшее, что может случиться?
- Я мог бы быть полностью осмеян за качество кода!
2. Живой проект может быть взломан в результате случайного раскрытия некоторых секретов среды или уязвимости фреймворка/зависимости.
3. Кто-то копирует все приложение и делает его более успешным.
4. Никому нет дела и все это бессмысленно.
Ого, это то, что есть.
Если кто-то копирует полностью, то это, по крайней мере, своего рода проверка идеи, и первые два случая в долгосрочной перспективе приведут к лучшему коду. Так что я думаю, учитывая все обстоятельства, потенциальная выгода от того, что просто больше не будет строиться в частном порядке, стоит рисков.
Я также делаю это в духе ETHOnline, я думаю, что это в основном для проектов и протоколов с открытым исходным кодом, и хотя я изначально не разрабатывал invoice.build как проект с открытым исходным кодом, это не Ethereum. протокол (пока), кто знает, куда он может пойти.
Задний план
Не пытаюсь кричать здесь в свой собственный рог, просто хочу дать некоторый контекст тому, почему я создаю это и почему я делаю это публично.
Изначально я был инженером-механиком в нефтегазовой отрасли, в то же время я создал массу сторонних онлайн-проектов и в итоге получил работу Full-Stack разработчика в Bitbond. Bitbond активно участвует в криптографии, мы в основном работаем с традиционными банками, предоставляющими технологии токенизации. Мы также выпустили первое в истории STO (Security Token Offering) в Германии еще в 2019 году.
В прошлом году я создал еще один побочный проект под названием Remroll, инструмент для обработки бизнес-платежей для токенов Ethereum. На данный момент Remroll обработал токены ERC20 на сумму более 100 000 долларов, в основном в виде бонусных выплат, но использование как бы выдохлось.
Однако процесс сборки Remroll привел меня к идее invoice.build. Пару раз мне нужно было выставить счет криптобизнесу, и в идеале это был бы Dai или какой-либо другой стейблкоин. Все, что мне было нужно, это симпатичная платежная страница, которая позволяла бы клиенту совершить платеж, используя кошелек по своему выбору.
У меня также был друг, который работал в одном из крупных проектов ERC20, появившихся во время бума 2017 года. Он ежемесячно выставлял счета этой компании в эфире (ETH), и этот процесс, как он описал, был мучительным.
Это в основном то, что привело меня к созданию invoice.build. Как правило, это имеет отношение к моей работе и отрасли, а особенно к некоторому опыту, который я получил в сторонних проектах.
И, наконец, идея регулярных бизнес-платежей / выставления счетов в токенах Ethereum мне интересна, поэтому я подумал, что было бы интересно построить
Идея
Краткий обзор того, что такое invoice.build и каким я хотел бы его видеть.
Идея довольно проста, invoice.build — это чисто служебное приложение, которое помогает вам создавать страницы оплаты счетов для токенов на основе Ethereum.
По крайней мере, это то, что есть прямо сейчас.
Я хотел бы предоставить API или, может быть, даже протокол Ethereum, который позволит другим приложениям легко интегрировать аналогичные функции в свои собственные приложения и DApp.
Возможно, однажды он предоставит возможность использовать более интересные платежные протоколы, которые стали возможными благодаря Ethereum, такие как Sablier, чтобы платежи по счетам можно было передавать в потоке с течением времени.
Это то, что мне так нравится в Эфириуме: компонуемость передачи стоимости, так много вариантов, и все открыто.
Почему
Так зачем все это выкладывать на всеобщее обозрение?
- У меня есть привычка создавать сторонние проекты в непреднамеренном скрытом режиме, и как только у меня есть MVP, я публикую его на ProductHunt, Show HN и тому подобное. У меня были небольшие успехи, но в целом это не сработало для меня. Мне нужно попробовать что-то другое, и почему бы не полную противоположность.
- Код очень редко является рвом.
- Я ничего не теряю, открывая все.
- Быть сверхпрозрачным ценно, это укрепляет доверие, а доверие к криптографии на данный момент является серьезной проблемой.
- Это дает мне возможность быть полностью прозрачным для ETHOnline.
Стек
Краткий обзор того, что я создал на данный момент, и инструментов, которые я использую:
- Внешний интерфейс — это приложение Nuxt.js (Vue), которое подключается к MetaMask и WalletConnect для платежей.
- Backend — это чистый Rails API, подключенный к базе данных PostgreSQL. У меня также есть приложение Express.js Node, которое действует как микросервис для API Rails для выполнения некоторых операций с данными Ethereum.
- Размещение/развертывание выполняется на некоторых серверах Dokku, которые я запускаю в DigitalOcean.
- База данных — это управляемая база данных PostgreSQL, предоставляемая DigitalOcean. База данных просто используется для хранения данных о счетах и транзакциях, подробнее об этом в предостережении ниже.
- Для локальной разработки я использую VScode и Docker. Вы также можете раскрутить приложение, если хотите, просто следуйте Readme здесь.
*Предостережение
Данные (база данных) не являются общедоступными. т. е. где хранятся все данные счета-фактуры. Транзакции, сделанные для оплаты счетов, очевидно, общедоступны в блокчейне Ethereum.
Долгосрочная идея состоит в том, чтобы переместить все это в цепочку. В идеале все, включая создание счетов, будет помещено в цепочку, но мне нужно найти лучший способ сделать это. Я писал смарт-контракты раньше, я даже писал комбинацию смарт-контрактов для хранения счетов в сети, но я хочу серьезно подумать об этом, смарт-контракты пугают.
В этом пространстве также есть существующие протоколы, которые я мог бы использовать, наиболее известным из которых является Request.network.
Так что база данных пока скорее временное решение. В будущем весьма вероятно, что invoice.build будет использовать только Ethereum в качестве своей «базы данных».
Я работаю над этим проектом пару месяцев в свободное время, поэтому в нем не хватает многих функций, а код явно не идеален.
Я очень открыт для обратной связи и сотрудничества (если кто-то еще думает, что это хорошая идея). Тем не менее, суть открытого исходного кода в большей степени заключается в проверке идеи о том, что сохранение конфиденциальности кода очень редко является причиной успеха или неудачи проекта, и что общедоступное создание всего ценно, даже если сам проект терпит неудачу.
Пожалуйста, найдите все соответствующие ссылки на общедоступные страницы проектов ниже.
Если вы хотите следить за тем, как я создаю invoice.build, я буду публиковать обновления, когда смогу, в Твиттере.
Ссылки
- 🔮 Приложение: https://invoice.build
- 🏗 Код: https://github.com/Invoice-build
- 🛣 Дорожная карта: https://trello.com/b/RKj2K6Hz
- 📊 Аналитика: https://app.usefathom.com/share/qktowsha/invoice.build
- 👨💻 Обновления: https://twitter.com/garethafuller
Первоначально опубликовано на garethfullers.site 12 октября 2020 г.