Що насправді всередині застосунку на ШІ: екскурсія для нерозробників
Якщо ви випустили щось за допомогою конструктора застосунків на ШІ й хочете зрозуміти, на що дивитеся, ось дружня екскурсія по частинах — без жаргону.
Ви ввели опис, натиснули «вперед», і за двадцять хвилин у вас був робочий застосунок. Чудово. Але тепер ви клікнули «переглянути файли» й витріщаєтеся на дерево папок, що виглядає так, ніби написане іншою мовою. Що таке package.json? Чому в node_modules сорок речей? Що означає «схема» і чому вона у вас є?
Цей допис — екскурсія з гідом. Не туторіал — екскурсія. Прочитавши його, ви не знатимете, як написати жоден із цих файлів самі, але наступного разу, коли щось виглядатиме дивно, ви знатимете, на який кут застосунку вказати.
Я використовуватиму три наскрізні приклади, щоб абстрактні частини мали до чого прикріпитися:
- Майя, маркетинг-лідерка, що зібрала реферальну таблицю лідерів для своєї команди.
- Джордан, учитель йоги, що зібрав сайт для запису на заняття.
- Сем, що тримає пекарню й зібрав сторінку «передзамов завтрашні круасани».
Усі троє використали конструктор застосунків на ШІ. Усі три застосунки виглядають для клієнта цілком по-різному. Під капотом вони влаштовані напрочуд схоже.
Фронтенд: те, що насправді бачить ваш клієнт
Фронтенд — це все, що завантажується в чийомусь браузері. Кнопки, макети, шрифти, анімації, те, як форма очищається після надсилання. Якщо ви це бачите, це фронтенд.
Для Майї фронтенд — це таблиця лідерів із рангом, ім’ям і кількістю рефералів. Для Джордана це календар занять із кнопкою «забронювати». Для Сема це список випічки з маленькими кнопками плюс-і-мінус біля кожної.
Усередині проєкту фронтенд зазвичай живе в папці з назвою на кшталт app/, pages/ чи src/. Ви побачите файли, що закінчуються на .tsx чи .jsx. Кожен — це приблизно «один екран» чи «один шматок екрана». Рядок таблиці лідерів — один файл. Хедер — інший файл. Сторінка, що все це поєднує, — третій.
Коли ви просите конструктор на ШІ «зробити кнопки округлішими» чи «перемістити таблицю лідерів праворуч», змінюється саме ця частина.
Бекенд: частина, що думає
Бекенд — це частина, якої ніхто не бачить, але від якої всі залежать. Це код, що працює деінде — на сервері, а не в браузері клієнта, — коли має статися щось, чого не варто довіряти браузеру клієнта самому.
Чому браузер не може робити все? Бо браузер — це машина клієнта, і їй не можна довіряти. Якби таблиця лідерів Майї оновлювала кількість рефералів суто в браузері, будь-хто міг би клікнути правою кнопкою й додати собі 9000 рефералів. Тож бекенд — це місце, де живуть правила: «ця людина може робити це, але не те», «справді збережи це в базу даних», «надішли цей лист».
Бекенд зазвичай живе в папці з назвою api/, server/ чи app/api/. Файли там зазвичай короткі. Кожен обробляє конкретний запит: «створити бронювання», «перелічити сьогоднішні круасани», «додати реферал».
Коли щось працює у вашому застосунку, але результат не тримається — ви клікаєте надіслати, бачите підтвердження, але завтра дані зникли — баг майже завжди в бекенді.
База даних: пам’ять вашого застосунку
Уявіть пам’ять вашого застосунку як ряд картотечних шаф. У кожної шафи спереду етикетка. На одній написано «користувачі». На іншій — «бронювання». На ще одній — «замовлення_круасанів». Усередині кожної шафи кожна шухляда — це один рядок. Кожна шухляда має той самий набір комірок: ім’я, e-mail, created_at, статус.
Ця структура — «які шафи існують, які комірки має кожен рядок» — називається схемою. Це найважливіший файл у проєкті, навіть якщо він також, мабуть, найнудніший на вигляд. Знайдіть файл із назвою schema.ts, schema.prisma чи щось усередині папки з назвою db/ чи migrations/. Відкрийте його. Ви побачите список, що віддзеркалює те, що ваш застосунок насправді пам’ятає про світ.
Схема Джордана має таблицю classes, таблицю bookings і таблицю users. Сема — products, orders та order_items. Майї — members і referrals. Форма схеми — це форма продукту, ось чому змінювати її потім важче, ніж змінювати, як виглядають кнопки.
Корисний трюк: якщо ви можете описати, що ваш застосунок пам’ятає, простими словами, ви зазвичай можете описати схему. «Я пам’ятаю ім’я та e-mail кожного клієнта. Для кожного клієнта я пам’ятаю замовлення, які він зробив. Для кожного замовлення я пам’ятаю, яку випічку й скільки кожної». Це речення — майже слово в слово схема.
Авторизація: вишибала на дверях
«Auth» — це два слова, зліплені докупи: автентифікація (хто ви?) і авторизація (що вам дозволено робити?). Обидва зазвичай обробляються невеликим набором файлів у папці з назвою auth/ чи сервісом, чию назву ви, можливо, упізнаєте: Clerk, Auth0, Supabase Auth, NextAuth.
Ці два запитання різні. Автентифікація відповідає: «це справді Майя?» — зазвичай паролем, входом через Google чи магічним посиланням, надісланим їй поштою. Авторизація відповідає: «чи дозволено Майї видаляти чужі реферали?» — і чесна відповідь для більшості застосунків на ШІ в перший тиждень — «ми забули перевірити».
Це частина, що найчастіше тихо зламана. Екран входу працює, тож воно відчувається безпечним. Але бекенд не завжди перевіряє, що увійшла людина — це та сама людина, чиї дані вона намагається прочитати. Якщо у вашому застосунку є будь-яке поняття «мої дані проти ваших даних», запитайте конструктор на ШІ явно: «Переконайся, що користувачі можуть бачити й редагувати лише власні дані.» Ви здивуєтеся, як часто це одне речення виявляє відсутню перевірку.
Інтеграції: речі, які ви не будували, але все одно використовуєте
Ось де більшість нерозробників недооцінює те, що насправді відбувається. Те, що надсилає лист Сема «ваші круасани готові», — це не код, а акаунт у SendGrid чи Resend. Те, що обробляє платіж Джордана за заняття, — це не код, а Stripe. Те, що зберігає фото на таблиці лідерів Майї, — це не код, а сервіс зберігання на кшталт S3 чи Cloudinary.
Кожна інтеграція з’являється у двох місцях. Є невеликий шматок коду в бекенді, що каже «гей, Stripe, спиши цю картку». І є ключ — довгий секретний рядок — збережений десь у безпеці (зазвичай файл .env, який ніхто ніколи не має комітити), що доводить Stripe, що запит надійшов від пекарні Сема, а не від незнайомця.
Якщо ви колись запитаєте, чому ваш застосунок раптом перестав надсилати листи чи приймати платежі, причина майже завжди одна з: спливлий ключ, досягнутий ліміт використання чи зміна в політиках інтеграції. Код не зламався. Зламалося рукостискання.
Деплой: як воно потрапляє в інтернет
Остання частина — це частина, що перетворює папку на вашому диску на річ, яку ваш клієнт може відвідати за URL. Це зазвичай означає три маленькі речі, що працюють разом:
- Хост: сервіс на кшталт Vercel, Netlify, Fly чи Render, що запускає ваш бекенд і віддає ваш фронтенд.
- Домен: ім’я на кшталт
mayas-leaderboard.com, що вказує на ваш хост. - Збірка: рецепт, що бере ваші заплутані вихідні файли й перетворює їх на стрункішу, швидшу версію, що насправді працює.
Коли щось працює локально, але ламається в продакшені, проблема зазвичай тут. Ключ, заданий на вашому ноутбуці, але не на хості. Бібліотека, встановлена в розробці, але не в продакшені. База даних, що існує у вашому браузері, але не на живому сайті.
П’ятихвилинна звичка, що окуповується
Вам не треба читати кожен файл у вашому проєкті. Вам не треба знати, що роблять більшість із них. Але вам варто раз на тиждень робити п’ятихвилинний прохід, де ви відкриваєте кожну з папок вище й питаєте конструктор на ШІ, простими словами, що змінилося.
Майя робить це щоп’ятниці пообіді. Вона набирає: «Що змінилося в схемі цього тижня й чому?» І: «Чи є в цьому застосунку нові інтеграції, яких я не просила?» Відповіді майже завжди заспокійливі. У ті кілька разів, коли ні, вона ловить проблеми, поки вони ще маленькі.
У цьому весь сенс розуміння частин. Не в тому, щоб стати розробником. Просто в тому, щоб уміти ставити кращі запитання.
Куди йти далі
Якщо ця екскурсія допомогла, два продовження варті вашого часу. Баг «виглядає нормально» охоплює, що робити, коли одна з цих частин тихо зламана, а готовий до демо проти готового до продакшену охоплює, як зрозуміти, що ваш застосунок перейшов від першого етапу до другого. Та сама мапа, різні способи її використання.