Так, гарне зауваження, це звичайний веб-додаток

Мені трохи сумно читати такі коментарі 🙂 Мета статті була показати прості кроки для тих, хто тільки починає знайомство з AI (використала перекладача як приклад). Для тих, хто вже в темі, у мене є інша стаття dou.ua/forums/topic/54530. (хоча впевнена, що і там знайдуться варіанти для хейту :) )
На коментарі в подібному тоні відповідати не бачу сенсу, краще зосередитися на тих, кому це справді допомогло.

Гарне питання! API-ключ не можна зберігати у фронтенді(навіть у .env) Але для того щоб локально зарадити і спробувати різні промпти, то можна.

Дякую ❤️

Дякую за коментар, надіюсь ти дійшов такого висновку після того як запустив проект і попробував як все працює.
Можу порекомендувати почитати попередню статтю про чат бот, або написати кращу статтю ;)

Дякую, рада що сподобалась ❤️

Дякую! Приємно це чути!

Дякую! Дуже класний і змістовний коментар
Абсолютно згодна — поки це експеримент, але вже бачимо потенціал. Думаю, з часом AI навчиться поводитися обережніше з даними і не «фантазувати»

Так, абсолютно, мікрофронт повинен мати можливість працювати самостійно — і це в нас є. А import-map-overrides — це просто зручний спосіб вбудувати локально запущений модуль у shell, щоб перевірити взаємодію з іншими частинами. Це не заміна stand-alone режиму, а доповнення.

Дякую! 😊 У нас основні глюки починались на масштабі: різні фреймворки, React 17/18, shared залежності, які не завжди шарились коректно, і ще hot reload не завжди підхоплював зміни у dev-режимі. Плюс були нюанси з внутрішніми пакетами, типу UI-компонентів — іноді злітала синхронізація або конфліктували стилі. Тобто не те щоб «не працює», а радше нестабільно в edge-кейсах.

Дякую, дуже влучне зауваження 🙌 Я свідомо не ділилась конкретними конфігами — проєкт комерційний, і мені не дуже ок публічно шарити такі речі. Хотілося радше передати загальну картину, як це працює на продакшні, а не робити «копіпаст». Дякую за комент! 🙏

Дякую, що прочитав! Рада, що було цікаво 😊

На жаль, не можу показати — у нас усе досить строго з безпекою. Але можу порадити: спробуй зробити свій маленький pet-проєкт із мікрофронтендами — це реально найкращий спосіб зрозуміти, як все працює. Коли сам проходиш шлях від інтеграції до деплою, багато речей стають очевидними.

Після логіну ми отримуємо доступи користувача, і вже на їх основі вирішується, які мікрофронтенди підключати. Якщо прав немає — модуль взагалі не завантажується. Все працює через dynamic import, тож підтягується тільки те, що потрібно саме цьому юзеру.

Так, можна запускати мікрофронт локально навіть якщо все збирається через shell. Ми використовуємо import-map-overrides — це тулза, яка дозволяє підмінити окремий модуль на локальний. Просто запускаєш свій мікрофронтенд, обираєш його в UI цієї тулзи — і він підставляється на твій локальний. Працюєш із ним як з окремим додатком, все інше лишається як є. Дуже зручно і просто.

О, та я теж так само спочатку казала «вайт», поки друг не підказав, що правильно «віт». Тепер вже звикла, хоч і звучить трохи непривично, зате правильно!

Так і є — чекаємо, поки доросте. У Vite є плагін для Module Federation, але з великими проєктами він поки поводиться нестабільно. Loading....

Та і у нас продукт досить великий, з купою залежностей і складною архітектурою. Ми дивились у бік Vite + MF, але поки що він не тягне такі масштаби — надто багато edge-кейсів. Тому залишились на Webpack, він хоч і повільніший, але стабільно працює в нашому випадку.

Так, Webpack уже втомив :) Але проєкт стартував давно, і тоді це був дефолт. Через module federation міграція не така проста. Vite дуже подобається, ми вже пробуємо його в нових проєктах.

Так, логін/логаут у нас відбуваються в shell-апліку(контейнері) — він зберігає токени, ініціалізує сесію і передає все мікрофронтендам. single-spa дивились, непогано підходить, коли треба міксувати різні фреймворки. Кожен мікрофронтенд можна запускати окремо на своєму девсервері, це зручно. Деплой автоматизований — у кожного мікрофронтенда свій пайплайн.