Обновить

Комментарии 5

Вот за это я и люблю JAMstack - за то что всей этой рокет сайнс там нет. Странички грузятся легко и быстро (с ближайшего узла CDN), в памяти занимают места мало, процессор не грузят. Любой поисковик легко увидит, где там у вас какой товар, с какими характеристиками и по какой цене. При этом - полный функционал (хабр или электронный магазин вполне можно делать на jamstack, reddit на нем и работает вроде). Для сложных вещей - будет JS но будет только там, где без него нельзя обойтись. А где можно - там не будет.

Сначала были статические странички - и ресурсы расходовались эффективно.

Потом CMS появились и каждый раз, на каждый запрос юзера, чтобы вевести заголовок "ООО Фортуна тел. 111-22-33" CMSка лезла в СУБД - А как мы называемся? (я 2 секунды назад спрашивала, да, но забыла). А каким цветом надо писать заголовок? А какой у нас рекламный слоган? а какой у нас адрес? Этот адрес меняется раз в 15 лет, но запрашиваться может 15 раз в минуту, чтобы выплюнуть HTMLку. Спасибо хоть СУБД немного кеширует.

Потом еще фронтендеры добавили динамики и сложности (будто бы сложность - это что-то хорошее, будто бы она показывает профессионализм, смотрите как сложно я могу сделать простую вещь! Что-то медленно.... а какой райзен у вас стоит?). Теперь уже фронтенд начинает много думать. Мы показываем меню? Окей, а сколько у нас там пунктов? Ух-ты, семь! А какие? Ух-ты, есть раздел "контакты" в меню - хорошо, сейчас нарисую. Ух, а еще у нас есть раздел "цены" - я и не ожидал - тоже нарисую, да. Над каждой буковкой фронтент размышляет. Над каждой моргающей звездочкой (которой должен помечаться пункт "Акции!") - тоже думает. Даже если звездочки нет - фронтенд подумает, все взвесит и примет решение ее не рисовать.

Каждая козявка, каждый пиксель на экране, каждый элемент меню теперь "умный" и "думает". И все это жрет ресурсы. Вспоминается гангстерская сцена из "Подпольной империи":
- Как это смогло произойти?
- Ну.... я думал, они все мертвы.
- Что!? Ты ДУМАЛ? Он, б.... ДУМАЛ!! Ты кто? ДОЛБАННЫЙ АРИСТОТЕЛЬ?

"Было бы величайшей ошибкой думать". Не должно быть никакой логики там, где как-то можно без нее.

Конечно, где-то эти сложные схемы оправданы. Но мне кажется, любое сложное (ресурсоемкое) техническое решение должно обсуславливаться, и точно не через "ну это модная технология, сейчас все на ней делают, я хочу эту строчку опыта в резюме", а через "на более простых технологиях это сделать невозможно по таким-то причинам".

REST stateless и называть что-то у чего есть состояние RESTом имеет ровно такие же основания, как и назвать яблоко апельсином - оба фрукты, но смысл разный. Но сравнение с сервером, не спорю, имеет место быть.

Автор REST в своей диссертации , в которой он собственно представил REST, очень явно обосновывает свое решение ссылаясь на другую работу, ссылку на которую я также привел в статье. Суть архитектуры в том, что она явно обозначает ограничения которые должны быть соблюдены для достижения результата, при этом архитектура не диктует «как» реализовывать. Он пишет:

We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request

То есть stateless – не REST, а «коммуникация» между клиентом и сервером. Это в том числе вытекает из ограничений остальных компонентов системы, например транспорта. Каждый TCP пакет в последовательности должен содержать идентификатор соединения, каждый Request должен содержать идентификатор пользователя и т.д.

Тоже остается справедливым и для фронтенда, где каждый Request (Event), содержит всю необходимую информацию. Когда мы пишем el.addEventListener('input', cb), браузер передает не просто строку с новым текстом, полагая что мы понимаем от какого именно <input /> оно пришло, а Event со всей необходимой информацией, делая нашу «шину» stateless по природе.

А кто является клиентом? Просто если человек, который тыкает на кнопки, то запросом будет не Event, а само действие нажатия на кнопку. Если браузер, то тут возникают сложности в отделении браузера от браузера.

Вся суть статьи:
"А давайте на фронте разделять ответственность, и использовать название уже существующих паттернов!"
Не обращать внимания, на названия который вводят фреймворки аля, "хуки", "композаблы".
Или я что-то упустил?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации