Парадигми на фронтенда: как да изберете архитектурата на вашето уеб приложение

Преди да изберете инструмент, изберете парадигма

Когато един екип спори „React или Angular?“, често спори за грешния въпрос. Решението, което наистина струва години поддръжка, е друго: къде и кога се сглобява екранът. В браузъра на потребителя? На сървър, при всяко посещение? Само веднъж, при изграждането на сайта? Или е приложение, инсталирано на компютъра или на телефона?

Всеки отговор е парадигма, с реални предимства и разходи, които не се виждат в демонстрацията. Тази статия е карта за един CTO или дигитален директор: какво представлява всяка, кога подхожда според бизнеса, какво струва наистина и как да се излезе от една, без всичко да се пише наново. Това е преценка, не рецепта.

1. Приложение на една страница (SPA)

MDN го определя като уеб приложение, което зарежда един-единствен документ и обновява съдържанието му с JavaScript, когато трябва да се покаже нещо друго. Предимството: потребителят навигира без презареждане на цели страници, с по-динамично изживяване. А MDN назовава и цената: SEO, повече усилия за поддържане на състоянието и навигацията и за смислено измерване на производителността.

Документацията на React добавя още една: SPA се започват лесно, но могат да имат по-бавно първоначално зареждане, а ако всеки компонент поиска данните си чак след като е изрисуван, се образуват „каскади“ от заявки, при които всяка стъпка чака предишната.

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

2. Изобразяване от страна на сървъра (SSR)

Сървърът сглобява HTML при всяка заявка и го изпраща вече готов. Angular го обобщава така: сървърът отговаря с изобразен документ, което дава по-бързо зареждане от изобразяването от страна на клиента и пълен HTML за роботите на търсачките. web.dev назовава противотежестта: първият байт може да се забави, защото сървърът трябва да поработи, преди да отговори.

Има нюанс, който си струва да се разбере: страницата „изглежда“ готова, преди да е интерактивна. web.dev го описва като хидратация: докато JavaScript не приключи, страницата изглежда готова, но интерактивните ѝ функции още не отговарят.

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

3. Статично генериране (SSG)

HTML на всеки URL адрес се генерира веднъж, при изграждането на сайта. Според web.dev това дава постоянно бързо време за отговор и позволява да се сервира от мрежа за доставка на съдържание (CDN); според Angular сайтът може да се разположи само с CDN или файлов сървър, без да се поддържа собствен сървър. Границата също е в web.dev: не е приложимо, когато има милиони уникални страници, и изисква URL адресите да са известни предварително.

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

4. Хибридни подходи и острови

На практика рядко е „или едното, или другото“. Angular описва хибридното изобразяване като съчетание на сървър, статично и клиент, маршрут по маршрут. Next.js го изразява с компоненти на сървъра и на клиента: по подразбиране страниците и оформленията (layouts) се сглобяват на сървъра, а само това, което се нуждае от състояние, събития или API на браузъра, се маркира като клиентско, така че се изпраща по-малко JavaScript.

// Илюстративно, от документацията на Next.js: страницата се сглобява на сървъра
// и само бутонът (маркиран с 'use client') е интерактивен в браузъра.
<LikeButton likes={post.likes} />

Архитектурата на островите довежда идеята докрай. Документацията на Astro я описва така: по-голямата част от страницата е статичен HTML и само малки „острови“ получават JavaScript, единствено където е нужно.

Къде се вписва: почти всеки публичен продукт с интерактивни зони: статичен каталог с калкулатор на оферти, сайт със съдържание и количка.

5. Микрофронтенди

Разделят голямо приложение на части, които различни екипи изграждат и пускат поотделно. Документацията на single-spa ги нарича „микроуслуга в браузъра“, всеки със собствено хранилище и собствено изграждане; Module Federation на webpack позволява отделни компилации да образуват едно приложение и да споделят зависимости.

Сега, онова, което тези страници не казват, а ние казваме: един микрофронтенд решава организационен проблем, а не технологичен (наша преценка; цитираните източници описват ползи, не разходи). Има смисъл, когато няколко екипа, с различен ритъм на пускане, се сблъскват в една и съща кодова база. При малък екип добавя шевове, които някой трябва да поддържа: споделени версии на библиотеки, визуална последователност между частите и изживяване, което да не изглежда зашито.

И има разход, който стига до потребителя: ако всеки екип зарежда собствени копия на едни и същи библиотеки, браузърът изтегля същото по няколко пъти. Самите източници препоръчват да се споделят екземплярите на големите библиотеки; това ще се случи само ако екипите се координират и се проверява със сигналите за производителност, които споменаваме по-долу.

6. Настолни и мобилни приложения за много платформи

Когато браузърът не стига, има три пътя с различна природа:

