Упомяните термин “web3” группе разработчиков, и вы неизбежно увидите, как горстка из них рефлекторно съежится. Некоторые до сих пор настойчиво спорят, что это в основном необоснованный хайп - способ для программистов тратить свое время на создание прославленных схем Понци с некачественным UX.

Что они упускают, так это то, что новые децентрализованные протоколы на самом деле стали катализатором для разработчиков, чтобы переосмыслить годы предположений о том, как сеть должна работать. Одно из них - это IPFS, которая, несмотря на то, что ей 7 лет, все еще думаю, что она упущенная из виду технология, заслуживающая большего внимания.

После использования IPFS для хранения изображений в моих новых проектах я больше никогда не хочу возвращаться к старому. Вот почему.

Давайте представим, что вы создаете простое веб-приложение, где пользователи могут создавать свои профили и загружать изображение профиля. Мы начнем с создания довольно наивного минимально-жизнеспособного продукта и посмотрим, что произойдет, как возникнет сложность.

Первая вещь, которая нам нужна, это место для хранения статических файлов, которые загружают пользователи. Легко - мы можем использовать дешевый и надежный сервис хранения данных, такой как AWS S3. Мы создаем нашу корзину, меняем некоторые разрешения и пишем логику загрузки, например:

import { PutObjectCommand } from "@aws-sdk/client-s3"

const uploadParams = {
  Bucket: "mybucket",
  Key: `avatars/${userId}.jpg`,
  Body: fileStream,
}

await s3Client.send(new PutObjectCommand(uploadParams))

Когда Пользователь 1 загружает изображение профиля, оно теперь будет храниться в https://mybucket.s3.amazonaws.com/avatars/1.jpg

Мы, конечно, также захотим хранить ссылку на этот файл в нашей таблице базы данных users:

ID    username     profile_picture_s3_url
1     tristan      avatars/1.jpg

Кажется достаточно хорошо. Теперь, мы можем развернуть наш сайт и начать набирать обороты!

Некоторое время спустя, пользователь требует новую функцию: он также хочет загружать обложки фотографий! Без проблем. Мы можем просто создать новый каталог covers в нашей корзине S3 и загрузить туда файлы! Пользователь 1 будет хранить аватар в /avatars/1.jpgи обложку фотографии в /covers/1.jpg. Все хорошо.

Через некоторое время, пара опытных пользователей приложения начинают требовать учетные записи организаций. Они так довольны вашей удивительной услугой, что хотят пригласить в нее своих коллег. О, и у организаций, конечно же, также должны быть изображения профиля и обложки фотографий.

Хм, теперь вы начинаете чуть-чуть сомневаться в своей структуре каталогов в S3. Организации отличаются от пользователей, поэтому мы не можем хранить аватар Организации 1 как /avatars/1.jpg, иначе он будет конфликтовать с аватаром Пользователя 1.

Должны ли мы создавать новые каталоги org-avatarsи org-covers?

Или, может быть, было бы разумнее иметь usersи orgsв качестве каталогов верхнего уровня? Таким образом, мы могли бы хранить все, связанные с Пользователем 1, в одном каталоге, например: /users/1/avatar.jpg+ /users/1/cover.jpg. Это кажется элегантнее.

На самом деле, что, если мы просто полностью отбросим структуру каталогов и добавим один каталог /images со случайно сгенерированными именами файлов?

Эх, решения, решения… ну, уже слишком поздно. Для их миграции потребуется не только переместить все файлы в S3, но также обновить все ссылки на пути в нашей базе данных. Звучит так, будто наши будущие разработчики по найму позаботиться об этом. 👍

Пару недель спустя, ваше приложение пострадало от ужасного сбоя AWS (на самом деле это случается время от времени, так что это не такой уж нереалистичный сценарий). Все картинки на вашем сайте выглядят так, и ваши пользователи недовольны:

Черт возьми! Вероятно, у нас должна быть служба резервного копирования для обслуживания наших изображений, если AWS выйдет из строя. Может быть, Google Cloud или Microsoft Azure? Ноооо… тогда мы должны бы скопировать все наши папки из S3 в этот альтернативный сервис, загрузить все будущие загрузки в эти два сервиса и убедиться что, мы поддерживаем такую же файловую структуру в двух местах по мере ее развития. Звучит как много работы. Давайте оставим это для будущих разработчиков по найму. 👍

При использовании традиционного поставщика хранилища появляется тонны подобных мелких неприятностей, но в конечном счете все сводится к той же проблеме: файлы, которые вы загружаете, идентифицируются по их URL-пути, а не по их содержимому.

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

С IPFS файлы больше не представлены их URL-адресом - они расположены через хэш (также известный как CID ).

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

Лучшая вещь это, то что с этим действительно легко начать. При чтении статей об IPFS у вас может сложиться впечатление, что вам нужно запустить собственную ноду, перемещаться по различным инструментам CLI или присоединиться к сети Filecoin. В реальности, существует тонны сервисов с API, которые так же просты в использовании, как и AWS SDK! Например, вот как вы можете загружать и закреплять файлы с помощью Pinata:

const pinata = pinataSDK(PINATA_API_KEY, PINATA_SECRET_API_KEY)

const { ipfsHash } = await pinata.pinFileToIPFS(fileStream)

Теперь я могу хранить возвращенный CID вместо пути S3 в своей базе данных:

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

Как пример, вот мой файл на IPFS-шлюзе Cloudflare: https://cloudflare-ipfs.com/ipfs/QmVeg59S5tUgQEPHDaWFVsAXx4VW1ctAWNkXK6Mt5bCQV6

Есть растущая экосистема сервисов, которые будут хранить и хэшировать файлы для вас, включая Pinata, Filebase и Web3Storage. Вы даже могли бы решить идти по полной децентрализации и попросить Filecoin или Arweave закрепить ваши файлы (просто сперва убедитесь, что вы понимаете основные экономические стимулы, основанные на токенах).

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

Нашли услугу закрепления дешевле, чем у вашего текущего поставщика услуг хранения? Нет проблем - просто дайте CID вашему новому провайдеру, позвольте ему закрепить ваши файлы и перестаньте платить старому.

Встревожены, что ваш провайдер может пострадать из-за сбоя сервера? Просто реплицируйте свой контент на другую IPFS ноду в другом месте.

Беспокоитесь о скорости загрузки для ваших пользователей в Гонконге? Попросите провайдера закрепить ваши файлы и обслуживать их, используя другой шлюз в зависимости от IP-адреса пользователя.

Если вы веб-разработчик и еще не пробовали IPFS, попробуйте!

На Layer3, мы храним все наши загруженные файлы с помощью IPFS. Если вам понравился этот пост и вам понравилась идея создания новых типов приложений, которые используют преимущества децентрализованной сети, вам следует присоединиться к нашей команде!

Упомяните термин “web3” группе разработчиков, и вы неизбежно увидите, как горстка из них рефлекторно съежится. Некоторые до сих пор настойчиво спорят, что это в основном необоснованный хайп - способ для программистов тратить свое время на создание прославленных схем Понци с некачественным UX.

Что они упускают, так это то, что новые децентрализованные протоколы на самом деле стали катализатором для разработчиков, чтобы переосмыслить годы предположений о том, как сеть должна работать. Одно из них - это IPFS, которая, несмотря на то, что ей 7 лет, все еще думаю, что она упущенная из виду технология, заслуживающая большего внимания.

После использования IPFS для хранения изображений в моих новых проектах я больше никогда не хочу возвращаться к старому. Вот почему.

Давайте представим, что вы создаете простое веб-приложение, где пользователи могут создавать свои профили и загружать изображение профиля. Мы начнем с создания довольно наивного минимально-жизнеспособного продукта и посмотрим, что произойдет, как возникнет сложность.

Первая вещь, которая нам нужна, это место для хранения статических файлов, которые загружают пользователи. Легко - мы можем использовать дешевый и надежный сервис хранения данных, такой как AWS S3. Мы создаем нашу корзину, меняем некоторые разрешения и пишем логику загрузки, например:

import { PutObjectCommand } from "@aws-sdk/client-s3"

const uploadParams = {
  Bucket: "mybucket",
  Key: `avatars/${userId}.jpg`,
  Body: fileStream,
}

await s3Client.send(new PutObjectCommand(uploadParams))

Когда Пользователь 1 загружает изображение профиля, оно теперь будет храниться в https://mybucket.s3.amazonaws.com/avatars/1.jpg

Мы, конечно, также захотим хранить ссылку на этот файл в нашей таблице базы данных users:

ID    username     profile_picture_s3_url
1     tristan      avatars/1.jpg

Кажется достаточно хорошо. Теперь, мы можем развернуть наш сайт и начать набирать обороты!

Некоторое время спустя, пользователь требует новую функцию: он также хочет загружать обложки фотографий! Без проблем. Мы можем просто создать новый каталог covers в нашей корзине S3 и загрузить туда файлы! Пользователь 1 будет хранить аватар в /avatars/1.jpgи обложку фотографии в /covers/1.jpg. Все хорошо.

