Што е full-stack апликација? Објаснето едноставно

Full-stack апликација е апликација што ги вклучува сите слоеви што ѝ требаат за да работи: фронтендот што луѓето го гледаат и го допираат, бекендот што работи на сервер и ги применува правилата, и базата на податоци што сè памети. Листа за работи што ги зачувува вашите задачи, ви дозволува да се најавите од кој било уред и никому не ја покажува вашата листа е full-stack. Една страница што само ги прикажува вашите работни часови не е.

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

Зошто е важно кога градите со вештачка интелигенција

Кога ја опишувате апликацијата на AI градител, зборовите што ги користите определуваат кои слоеви ќе ги изгради. „Направи страница што го прикажува нашето мени“ создава фронтенд. „Дозволи им на клиентите да нарачаат од нашето мени и нека кујната ги гледа новите нарачки“ бара сите три слоја, бидејќи нарачките мора да се зачувуваат, да се споделуваат меѓу два вида корисници и да остануваат приватни.

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

• Барате вистинската работа. Ако сакате податоците да се зачуваат, кажете го тоа. Градител што прави само фронтенд ќе изгледа завршено, но ќе заборави сè при освежување.
• Ја препознавате лажната комплетност. Демо со примерни податоци може да изгледа исто како работечка апликација. Познавањето на слоевите ви овозможува да проверите дали податоците навистина некаде одат.
• Ги разбирате тековните трошоци. Самиот фронтенд може да се послужи како статички датотеки. Бекендот и базата се програми што работат на сервери, и тука доаѓа најголемиот дел од трошокот за хостинг.

Секојдневна аналогија: ресторан

Замислете ресторан.

• Салата за јадење е фронтендот. Менија, маси и бележницата на келнерот. Тоа е она што го гледаат гостите и треба да биде пријатно и лесно за користење.
• Кујната е бекендот. Гостите никогаш не влегуваат таму. Таа ги прима нарачките, проверува дали јадењето е достапно, го готви и одбива чудни барања. Правилата живеат тука.
• Магацинот и книгата за нарачки се базата на податоци. Тие го чуваат она што постои и што е нарачано, па ништо не се заборава при смена.

Ресторан со само салата за јадење може да ви покаже убаво мени, но не можете да се нахраните. Тоа е апликација само со фронтенд што се преправа дека е full-stack.

Трите слоја подетално

Слоевите разговараат меѓу себе по фиксен редослед. Фронтендот бара нешто од бекендот преку API — дефиниран сет барања што бекендот ги прима. Бекендот го проверува барањето, чита или запишува во базата и враќа одговор. Фронтендот никогаш не разговара директно со базата.

Тој редослед е најважната безбедносна идеја во целиот стек. Сè во фронтендот може да го прочита и промени посетителот, бидејќи работи на неговиот уред. Затоа правилата — „само сопственикот може да ја види оваа фактура“, „купонот може да се искористи еднаш“ — мора да се спроведат во бекендот. За повеќе за поделбата, видете фронтенд наспроти бекенд.

Работен пример: апликација за резервација на часови

Да речеме дека држите студио за јога и сакате луѓето да резервираат часови онлајн.

Што прави посетителот: ја отвора страницата, ги гледа часовите за оваа недела, допира еден, се најавува и резервира место.

Што се случува во позадина:

1. Фронтендот го прикажува распоредот. За да го пополни, го прашува бекендот: „Кои часови се оваа недела и колку места се слободни?“
2. Бекендот ја прашува базата за часовите и ги брои резервациите за секој, па одговара.
3. Посетителот допира Резервирај. Фронтендот испраќа „резервирај час 42 за оваа најавена личност“.
4. Бекендот проверува: дали оваа личност навистина е најавена? Дали часот е полн? Дали веќе е резервирано? Само ако е сè во ред, запишува нов ред за резервација во базата.
5. Бекендот одговара „резервирано“, а фронтендот прикажува потврда.
6. Подоцна, сопственичката на студиото се најавува и ја гледа листата на часови. Бекендот проверува дали е администратор пред да ги покаже имињата на сите.

Сега замислете дека ова било изградено само како фронтенд. Распоредот можеби би се прикажал, а копчето „Резервирај“ би покажало убаво штиклирање, но резервацијата би исчезнала при освежување, бројот на „слободни места“ би бил погрешен за сите други, а сопственичката никогаш не би ја видела. Чекор 4 — проверките — би недостасувал целосно. Тоа е практичната разлика.

Клучни поими

• Фронтенд (страна на клиентот): делот што работи во прелистувачот.
• Бекенд (страна на серверот): делот што работи на сервер. Се нарекува и API сервер.
• База на податоци: место каде податоците се чуваат на организиран начин. Видете што е база на податоци.
• API: листа на барања што бекендот ги прима од фронтендот или други програми.
• Автентикација: проверка кој е некој (најава). Авторизација: проверка што смее да прави.
• Распоредување (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) покрај веб-страницата. Сè работи заедно во жив преглед и се објавува на јавна URL адреса. Страницата во документацијата за апликации со повеќе услуги покажува како веб-страницата и API-то се прегледуваат и објавуваат заедно, а страницата за градител на full-stack апликации содржи почетни точки.

Прашања