• Инсталируемо уеб приложение (PWA). Според MDN и web.dev това е приложение, изградено с уеб технологии, което се инсталира, може да работи без мрежа, да получава известия и да ползва цял екран, с една-единствена кодова база. MDN уточнява, че продължава да разчита на браузърен двигател и че трябва да се проектира с прогресивно подобряване, защото напредналите API не са във всички браузъри.
• Десктоп. Electron пакетира Chromium и Node.js, за да се правят настолни приложения с JavaScript, HTML и CSS за Windows, macOS и Linux; документацията му уточнява, че процесът, който показва интерфейса, няма пряк достъп до Node.js, от съображения за сигурност. Tauri поема друг път: ползва уеб двигателя на самата операционна система и основа на Rust, което документацията му посочва като причина приложенията му да са много малки. Всяко решение има цена: когато носите собствен двигател, поведението е по-еднородно между системите; когато разчитате на този, който идва с всяка система, пестите размер, но двигателят може да се различава от система на система и екипът трябва да решава визуални и поведенчески разлики (наша преценка; и в двата случая трябва да се тества във всяка операционна система, която поддържате). Кога десктопът наистина е отговорът — принтери, четци, везни, локални файлове — обясняваме в Вашето уеб приложение вече не стига?.
• Мобилни за много платформи. React Native създава, по време на изпълнение, нативните изгледи на Android и iOS от компоненти на React; затова, според документацията му, приложенията изглеждат и се усещат като всяко друго. Това е трети път между мобилната уеб версия и две отделни нативни разработки.

Кога не е нужно нищо от това

Ако ви трябва блог или стандартен онлайн магазин, вече изградена платформа за съдържание, изобразявана на сървъра по класическия начин, може да е по-добра сделка от изграждането на архитектура по поръчка (наша преценка). Парадигма се избира, когато има проблем, който я оправдава, а не заради новост.

Как да изберете според бизнеса си

Разходите, които не се виждат в демонстрацията

• Разход за експлоатация. Статичното се сервира с CDN; изобразяването на сървъра изисква изпълнение на код при всяко посещение, на собствен сървър или на доставчик, с цена според употребата, мащабиране и мониторинг. Това, че доставчикът управлява инфраструктурата, променя кой я експлоатира, но не и че някой трябва да я наблюдава.
• Разход за таланти. Всяка парадигма изисква различни умения. Един добре направен хибрид изисква екипът да разбира какво къде се изпълнява; иначе се появяват грешки, които стават само „на сървъра“. И важи обемът: инструмент с по-малко хора, които го владеят, може да поевтини инфраструктурата и да оскъпи наемането (наша преценка).
• Разход за измерване. Изборът на парадигма сам по себе си не подобрява производителността. Google определя трите си сигнала за изживяване на 75-ия персентил от зарежданията, разделени между мобилни устройства и компютри: измерват се с реални потребители, преди и след всяко решение.
• Разход за сигурност. Преместването на логика на сървъра защитава тайните, но и изложеният сървър трябва да се защитава; преместването на логика на клиента я прави публична (подробно го обясняваме в Какво трябва да има професионалният фронтенд).
• Разход за излизане. Най-забравеният: колко струва да промените решението си. Парадигма, която налага пренаписване, за да се смени, е скъпо решение, дори днес да изглежда евтино.

Миграция без пренаписване на всичко

Пренаписването от нулата е опцията, която струва най-много и най-късно дава резултати. Алтернативата, която препоръчваме като преценка, е миграция по маршрути, като се започне от тези, които тежат най-много за бизнеса. Източниците я правят възможна: Next.js твърди, че съществуващо SPA може да мигрира без да се пише изцяло наново, че може да започне като статичен сайт или дори като строго SPA и да добавя сървърни функции постепенно, и предлага ръководства за поетапна миграция от други среди. Документацията на React отбелязва, че един фреймуърк покрива от самото начало онова, което приложение само за клиента решава ръчно, като избягването на каскади от заявки.

Три въпроса подреждат една миграция:

1. Кой екран ви струва най-много днес? Бавно зареждане в екрана, който носи приходи, или публична страница, която не се намира. Започнете оттам, не от най-лесния.
2. Какво може да се премести, без да се пипа бизнес логиката? Презентацията обикновено се отделя от логиката; ако не, това е първата находка.
3. Как ще разберете, че е станало по-добре? Определете предварително сигнала (производителност, конверсия, грешки) и го измервайте с реални данни.

Какво да отговорите, преди да решите

Пет въпроса, на които един комитет може да отговори за един час: кой идва от търсачка и кой не? Какви данни не могат да живеят на устройството? Колко екипа пипат един и същ продукт? Какъв канал ползва най-важният ви клиент? И най-вече: колко би ви струвало да смените архитектурата след три години?

Заключение

Правилната архитектура не е най-модерната: това е тази, която вашият бизнес може да експлоатира, измерва и променя. В Hábil помагаме да се избере с общ критерий и да се изгради пътят на миграция, който екипът ви може да поддържа.