От звуковых волн до serverless-функций: Как саунд-дизайнер 7 месяцев создавал веб-приложение с помощью ИИ и без знаний в коде
Привет! Меня зовут Илья Шмяк, и я саунд-дизайнер.
Я работаю с самыми разными клиентами, среди которых:
Разработчики игр, кинорежиссеры и аниматоры, дизайнеры одежды, бренды и агентства.
Моя профессия - это мир синтезаторов, аудиоволн и поиска идеального звука.
Я не понимаю в коде от слова «совсем». Но у меня была цель - создать собственный сайт-библиотеку с моими звуками и музыкой.
В начале года я решил создать полноценный сайт, куда я могу загружать свои звуки и музыку с целью их продажи. И моим единственным программистом должен был стать ChatGPT.
Эта статья — честный дневник этого 7-месячного путешествия, полного наивных ошибок, неожиданных открытий, технических тупиков и, в конечном итоге, ценных уроков и — рабочий сайт!
Глава 1. Локальная разработка: Иллюзия простоты и первые ошибки фронтенда
Мой путь начался с исследования. Я скармливал нейросетям код референс сайты, чтобы понять их устройство, как и на чем они сделаны. Так я узнал о Jekyll — генераторе статических сайтов. ИИ описал его как «быстрый, безопасный и простой». Идеально для новичка!
Поначалу я даже не подозревал о существовании «бэкенда». Я думал, сайт — это просто набор страниц. Я рисовал в блокноте схемы, придумывал структуру, а потом просил ИИ воплотить это в коде. Этот этап был долгой, мучительной, но понятной борьбой с фронтентом:
UI/UX итерации: Я часами двигал кнопки, менял шрифты и переделывал дизайн модальных окон. Часто ИИ понимал мои запросы слишком буквально, генерируя нерабочий или кривой интерфейс.
Месяцы допросов ИИ и слепых экспериментов: Как сделать так, чтобы при нажатии на одну кнопку «Play», другая останавливалась? Как заставить модальное окно корректно появляться и исчезать? Каждый такой вопрос превращался в многодневный квест.
Сложность vs. Реализуемость: Я постоянно отказывался от сложных идей (вроде динамической визуализации волны), потому что ИИ не мог дать простого решения, а потом снова возвращался к ним, пытаясь разбить задачу на микроскопические шаги.
В конце концов, у меня на компьютере был красивый, интерактивный, но абсолютно «мертвый» сайт-витрина. Я был невероятно горд успехом.
Глава 2. Перенос в онлайн: Первый удар о реальность
Я искал бесплатные решения для хостинга, остановился на GitHub, залил файлы и... вот он, мой сайт в интернете! Но тут же возникли вопросы, о которых я раньше не думал:
А как сделать корзину? Как пользователь будет скачивать файлы? А где хранить данные о регистрации пользователей? Как подтвердить регистрацию по email? А как пополнять баланс? Как реализовать и при помощи чего...?
Стало ясно, что просто красивых страничек недостаточно. Нужна была какая-то серверная логика — бэкенд.
Глава 3. Поиски бэкенда и нокаут от законодательства
Мои поиски бэкенда напоминали блуждание в тумане. ChatGPT предлагал десятки вариантов. Я пробовал собрать «монстра» из Auth0 для авторизации и Supabase для базы данных, пытался использовать Node.js на хостинге Beget — всё было слишком сложно и работало на костылях.
В итоге я решил использовать единую экосистему Yandex Cloud, но с Auth0 в качестве сервиса аутентификации. И вот, когда я почти решил все проблемы, я совершил роковую ошибку. Изучая консоль Яндекса, я случайно подключил платную услугу. Утром меня ждал заблокированный аккаунт и долг в 5000 рублей. Техподдержка была непреклонна.
Платить за случайный клик я не собирался. Я закрыл тот аккаунт, зарегистрировал новый и начал переносить весь фронтенд. Бэкенд предстояло делать снова, с полного нуля. И в этот момент я узнал про Федеральный закон № 152-ФЗ. Оказалось, данные нужно хранить в России. Мой Auth0, расположенный за границей, больше не подходил.
Вся моя архитектура снова рассыпалась. Пришлось писать всё самому.
Глава 4. Финальная сборка: Свой бэкенд на Yandex Cloud
Я полностью отказался от сторонних сервисов аутентификации. Теперь вся логика работала на связке Yandex Cloud (база данных, функции, хранилище) и отечественного сервиса Unisender для отправки писем. На этом этапе я столкнулся с последней волной проблем, где мне пришлось стать настоящим отладчиком.
Моей первой настоящей бэкенд-задачей было подключить облачную функцию к Yandex Database Я попросил ИИ написать код, развернул его и тут же получил жесткий отказ: Unauthenticated.
Логи кричали, что у меня нет прав. «Окей, — подумал я, — это, наверное, просто». Я полез в документацию и настройки IAM. Оказалось, что «сервисному аккаунту» — этакой цифровой личности моей функции — нужно было вручную выдать роль ydb.editor. Я нашел нужную галочку, поставил и был уверен, что всё заработает.
Но ничего не заработало. Та же ошибка.
Проблема была не столько в правах, сколько в самом коде, который сгенерировала нейросеть. Она написала его так, будто он запускается с личного компьютера, и пыталась найти секретные ключи. Но в облачной среде всё работает иначе — функция должна была использовать специальный временный токен, который ей предоставляет само Облако. Мне пришлось перелопатить кучу документации и заставить ИИ переписать код с использованием правильного метода аутентификации. Только тогда база данных наконец-то со мной «поздоровалась».
Но как только я решил одну проблему, тут же появилась следующая, еще более загадочная.
Когда я все настроил, сайт просто отказывался общаться с моим сервером. В консоли браузера горела красная ошибка: blocked by CORS policy.
Расследование: ИИ объяснил мне, что это политика безопасности браузера. Она запрещает сайту на одном домене общаться с сервером на другом домене, если сервер явно этого не разрешит.
Решение: Мне пришлось создать отдельную «пустую» облачную функцию cors-handler, которая не делала ничего, кроме как отвечала на запросы браузера специальными заголовками: «Да, я знаю этого парня, ему можно». Это была кропотливая работа по настройке для каждого типа запроса в API-шлюзе.
Отправка простого письма для подтверждения регистрации превратилась в квест. Письма уходили в спам или вообще не доставлялись. Я потратил неделю, копаясь в DNS-записях (MX, DKIM, SPF), чтобы доказать почтовым гигантам, что я не спамер, и заставить сервис рассылок работать корректно.
Глава 5. Архитектура, рожденная в муках: Как это работает сейчас
В итоге у меня получилась полноценная архитектура, полностью построенная на сервисах Yandex Cloud. Звучит страшно, но на деле это просто набор связанных между собой «кубиков».
Фронтенд: Сам сайт лежит в Object Storage в виде статических HTML-файлов. Это делает его загрузку молниеносной.
Доставка контента: Cloud CDN забирает файлы с сайта и раздает их пользователям по всему миру, обеспечивая высокую скорость.
Мозг (Cloud Functions): Вся логика — регистрация, вход, покупка, скачивание — реализована в 10 отдельных Cloud Functions. Это небольшие скрипты, которые запускаются только тогда, когда к ним обращаются.
Память (YDB): Все данные — пользователи, их балансы, купленные звуки, транзакции — хранятся в serverless-базе данных Managed Service for YDB.
API Gateway: Чтобы сайт мог безопасно общаться с функциями, используется API-шлюз. Он принимает запросы от пользователей и направляет их к нужной функции.
Хранилище файлов: Все мои звуковые файлы лежат в отдельном, приватном бакете, доступ к которому можно получить только через специальную функцию.
Безопасность и управление: IAM управляет правами доступа между сервисами, Lockbox хранит секретные ключи, Certificate Manager выдал бесплатный SSL-сертификат, а Cloud DNS управляет моим доменом.
Глава 6. Ошибки, которые я допустил и цена
Оглядываясь назад, я понимаю, что совершил множество ошибок, которые стоили мне времени и нервов.
Слепое доверие ИИ: Я начинал с того, что просто копировал код, не обращаясь к технической поддержке сервисов. Это главная ошибка.
Игнорирование бэкенда и юридических аспектов: Я слишком долго фокусировался на красивой «обертке», не изучив, как работает «начинка» и какие законы ее регулируют.
Недооценка отладки: Я думал, что основное время уходит на написание кода. Оказалось, 90% времени — это поиск причин, почему код не работает.
И, конечно, у всего этого есть цена, вполне реальная. На данном этапе:
Yandex Cloud: ~164 ₽/мес. (за хранение, трафик и выполнение функций) цена будет расти от нагрузки на сайт.
Почта домена (Beget): 600 ₽/мес. (необходима для работы DKIM и отправки писем)
Домен: 3600 ₽/год
Транзакционные письма (Unisender Go): 400 ₽/мес.
Маркетинговые рассылки (Unisender): Пока бесплатно, в будущем — 8064 ₽/год
Итого, ежемесячные расходы на поддержание проекта составляют около 1464 рублей.
Заключение: От кода к сообществу. Что дальше?
Я прошел путь от идеи до реализации, спотыкаясь о множество проблем. Самое главное — я доказал себе, что даже без знаний в коде можно построить сложный цифровой продукт. Платформа готова принимать пользователей, обрабатывать платежи и доставлять качественный звук.
Но я прекрасно понимаю, что самый лучший инструмент бесполезен, если о нем никто не знает. Технический марафон позади, и теперь начинается новый, не менее сложный этап — сделать сайт по-настоящему живым и полезным сервисом для креаторов. Чтобы он из личного проекта превратился в ценный ресурс для разработчиков игр, режиссеров и дизайнеров.
Спасибо, что дочитали эту длинную историю! Буду невероятно благодарен за вашу обратную связь, советы и мнения в комментариях. Возможно, именно вы подскажете, в каком направлении двигаться дальше.
