Pull to refresh

Frontend + метод fetch + СУБД = fullstack?

Современные тенденции в Web-разработке, или «лёгкий» backend


Хотелось бы поделиться размышлениями о наметившихся тенденциях в Web-разработке.

На сегодняшний день в мире Web-разработки существует почти официальное разделение разработчиков на категории frontend и backend.

Frontend это те, кто делает пользовательский интерфейс для клиентского устройства.
Backend разработчики обеспечивают серверную часть функционала Web-сайта.

В различных публикациях, со стопроцентным совпадением, обозначен набор рабочих инструментов frontend разработчика. Это HTML, CSS и JavaScript (плюсом есть ещё упоминания о CSS-фреймворках, но CSS-фреймворк это тот же CSS, а фреймворк понятие растяжимое, каждый может сам написать себе фрейворки хоть и на HTML, хоть и на JavaScript).

Однако, главным же инструментом frontend разработчика, по моему убеждению, являются интерфейсы DOM. Без знания базовых DOM интерфейсов, без понимания логики DOM, никакого frontend-а быть не может, а JavaScript превращается просто в игрушку.

Зачем же frontend разработкам нужен backend?

Самой главной, да пожалуй, и единственной существенной, причиной является необходимость в едином хранилище данных на сервере для всех потенциальных пользователей Web-сайта. А главным инструментом backend разработчика является СУБД, так как у frontend-а исторически не было хорошего функционала для формирования запросов к базе данных и получения ответной информации из неё.

До сравнительно недавнего времени frontend, чтобы обратиться к серверной базе данных, формировал HTTP-запросы и отправлял их на сервер с помощью специальных HTML тегов формы. Сервер должен был запустить серверный скрипт backend-а, который делал соответствующий запрос в базе данных, получал ответ и отправлял его frontend-у.

То есть серверным скриптам (например, PHP-скриптам) пришлось научиться работать с СУБД. А, поскольку, тот же PHP изначально был предназначен совсем для других целей, то ответить он мог только HTML-кодом. Этот код не предназначался для скрипта JavaScript на клиенте, а сразу же интерпретировался браузером. И это создавало огромный геморрой для frontend-а.

Затем появились технология AJAX (Asynchronous JavaScript and XML) и объект XMLHTTPRequest, который стал доступен скрипту JavaScript. И скрипт JavaScript смог формировать клиентский запрос, и, по цепочке: серверный скрипт — сервер — браузер — клиентский скрипт, смог получать ответ в формате XML или JSON, который проходил через браузер, минуя его интерпретацию.

Недавно же, в DOM, появился метод fetch, функционал которого подобен XMLHTTPRequest. Но механизм метода fetch построен на стандартных объектах — Request и Response, и он доступен в Worker-ax.

Вследствие этого, ответ от серверного скрипта может быть принят в стандартных JavaScript форматах – ArrayBuffer, Blob, FormData, JSON и строковом.

Вследствие этого же механизм метода fetch более функционален, чем механизм XMLHTTPRequest, и более встроен в логику развития интерфейсов DOM.

И это, на мой взгляд, назревающая революция в отношениях frontend-а и backend-а.

Строго говоря, метод fetch нельзя отнести к технологии AJAX, которую сейчас трактуют как технологию создания Web-сайтов с подгружаемым контентом. Ведь в методе fetch не используется XML. Видимо с названием технологии немного поторопились, но не будем придираться, тем более, что название красивое.

Однако, теперь frontend разработчику, ко всему, достаточно знать СУБД и уметь проектировать базы данных. Не такая уж сложная задача, учитывая, что любой уважающий себя программист, создающий пользовательские интерфейсы, это знает и умеет.

Написать же несколько строчек кода, на том же PHP, для обработки запроса от клиентского скрипта, формирования соответствующих SQL-запросов, и отправки результата клиенту, не так уж сложно.

На мой взгляд, функционал метода fetch ещё не лишён недостатков:

Во-первых, он реализован на промисах. Это, скорее всего, дань моде, так как в данном случае это не было необходимостью, а писать цепочки промисов не самое приятное занятие. Но это, наверное, дело вкуса.

Во-вторых, и это серьезней, механизм метода fetch построен на протоколе http(https). Хотя сейчас уже официально существует протокол ws(wss), который специально создан для обмена данными в режиме “скрипт-скрипт”. Этот протокол уже используется технологией WebSocket.

Сама технология WebSocket была бы идеальной альтернативой методу fetch, если бы не использовала постоянное логическое соединение с сервером, практическая поддержка которого на сервере связана с очевидными издержками.

Но даже в текущем состоянии применение механизма метода fetch позволяет создавать очень производительные решения с “легким” бэкенд-ом.

Можно пофантазировать, и представить себе, что формировать SQL-запросы можно будет в клиентском скрипте (это возможно и сейчас, но механизм не очень функционален). Можно также предположить более широкое распространение протокола ws(wss).

Однако, в любом случае, “чистым”, к примеру, PHP-кодерам и любителям PHP фреймворков надо задуматься над тенденцией. Может уже пора менять квалификацию?
Tags:
Hubs:
You can’t comment this publication because its author is not yet a full member of the community. You will be able to contact the author only after he or she has been invited by someone in the community. Until then, author’s username will be hidden by an alias.