Через некоторое время, пара опытных пользователей приложения начинают требовать учетные записи организаций. Они так довольны вашей удивительной услугой, что хотят пригласить в нее своих коллег. О, и у организаций, конечно же, также должны быть изображения профиля и обложки фотографий.

Хм, теперь вы начинаете чуть-чуть сомневаться в своей структуре каталогов в S3. Организации отличаются от пользователей, поэтому мы не можем хранить аватар Организации 1 как /avatars/1.jpg, иначе он будет конфликтовать с аватаром Пользователя 1.

Должны ли мы создавать новые каталоги org-avatarsи org-covers?

Или, может быть, было бы разумнее иметь usersи orgsв качестве каталогов верхнего уровня? Таким образом, мы могли бы хранить все, связанные с Пользователем 1, в одном каталоге, например: /users/1/avatar.jpg+ /users/1/cover.jpg. Это кажется элегантнее.

На самом деле, что, если мы просто полностью отбросим структуру каталогов и добавим один каталог /images со случайно сгенерированными именами файлов?

Эх, решения, решения… ну, уже слишком поздно. Для их миграции потребуется не только переместить все файлы в S3, но также обновить все ссылки на пути в нашей базе данных. Звучит так, будто наши будущие разработчики по найму позаботиться об этом. 👍

Пару недель спустя, ваше приложение пострадало от ужасного сбоя AWS (на самом деле это случается время от времени, так что это не такой уж нереалистичный сценарий). Все картинки на вашем сайте выглядят так, и ваши пользователи недовольны:

Черт возьми! Вероятно, у нас должна быть служба резервного копирования для обслуживания наших изображений, если AWS выйдет из строя. Может быть, Google Cloud или Microsoft Azure? Ноооо… тогда мы должны бы скопировать все наши папки из S3 в этот альтернативный сервис, загрузить все будущие загрузки в эти два сервиса и убедиться что, мы поддерживаем такую же файловую структуру в двух местах по мере ее развития. Звучит как много работы. Давайте оставим это для будущих разработчиков по найму. 👍

При использовании традиционного поставщика хранилища появляется тонны подобных мелких неприятностей, но в конечном счете все сводится к той же проблеме: файлы, которые вы загружаете, идентифицируются по их URL-пути, а не по их содержимому.

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

С IPFS файлы больше не представлены их URL-адресом - они расположены через хэш (также известный как CID ).

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

Лучшая вещь это, то что с этим действительно легко начать. При чтении статей об IPFS у вас может сложиться впечатление, что вам нужно запустить собственную ноду, перемещаться по различным инструментам CLI или присоединиться к сети Filecoin. В реальности, существует тонны сервисов с API, которые так же просты в использовании, как и AWS SDK! Например, вот как вы можете загружать и закреплять файлы с помощью Pinata:

const pinata = pinataSDK(PINATA_API_KEY, PINATA_SECRET_API_KEY)

const { ipfsHash } = await pinata.pinFileToIPFS(fileStream)

Теперь я могу хранить возвращенный CID вместо пути S3 в своей базе данных:

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

Как пример, вот мой файл на IPFS-шлюзе Cloudflare: https://cloudflare-ipfs.com/ipfs/QmVeg59S5tUgQEPHDaWFVsAXx4VW1ctAWNkXK6Mt5bCQV6

Есть растущая экосистема сервисов, которые будут хранить и хэшировать файлы для вас, включая Pinata, Filebase и Web3Storage. Вы даже могли бы решить идти по полной децентрализации и попросить Filecoin или Arweave закрепить ваши файлы (просто сперва убедитесь, что вы понимаете основные экономические стимулы, основанные на токенах).

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

Нашли услугу закрепления дешевле, чем у вашего текущего поставщика услуг хранения? Нет проблем - просто дайте CID вашему новому провайдеру, позвольте ему закрепить ваши файлы и перестаньте платить старому.

Встревожены, что ваш провайдер может пострадать из-за сбоя сервера? Просто реплицируйте свой контент на другую IPFS ноду в другом месте.

Беспокоитесь о скорости загрузки для ваших пользователей в Гонконге? Попросите провайдера закрепить ваши файлы и обслуживать их, используя другой шлюз в зависимости от IP-адреса пользователя.

Если вы веб-разработчик и еще не пробовали IPFS, попробуйте!

На Layer3, мы храним все наши загруженные файлы с помощью IPFS. Если вам понравился этот пост и вам понравилась идея создания новых типов приложений, которые используют преимущества децентрализованной сети, вам следует присоединиться к нашей команде!