Современные тенденции в 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 фреймворков надо задуматься над тенденцией. Может уже пора менять квалификацию?
Автор: друже
