Web2 против Web3: что меняется для фронтендера
Сравниваем привычную клиент-серверную архитектуру с архитектурой dApp, чтобы понять, что переносится один-в-один, а что меняется кардинально.
Web2 — привычный интернет с серверами, которыми владеют компании. Web3 — слой приложений поверх блокчейна, где состояние и логика децентрализованы.
Чтобы быстро освоиться, полезно наложить новую модель на старую. Большинство ваших фронтенд-навыков переносятся без изменений: компоненты, состояние, роутинг, формы, стили. Меняется только слой данных.
Таблица соответствий Web2 и Web3
| Web2 | Web3 / dApp |
| REST/GraphQL API | Вызовы функций смарт-контракта через JSON-RPC |
| База данных (Postgres) | Состояние контракта в блокчейне |
| Логин по паролю + сессия | Подключение кошелька + подпись сообщения |
| Бэкенд-логика (контроллеры) | Код контракта на Solidity |
| Запрос почти бесплатен и мгновенен | Запись стоит газ и занимает секунды |
| Сервер можно изменить в любой момент | Контракт после деплоя обычно неизменен |
Идентичность вместо логина
В Web2 «кто ты» определяет сервер: ты вводишь email и пароль, сервер выдаёт сессию. В Web3 личность — это адрес кошелька (например, 0x71C7...976F). Пользователь не регистрируется на вашем сайте: он подключает кошелёк, и вы сразу знаете его адрес. Никакой базы пользователей, никаких паролей. Это и плюс (мгновенный «вход»), и минус (нет привычного восстановления доступа — потерял ключ, потерял аккаунт).
Где остаётся бэкенд
Чистый dApp без сервера возможен, но на практике бэкенд часто всё же есть — для задач, которые блокчейн делает плохо: индексация и поиск истории (см. урок про The Graph), кэш, нотификации, хранение больших файлов, аналитика. Важно понимать границу: деньги и право собственности — в контракте; удобство и скорость — во вспомогательных сервисах. Если бэкенд упадёт, ценности пользователя в контракте не пострадают.
Как работает под капотом
Когда фронт «читает данные пользователя», он на самом деле спрашивает у ноды текущее значение переменной контракта для конкретного адреса. Никакого JOIN и SQL — только чтение слотов хранилища контракта по детерминированным правилам EVM. Поэтому сложные выборки («покажи топ-10 за неделю») напрямую с ноды почти невозможны — отсюда и нужда в индексаторах.
Частые ошибки
- Пытаться сделать в контракте «как в базе». Контракт — дорогое и медленное хранилище; держите в нём только то, что обязано быть on-chain.
- Считать адрес кошелька секретом. Адрес публичен (как номер счёта); секретен только приватный ключ.
- Завязывать критичную ценность на свой сервер. Тогда теряется главное преимущество — независимость от вас как посредника.
Итоги
- Фронтенд-навыки переносятся; меняется только слой данных — API заменяется вызовами контракта.
- Личность пользователя — адрес кошелька, а не логин/пароль.
- Бэкенд в Web3 опционален и решает задачи скорости/индексации, но не хранит ценность.