Круды от Иуды
Размышления о том, почему Backend и Frontend это end.
Пафосно безмерно, сложно непомерно. Точно современно? Или же безмерно? Речь пойдет сегодня про подход народный, К сервер сайд решениям, или новомодный?
Сегодня — о священной войне в IT, о великом расколе, который привел современных инженеров в очень интересное состояние. О разделении на frontend и backend, и это только часть разделения.
Эпоха Первая: Единство и простота (начало 1990-х)
В самом начале, в эпоху зарождения Всемирной паутины, все было просто. Приложения (если их можно было так назвать) грузились в браузере целиком с сервера. Каждое нажатие кнопки или ссылки приводило к новому запросу на сервер и полной перезагрузке страницы. Работало, но было не всегда быстро и уж точно не всегда удобно. Это был мир Server-Side Rendering в его чистом виде.
Эпоха Вторая: Великий Раскол (середина 2000-х)
Потом все изменилось. JavaScript, рожденный еще в 1995 году, повзрослел. А в 2005 году с появлением термина AJAX (Asynchronous JavaScript and XML) случился прорыв. Появились SPA — Single-Page Application, «приложения одной страницы». Теперь браузер или телефон один раз загружал «оболочку» приложения, а весь код, который с вами работал, уже жил внутри. Он сам отправлял запросы за данными, рисовал интерфейс и был почти как десктопная программа.
И тут-то и случился раскол. С одной стороны — сервера, на которых крутится бизнес-логика и базы данных. Их почему-то решили называть backend (задний двор). С другой — то, что видит пользователь. Это frontend (то, что спереди).
Почему так произошло? Приложения усложнялись. Требовалась интерактивность, быстрота и UX, как в десктоп-программах. Овладевать всеми тонкостями верстки, JS, а еще серверными языками, базами данных и администрированием стало для одного человека почти невозможно. Так началась естественная специализация.
Фронтенд стал не только тем, что в браузере. Появился «толстый клиент» (desktop-приложения) и целое направление — мобильные клиенты. Ух, развелось квалификаций, что грязи! Все едино — все там будем.
Когда я начинал в эту сферу погружаться (а это было как раз до этого бума), ничего такого еще не придумали. Поэтому в бытность свою могу выполнять любую роль. Таких теперь называют Full-stack (термин набрал популярность в early 2010-х), гы-инженеры. Но я думаю, первое слово можно упустить, и таких «модных» универсалов в современном мире становится все меньше. Цените это.
Эпоха Третья: Пакт о CRUD и гонка вооружений (конец 2000-х – середина 2010-х)
Разделившись, лагеря начали спорить, кто и что должен делать. Данные-то живут на сервере, в ведомстве бэкендеров. И не комильфо отправлять запросы с клиента напрямую в базу — это дыра в безопасности. Но в начале и так гении делали!
Тогда договорились: за данными ходить на специальный сервер-посредник. И опять же, поначалу фронтендеры просили бэкендеров дать им прямой доступ к слоям бизнес-логики. Но кто-то «умный» на бэкенде сказал: «А чего мы будем из нашего хорошего приложения (фронтендеры, как вы можете догадаться, серверную часть за свою не считают) принимать ваши страшные запросы? Дайте нам что-то простое. Нам нужны документы, задачи, пользователи. Вот и дайте нам операции над ними».
Так возник CRUD (Create/Read/Update/Delete), а вместе с ним и стандартные REST API. Появились контроллеры и сервисы, и все вроде бы хорошо. Бэкендеры пишут CRUDы, фронтендеры их вызывают — и вуаля, все работает, все при деле. Заняли кучу народа, байтики гоняют туда-сюда. Ей богу, цифровая канцелярия: бумажки перекладываем и фантики оформляем.
А что видим в итоге? Фронтенды, чтобы управлять сложностью, придумали Redux (2015 год) и наворотили всякой реактивной нечисти. А бэкенды, чтобы не писать SQL-запросы руками, завернули CRUDы в ORM-мапперы, а сверху еще и в GraphQL (тоже 2015 год) и просят еще больше и больше денег за свои обертки над обертками.
И что самое печальное: для добавления каждой новой сущности (Entity) в системе — будь то «дни недели» или «отпуска сотрудников» — требуются недели и месяцы. Новые таблицы в базе, новые CRUD на бэкенде, новые модели и списки на фронте. Печальная печаль.
Есть ли выход из порочного круга? Как завести «Иуду», которая предаст эту систему?
Решения есть и были. Это подходы, которые дают безопасный способ работать почти без сервера, когда роль бэкенда выполняет сама база данных. Это и Datomic (2012), и Firebase (приобретен Google в 2014), и Supabase (2020), и иже с ними. И это неплохо.
Или можно взять и сделать по-своему. Как сделали мы. Взять и описать модель предметной области в строгих терминах, скажем, OMG M2, держать модель под рукой, и на ее основе делать все остальное. Вынести всю логику и безопасность на один-единственный, но универсальный сервер. И вуаля: один раз написав такой сервер, можно делать любые приложения — и веб, и десктоп, и мобильные. И не надо делиться на фронтендеров и бэкендеров.
Выжгем всю ересь раскаленной кочергой!
Иуды с ними, но не с нами. С нами — Бог и логика предметной области.