Штука продумана, але як на мене забагато common/backend патернів там які на фронті здебільшого надлишкові.

Ну зараз спробую. В моєму випадку я розглядаю UI як джерело істини і відповідно до нього нарізаю функціональність. Тобто якщо у нас є модалка створення сутності, то відповідно до мого підходу, це атомарна функціональність. Уявимо собі що ми для неї створюємо директорію EntityCreateModal і в цій директорії ми зберігаємо все що стосується логіки дій цієї модалки — виклик API, можливо стейт цієї модалки якщо він потрібен. Функціональність яка заявлена в EntityCreateModal не перевикористовують ніякі інші UI віджети. Так, самі UI компоненти які ми стілізували використовуються наскрізно по всьому проекту. Таким чином ми маємо ізольовану функціональність яка гарантовано не зміниться якщо ми запроваджуємо зміни в інших частинах проєкту. Виходить більше коду, але він до біса стабільний, підтримуємий та розширюваний.

Звісно, подібний підхід може бути надлишковим для невеликих за розміром проектів, або тоді коли треба шось швидко дуже накидати.

Перш за все хочу подякувати за такий труд — стаття обʼємна та наповнена інформацією.

По друге хочу висловити свою думку стосовно подібного підходу. Воно звісно всіляко краще ніж просто кодити аби що аби куди. І мені здається що непогано ляже на не дуже великі проєкти. Але от далі можуть бути складності. При рості проєкту буде дуже складно утримувати в голові ось ці звʼязки між шарами, ну типу що де і коли викликається. Особливо важко може стати під час внесення змін або рефакторингу. Тобто коли декілька ui components мають в залежностях певний метод/клас з сервісного шару і нам треба внести зміни в один з цих компонентів. Треба або дописувати нове в сервісний шар, або обкладатися conditions типу якщо це ось такий компонент то роби так і так.

Ви можете сказати «раз критикуєш, то пропонуй», то я відповім що узагальнено vertical slicing, це коли у тебе фіча поєднує маленьку частину з кожного шару, буде більш прогнозований в роботі хоч і більш багатослівний, бо треба буде писати більше коду бо функціональність однієї фічі не може перетікати в іншу.

Суперовий дайджест! Я хоч в не джавіст але дивлюся і читаю з задоволенням (дома тихенько тицяю Java поки ніхто не бачить 😄)

Оце прям дуже цікаво. Виявляється що і в таких наче сталих областях як алгоритми сортування можна зробити покращення!

Дякую за висвітлення цікавих можливостей PG.

Перш за все дякую за цікавий аналіз і факти, подруге я дещо здивований тому скільки ChatGPT зміг зробити правильно. Але нажаль, або на щастя, в тій же web розробці люди не вирішують подобних задач і задчі які треба вирішити вони здебільшого не про те як написати код, а про те як правильно сформулювати те що треба зробити виходячи з бізнес-вимог. А вже далі дійсно йде більш меньш рутина.
Так що всі заклики до того що треба кидати айтішку бо ChatGPT прийшов, то дійсно передчасно, але використовувати це як існтрумент який може пришвидшити і спростити роботу, то мабуть в найближчому майбутньому вже буде можливо. Точніше навіть не ChatGPT як такий, а буде безліч інструментів, бо OpenAI довели що наразі це вже можливо.

Непогано викладено, структуровано і зрозуміло. Дякую за гарний допис.

Я б ще трошечки розписав про «складність реалізації» SSR. Бо якщо ми то не будемо робити руками, то той самий Next.js зробить все за нас, і складність то вже «розщеплення стану» між сервером і клієнтом, бо коли ми пишемо логіку, то там буде найбільше підводного каміння. Next 13 beta app directory підхід наче виправляє цей недолік, але воно покищо в беті.

Це так само як казать, майбутнє за Х замість Y — підстав будь яку мову, і ще шось. Але як завжди все залежить від вимог, як функціональних так і нефункціональних. І якщо інколи serverless лягає просто шикарно, то інколи то як п’ята нога.

Об’єктивно, без всіляких точок зору шо JS гівно, або Python гівно — JS кращий вибір для того щоб стартонуть. Так, це далеко не ідеальна мова, але зараз вона всюди. У вас буде більший вибір на ринку праці і по моєму досвіду, зайти в IT простіше зі сторони фронтенду. А вже як станете більш меньш на ноги то будете вже думати про те щоб вивчити якусь іншу мову, або свічнутися кудись.

Пізно.

Щодо typescript, то у них точно було в планах написати під все d.ts, а далі вже і писати можливо нові модулі на TS. Хоча Шемседінов критично ставиться до використання TS де не попало. Так шо не зрозуміло до чого вони в цілому прийдуть.

А от loopback мені рік тому не сподобався. Дуже він хитрозроблений мені. Але треба освіжити погляд ))) З приводу швидкості — того що демонструє Express здебільшого вистачає на все. Але дійсно залежить від потреб і задач.

Ми у себе використовуємо покищо fastify, але багато чого поверх нього написали.

В Metarhia (це платформа взагалі, але я просто так використовую цю назву бо так зрозуміліше) теж є hot reload, автоматичний резолвінг нових модулів, архітектура, генерація api-client, можливість використовувати застосунок через HTTP або WebSocket не пишучи для цього взагалі нічого ручками. Ну то я так, теж поверхнево дивився, але воно не схоже на те що є.

Apiato — Vertical Slicing architecture з можливістю розбивати застосунок на контейнери і сервіси.

ApiPlatform — ентерпрайзний комбайн теж з генерацією api-client кучею підкапотних генерацій (CRUD) і іншої магії. Так в двох реченнях не напишеш.

На Dismod я поверхнево дивився. Виглядає міцно і цікаво, але я поки не зрозумів що воно мені принципово змінить. Наприклад та ж сама Metarhia робить прям інший підхід до побудови застосунків. Але хочеться чогось накшталт Symfony/ApiPlatform або Apiato. Але покищо маємо шо маємо.

Та в тому то і справа що це виглядає так наче вибору іншого нема от і беремо Nest. Ну і не можна відмовити їм у маркетингу і в досить гарній документації.

А згодом ми отримуємо Decorator Driven Development як, наприклад, в Nest.js ))))) Я не стверджую що це погано, просто мені це наприклад не подобається візуально і ще тим що з великою кількістю декораторів можна легко заблудитися в контексті того що відбувається.

Щодо статті, розкладено гарно і зрозуміло, але хотілось би побачити більше прикладів з реального життя. Дякую!

Щодо «прокидання черкз всю апку» , я вже на досвіді впевнився що дані треба отримувати якомога ближче до того місця де ми їх рендеримо. Це суттєво спрощує розробку і не тільки роути мінімально залежать одне від одного, але й віджети вцілому.

З генерацією цікава штука, треба буде ближче подивитися.

Якщо у вас вже є досвід використання Redux, то раджу ознаїомитись з RTK-query (Redux Toolkit Query). Це теж реалізація паттерна SWR, але ви залишаєтесь в межах знайомого стейт менеджера, який вам все одно скоріш за все знадобиться.

А в цілому підхід SWR (Stale While Revalidate) мені здається трошки недооціненим. Хоча дуже сипльно спрощує розробку. Але звісно не срібна куля і також є свої «вузькі місця»

Найпростіше мабуть буде кубер використовувати, бо кубер він всюди кубер.