Какво е full-stack приложение? Обяснение с прости думи

Full-stack приложението е приложение, което включва всички слоеве, нужни за работа: фронтенда, който хората виждат и натискат, бекенда, който работи на сървър и прилага правилата, и базата данни, която помни всичко. Списък със задачи, който запазва задачите ви, позволява да влизате от всяко устройство и не показва вашия списък на никой друг — това е full-stack. Една страница, която показва само работното време на магазин, не е.

„Stack“ означава слоевете технологии, наредени един върху друг. „Full“ означава, че всички са налице.

Защо е важно, когато строите с AI

Когато описвате приложение на AI платформа, думите, които използвате, определят кои слоеве ще бъдат създадени. „Направи страница, която показва менюто ни“ води до фронтенд. „Позволи на клиентите да поръчват от менюто и кухнята да вижда новите поръчки“ изисква и трите слоя, защото поръчките трябва да се запазят, да се споделят между два вида потребители и да останат поверителни.

Познаването на разликата ви помага по три начина:

• Искате точното нещо. Ако искате данните да се запазват, кажете го. Платформа, която създава само фронтенда, ще изглежда завършена, но ще забрави всичко при презареждане.
• Разпознавате фалшивата завършеност. Демо с примерни данни може да изглежда точно като работещо приложение. Познаването на слоевете ви позволява да проверите дали данните наистина отиват някъде.
• Разбирате текущите разходи. Само фронтендът може да се поднася като статични файлове. Бекендът и базата данни са програми, които работят на сървъри, и там се крие по-голямата част от разходите за хостинг.

Ежедневна аналогия: ресторант

Представете си ресторант.

• Залата е фронтендът. Менюто, масите и бележника на сервитьора. Това е, което гостите виждат, и трябва да е приятно и лесно за ползване.
• Кухнята е бекендът. Гостите не влизат там. Кухнята приема поръчките, проверява дали ястието е налично, готви го и отказва странни искания. Правилата живеят там.
• Складът и поръчковата книга са базата данни. Те пазят какво има и какво е поръчано, така че нищо да не се забрави при смяна на смените.

Ресторант само със зала може да ви покаже хубаво меню, но няма да ви нахрани. Това е фронтенд приложение, което се прави на full-stack.

Трите слоя по-подробно

Слоевете комуникират в определен ред. Фронтендът иска нещо от бекенда през API — определен набор от заявки, които бекендът приема. Бекендът проверява заявката, чете или записва в базата данни и връща отговор. Фронтендът никога не говори директно с базата данни.

Този ред е най-важната идея за сигурност в целия стек. Всичко във фронтенда може да бъде прочетено и променено от посетителя, защото работи на неговото устройство. Затова правилата — „само собственикът може да вижда тази фактура“, „купонът може да се използва веднъж“ — трябва да се налагат в бекенда. За повече за разделението вижте фронтенд срещу бекенд.

Практически пример: приложение за записване на йога часове

Да кажем, че водите йога студио и искате хората да записват часове онлайн.

Какво прави посетителят: отваря сайта, вижда програмата за седмицата, натиска един час, влиза в акаунта си и записва място.

Какво се случва отдолу:

1. Фронтендът показва програмата. За да я попълни, пита бекенда: „Кои часове има тази седмица и колко места са останали?“
2. Бекендът пита базата данни за часовете и преброява записванията за всеки, после отговаря.
3. Посетителят натиска Запиши. Фронтендът изпраща „запиши час 42 за този влязъл човек“.
4. Бекендът проверява: наистина ли този човек е влязъл? Пълен ли е часът? Вече записан ли е? Само ако всичко е наред, записва нов ред за записването в базата данни.
5. Бекендът отговаря „записан“, а фронтендът показва потвърждение.
6. По-късно собственичката влиза и вижда списъка с часове. Бекендът проверява дали е администратор, преди да покаже имената на всички.

Сега си представете, че е изградено само като фронтенд. Програмата може да се вижда, а бутонът „Запиши“ да показва хубава отметка, но записването ще изчезне при презареждане, броят на свободните места ще е грешен за всички останали, а собственичката никога няма да го види. Стъпка 4 — проверките — ще липсва напълно. Ето практическата разлика.

Ключови термини

• Фронтенд (client side): частта, която работи в браузъра.
• Бекенд (server side): частта, която работи на сървър. Нарича се още API сървър.
• База данни: мястото, където данните се пазят по организиран начин. Вижте какво е база данни.
• API: списъкът с заявки, които бекендът приема от фронтенда или от други програми.
• Удостоверяване (authentication): проверка кой е някой (вход). Упълномощаване (authorisation): проверка какво може да прави.
• Внедряване (deployment): пускане на всички слоеве на сървъри, за да ги използва публиката.
• Монолит срещу услуги: една програма, която прави всичко, срещу няколко по-малки (например сайт и отделен API). И двете са full-stack.

Чести заблуди и грешки

• „Изглежда готово, значи е готово.“ Примерните данни и бутон, който изглежда работещ, не са същото като запазени данни. Презаредете страницата, отворете я в приватен прозорец и проверете дали данните са там.
• Слагане на правилата във фронтенда. Скриването на бутон не е сигурност. Ако бекендът не проверява, всеки, който знае заявката, може да я изпрати.
• Слагане на секретни ключове във фронтенда. Ключ на платежен или AI доставчик в браузърния код се чете от всеки посетител. Ключовете принадлежат на бекенда, в променливи на средата — вижте променливите на средата и тайните.
• Мисълта, че full-stack значи сложно. Малко full-stack приложение може да е няколко екрана, няколко бекенд маршрута и три таблици в базата данни. Това е описание на слоевете, а не на размера.
• Мисълта, че сами трябва да избирате всяка технология. За първа версия върши работа всеки разумен и широко използван стек. По-важно е ясното описание на данните и правилата.

Какво да поискате от AI платформата

Описвайте приложението през трите слоя, дори да не ги назовавате:

• Данните: „Запази часовете (име, час, капацитет) и записванията (час, човек, време на записване) в база данни.“
• Правилата: „Не може да се запише час над капацитета. Човек може да запише даден час само веднъж. Само администраторите виждат кой е записан.“
• Екраните: „Седмична програма, потвърждение за записване, административна страница със записванията по час.“
• Проверките: „Прилагай тези правила на сървъра, не само в страницата. Пази API ключовете на сървъра.“

После тествайте като скептик: презаредете, влезте с двама различни потребители, опитайте да видите данни, които не би трябвало да виждате. Ръководството за създаване на приложение с AI описва целия цикъл от край до край.

Full-stack приложения в Mythex

Mythex създава full-stack уеб приложения от описание в чат. По подразбиране новото приложение получава React и TypeScript фронтенд; когато приложението трябва да пази данни, Mythex добавя към проекта собствена Postgres база данни, а при нужда можете да поискате отделен API сървър (например на Python, Node, C# или Java) до сайта. Всичко работи заедно в жив преглед и се публикува на публичен адрес. Страницата в документацията за приложения с няколко услуги показва как сайт и API се преглеждат и публикуват заедно, а страницата конструктор на full-stack приложения предлага отправни точки.

Въпроси