frontend/backend - меняем линию отреза
Вот пост про WebAssembly: https://yorool-gui.livejournal.com/267418.html - навеял мысли.
На классических, server-side rendered, веб-проектах, роли распределяются как-то так:
- backend: достать данные с БД в VM-ки, сунуть в шаблоны, убедиться что данные все под рукой, убедиться что запросы эффективные, отдать фронтендерам. Плюс обмазать кешем, плюс навести порядок в коде - включая вьюшки. Всякий бандлинг CSS/JS, локализацию - тоже бекендеры делают
- frontend: допилить шаблоны, обмазать CSS-кой, посыпать JS-кой на JQuery
Когда мы начали делать SPA-шечки, линия реза переехала:
Backend:
Достать данные с БД, положить в VM-ки, пинать хуи, ебать овец, изобретать пизданутые микросервисные архитектуры
Fontend:
В хорошем случае (власть на проекте у фронтов):
- понять что надо для страницы
- рассказать бекендеру какое запилить API, чтобы все вынуть в 1-2 запроса
В плохом случае (власть у бекендеров):
- сходить в пизданутыми дебилами задизайненное микросерисное API
- 10 раз сходить с каждой страницы, потому что пидарасы дебилам продали REST, и они теперь отдают белочек и зайчиков с отдельных эндпоинтов
- все еще в параллель, чтобы быстро
- обработав ошибки, потому что у дебилов сервис про зайчиков лежит, а про белочек - нет, а зайчики - не обязательны. И похуй всем, что все с одной БД берется.
В любом случае:
- куда-то данные сложить удобно, кешить
- как-то кэши инвалидировать
- ну и дальше еще написать UI, который в 100 раз сложнее того, что было с server-side rendering-ом
Короче, текущая огранизация труда, часто приводит что бекенд может построить красивое халявное REST-API вида GET /api/person?id=123. А что фронтендерам оно неудобно - их не ебёт, у них так в книжках написано делать. Этот пиздец иногда и к полному факапу проектов приводит.
Ну и вообще, REST сдох, лучше пока не подвезли, и кому-то надо велосипедить.
Я думаю что должна родиться новая специализация, вот с таким скоупом:
[ ---------------------- Data Access Developer ----------------------- ] [ -------------- front -------------- ]
[DB] [ Business Logic ] [ Wire Protocol ] [ Front-end data store ] [ CSS, реакты, пауки из розетки ]
Т.е. фронт от бека получает на клиенте API типа store.getPersons({ name: 'Ivan' }) - и имеет право его дергать 60 раз в секунду по 100 раз на кадр. Как оно данные достает и кэшит - его не парит, на фронте и без этого забот тьма.
Можно сказать что это то, что сейчас называют фулл-стеком. Но по-факту, людей умеющих хорошо CSS/JS/интерактивщину - достаточно, эта часть - тоже целый хитрожопый мир, но она легко отпиливается и делегируется. Поэтому пусть сам UI остается фронту. А чтобы на фронте были данные, быстро и свежие - вот там надо нормально сечь в распределенных системах, ну и хорошо уметь в алгоритмы и данные.
С WebAssembly фронтовую часть про данные, можно написать на том же языке, на котором бэк. Можно будет пилить обе части на чем угодно. И обмазывать тестами, даже не стартуя фронт.
По факту, у нас уже сейчас роли похоже распределяются. Думаю что скоро это будет трендом.
На классических, server-side rendered, веб-проектах, роли распределяются как-то так:
- backend: достать данные с БД в VM-ки, сунуть в шаблоны, убедиться что данные все под рукой, убедиться что запросы эффективные, отдать фронтендерам. Плюс обмазать кешем, плюс навести порядок в коде - включая вьюшки. Всякий бандлинг CSS/JS, локализацию - тоже бекендеры делают
- frontend: допилить шаблоны, обмазать CSS-кой, посыпать JS-кой на JQuery
Когда мы начали делать SPA-шечки, линия реза переехала:
Backend:
Достать данные с БД, положить в VM-ки, пинать хуи, ебать овец, изобретать пизданутые микросервисные архитектуры
Fontend:
В хорошем случае (власть на проекте у фронтов):
- понять что надо для страницы
- рассказать бекендеру какое запилить API, чтобы все вынуть в 1-2 запроса
В плохом случае (власть у бекендеров):
- сходить в пизданутыми дебилами задизайненное микросерисное API
- 10 раз сходить с каждой страницы, потому что пидарасы дебилам продали REST, и они теперь отдают белочек и зайчиков с отдельных эндпоинтов
- все еще в параллель, чтобы быстро
- обработав ошибки, потому что у дебилов сервис про зайчиков лежит, а про белочек - нет, а зайчики - не обязательны. И похуй всем, что все с одной БД берется.
В любом случае:
- куда-то данные сложить удобно, кешить
- как-то кэши инвалидировать
- ну и дальше еще написать UI, который в 100 раз сложнее того, что было с server-side rendering-ом
Короче, текущая огранизация труда, часто приводит что бекенд может построить красивое халявное REST-API вида GET /api/person?id=123. А что фронтендерам оно неудобно - их не ебёт, у них так в книжках написано делать. Этот пиздец иногда и к полному факапу проектов приводит.
Ну и вообще, REST сдох, лучше пока не подвезли, и кому-то надо велосипедить.
Я думаю что должна родиться новая специализация, вот с таким скоупом:
[ ---------------------- Data Access Developer ----------------------- ] [ -------------- front -------------- ]
[DB] [ Business Logic ] [ Wire Protocol ] [ Front-end data store ] [ CSS, реакты, пауки из розетки ]
Т.е. фронт от бека получает на клиенте API типа store.getPersons({ name: 'Ivan' }) - и имеет право его дергать 60 раз в секунду по 100 раз на кадр. Как оно данные достает и кэшит - его не парит, на фронте и без этого забот тьма.
Можно сказать что это то, что сейчас называют фулл-стеком. Но по-факту, людей умеющих хорошо CSS/JS/интерактивщину - достаточно, эта часть - тоже целый хитрожопый мир, но она легко отпиливается и делегируется. Поэтому пусть сам UI остается фронту. А чтобы на фронте были данные, быстро и свежие - вот там надо нормально сечь в распределенных системах, ну и хорошо уметь в алгоритмы и данные.
С WebAssembly фронтовую часть про данные, можно написать на том же языке, на котором бэк. Можно будет пилить обе части на чем угодно. И обмазывать тестами, даже не стартуя фронт.
По факту, у нас уже сейчас роли похоже распределяются. Думаю что скоро это будет трендом.