Любой клиент-серверный проект подразумевает четкое разделение кодовой базы на 2 части (иногда больше) — клиентскую и серверную. Зачастую, каждая такая часть оформляется в виде отдельного независимого проекта, поддерживаемого своей командой девелоперов.В этой статье я предлагаю критически посмотреть на стандартное жесткое разделение кода на бэкенд и фронтенд. И рассмотрим альтернативу, где в коде нет четкой грани между клиентом и сервером.
Минусы стандартного подхода
Основной минус стандартного разделения проекта на 2 части — это размывание бизнес-логики между клиентом и сервером. Мы редактируем данные в форме в браузере, верифицируем их в клиентском коде и отправляем на деревню дедушке (на сервер). Сервер — это уже другой проект. Там тоже нужно проверить корректность поступивших данных (т.е. продублировать функциональность клиента), сделать какие-то дополнительные манипуляции (сохранить в базе, отправить e-mail и т.д.).
Таким образом, что бы проследить весь путь информации от формы в браузере до базы данных на сервере нам придется копаться в двух разноплановых системах. Если в команде разделены роли и за бэкенд и фронтенд отвечают разные специалисты, возникают дополнительные организационные проблемы связанные с их синхронизацией.
Давайте помечтаем
Предположим, что мы можем описать весь путь данных от формы на клиенте до базы на сервере в одной модели. В коде это может выглядеть примерно так (код не рабочий):
class MyDataModel { // метод используется на клиентской и на серверной стороне verifyData(data) { // проверка данных .... return true; } // вызывается на клиенте при сабмите формы client saveData(data) { if(this.verifyData(data)) this.writeDataToDb(data) else consol.log('error') } // серверный метод. Сохраняем данные в БД server writeDataToDb(data) { if(this.verifyData(data)) this.db.insert(data) else consol.log('error') } }
Таким образом, вся бизнес-логика модели у нас перед глазами. Поддерживать такой код проще. Вот плюсы, которые может принести совмещение клиент-серверных методов в одной модели:
- Бизнес-логика сконцентрирована в одном месте, нет необходимости разделять ее между клиентом и сервером.
- Можно легко переносить функциональность от сервера к клиенту ��ли от клиента к серверу в процессе развития проекта.
- Нет необходимости дублировать одинаковые методы для бэкенда и фронтенда.
- Единый набор тестов для всей бизнес-логики проекта.
- Замена горизонтальных линий разграничения ответственности в проекте на вертикальные.
Последний пункт раскрою подробнее. Представим обычное клиент-серверное приложение в виде такой схемы:
Вася отвечает за фронтенд, Федя — за бэкенд. Линия разграничения ответственности проходит горизонтально. Эта схема имеет недостатки любой вертикальной структуры — она сложно масштабируется и имеет низкую отказоустойчивость. Если проект расширяется вам придется делать довольно сложный выбор: кого усилить Васю или Федю? Или если заболел или уволился Федя, Вася не сможет его заменить.
Предлагаемый здесь подход позволяет развернуть линию разграничения ответственности на 90 градусов и превратить вертикальную архитектуру в горизонтальную.
Такая архитектура гораздо проще масштабируется и более отказоустойчивая т.к. Вася и Федя становятся взаимозаменяемыми.
В теории выглядит неплохо, попробуем реализовать все это на практике, не растеряв по дороге все то, что дает нам раздельное существование клиента и сервера.
Постановка задачи
Нам совершенно не обязательно в продуктиве иметь интегрированный клиент-сервер. Напротив, такое решение было бы крайне вредным со всех точек зрения. Задача состоит в том, что бы в процессе разработки у нас была единая кодовая база для моделей данных для бэкенда и фронтенда, но на выходе получались бы независимые клиент и сервер. В этом случае мы получим все преимущества стандартного подхода и приобретем удобства в разработке и поддержке проекта, перечисленные выше.
Решение
Уже довольно давно экспериментирую с интеграцией клиента и сервера в одном файле. Основной проблемой до недавнего времени было то, что в стандартном JS подключение сторонних модулей на клиенте и сервере происходило слишком по-разному: require(...) в node.js, на клиенте всякая AJAX-магия. Все поменялось с появлением ES-модулей. В современных браузерах «import» поддерживается уже давно. Node.js немного отстает в этом плане и ES-модули поддерживаются только с включенным флагом "--experimental-modules". Есть надежда, что в обозримом будущем модули заработают «из коробки» и в node.js. Кроме того, вряд ли что-то сильно поменяется, т.к. в браузерах эта функциональность уже давно работает по-умолчанию. Думаю, уже сейчас можно использовать ES-модули не только на клиентской но и на серверной стороне (если у вас есть контр-аргументы на этот счет, напишите в комментариях).
Схема решения выглядит так:
Проект содержит три основных каталога:
protected — бэкенд;
public — фронтенд;
shared — общие клиент-серверные модели.
Отдельный процесс-наблюдатель (observer) следит за файлами в каталоге shared и при любых изменениях создает версии измененного файла отдельно для клиента и отдельно для сервера (в каталогах protected/shared и public/shared).
Реализация
Рассмотрим пример простенького real-time мессенджера. Нам понадобится свежий node.js (у меня версия 11.0.0) и Redis (их установка тут не рассматривается).
Склонируем пример:
git clone https://github.com/Kolbaskin/both-example cd ./both-example npm i
Установим и запустим процесс-наблюдатель (observer на схеме):
npm i both-js -g both ./index.mjs
Если все в порядке, наблюдатель запустит веб-сервер и начнет мониторить изменения файлов в каталогах shared и protected. При изменениях в shared создаются соответствующие версии моделей данных для клиента и для сервера. При изменениях в protected наблюдатель автоматически перезапустит веб-сервер.
Посмотреть работоспособность мессенджера можно в браузере перейдя по ссылке
http://localhost:3000/index.html?token=123&user=Vasya (token и user произвольные). Для эмуляции нескольких пользователей откройте эту же страницу в другом браузере указав другие token и user.
Теперь немного кода.
Веб-сервер
protected/server.mjs
import express from 'express'; import bodyParser from 'body-parser'; // веб-сокеты используется в качестве транспорта // для клиент-серверного взаимодействия import wsServer from './lib/wsServer.mjs'; const app = express(); // запускаем сервер веб-сокетов wsServer(app); // добавим mime для mjs express.static.mime.define({'application/javascript': ['js','mjs']}); app.use( bodyParser.json() ); app.use(bodyParser.urlencoded({ extended: true })); // статический контент отдаем из каталога public app.use(express.static('public')); const server = app.listen(3000, () => { console.log('server is running at %s', server.address().port); });
Это обычный express-сервер, здесь нет ничего интересного. Расширение «mjs» нужно для ES-модулей в node.js. Для единообразия, будем использовать это расширение и для клиента.
Клиент
public/index.html
<!DOCTYPE html> <html lang="en"> <head> ... <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script> <script src="/main.mjs" type="module"></script> </head> <body> ... <ul id="users"> <li v-for="user in users"> {{ user.name }} ({{user.id}}) </li> </ul> <div id="messages"> <div> <input type="text" v-model="msg" /> <button v-on:click="sendMessage()">Отправить</button> </div> <ul> <li v-for="message in messages">[{{ message.date }}] <strong>{{ message.text }}</strong></li> </ul> </div> </body> </html>
Для примера я использую на клиенте Vue, но сути это не меняет. Вместо Vue может быть что угодно, где можно выделить модель данных в отдельный класс (knockout, angular).
public/main.mjs
// импортируем класс для работы с веб-сокетом import ws from "/lib/Ws.mjs"; // модель данных для работы с сообщениями import Messages from "./shared/messages/model/dataModel.mjs"; // модель данных пользователей import Users from "./shared/users/model/dataModel.mjs"; // подключаем веб-сокет (на проект нам достаточно одного коннекта) window.WS = new ws({ token: new URLSearchParams(document.location.search).get("token"), user: new URLSearchParams(document.location.search).get("user") }); // связываем модель данных сообщений с представлением new Messages({ el: '#messages' }) // связываем модель данных пользователей с представлением new Users({ el: '#users' })
main.mjs — это скрипт, связывающий модели данных с соответствующими представлениями. Для упрощения кода примера представления для списка активных пользователей и ленты сообщений встроены прямо в index.html
Модель данных
shared/messages/model/dataModel.mjs
// импортируем базовый класс // базовые классы для клиентской и серверной частей содержат разные методы, // но называются одинаково import Base from '@root/lib/Base.mjs'; export default class dataModel extends Base { //!#client constructor(attr) { attr.data = { msg: '', messages: [] } super(attr); // подписываемся на новые сообщения this.on('newmessage', (data) => { this.messages.push(data) }) } //!#client async sendMessage(e) { //отправляем сообщение на сервер await this.$sendMessage(this.msg); this.msg = ''; } //!#server async $sendMessage(text) { // генерируем событие newmessage для всех подключенных пользователей this.fireEvent('newmessage', 'all', { date: new Date(), text }) return true; } }
Эти несколько методов реализуют всю функциональность отправки и приема сообщений в режиме реального времени. Директивы !#client и !#server указывают процессу-наблюдателю какой метод для какой части (клиент или сервер) предназначен. Если перед определением метода нет этих директив, такой метод доступен и на клиенте и на сервере. Слэши комментария перед директивой не обязательны и существуют только для того, что бы стандартная IDE не ругалось на ошибки в синтаксисе.
В первой строке в пути используется подстановка &root. При генерации клиентской и серверной версий &root будет заменен на относительный путь к каталогам public и protected соответственно.
Еще важный момент: из клиентского метода можно вызвать только тот серверный метод, название которого начинается с "$":
... //отправляем сообщение на сервер async sendMessage(e) { await this.$sendMessage(this.msg); <- вызываем серверный метод this.msg = ''; } ...
Это сделано по соображениям безопасности: извне можно обратиться только к специально-предназначенным для этого методам.
Давайте посмотрим на версии моделей данных которые наблюдатель (observer) сгенерировал для клиента и сервера.
Клиент (public/shared/messages/model/dataModel.mjs)
import Base from '/lib/Base.mjs'; export default class dataModel extends Base { __getFilePath__() {return "messages/model/dataModel.mjs"} // constructor(attr) { attr.data = { msg: '', messages: [] } super(attr); // подписываемся на новые сообщения this.on('newmessage', (data) => { this.messages.push(data) }) } // async sendMessage(e) { //отправляем сообщение на сервер await this.$sendMessage(this.msg); this.msg = ''; } // ... async $sendMessage() {return await this.__runSharedFunction("$sendMessage",arguments)} }
На клиентской стороне модель является потомком класса Vue (через Base.mjs). Таким образом, вы можете работать с ней как с обычной моделью данных Vue. Наблюдатель добавил в клиентскую версию модели метод __getFilePath__ который возвращает путь к файлу класса и заменил код серверного метода $sendMessage на конструкцию, которая, по-сути, через механизм rpc вызовет нужный нам метод на сервере (__runSharedFunction определен в родительском классе).
Сервер (protected/shared/messages/model/dataModel.mjs)
import Base from '../../lib/Base.mjs'; export default class dataModel extends Base { __getFilePath__() {return "messages/model/dataModel.mjs"} ... куча пустых строк вместо клиентских методов ... // async $sendMessage(text) { // генерируем событие newmessage для всех подключенных пользователей this.fireEvent('newmessage', 'all', { date: new Date(), text }) return true; } }
В серверной версии так же добавлен метод __getFilePath__ и удалены клиентские методы отмеченные директивой !#client
В обеих сгенерированных версиях модели все удаленные строки заменяются на пустые. Это сделано для того, что бы по сообщению об ошибках отладчика можно было легко найти проблемную строку в исходном коде модели.
Взаимодействие клиента и сервера
Когда нам нужно вызвать на клиенте какой-то серверный метод, просто делаем это.
Если вызов в рамках одной модели, тут все просто:
... !#client async sendMessage(e) { await this.$sendMessage(this.msg); this.msg = ''; } !#server async $sendMessage(msg) { // что-то делаем на сервере } ...
Можно «дернуть» другую модель:
import dataModel from "/shared/messages/model/dataModel.mjs"; var msg = new dataModel(); msg.$sendMessage('blah-blah-blah');
В обратную сторону, т.е. позвать на сервере какой-нибудь клиентский метод, не работает. Технически это реализуемо, но с практической точки зрения лишено смысла, т.к. сервер один, а клиентов много. Если нам нужно на сервере инициировать какие-то действия на клиенте используем событийный механизм:
// импортируем базовый класс ... //!#client constructor(attr) { .... // на клиентской стороне подписываемся на событие "newmessage" this.on('newmessage', (data) => { this.messages.push(data) }) } //!#server async $sendMessage(text) { // генерируем на сервере событие newmessage для всех подключенных пользователей this.fireEvent('newmessage', 'all', { date: new Date(), text }) return true; } ...
Метод fireEvent принимает 3 параметра: название события, кому оно адресовано и данные. Адресата можно задать несколькими способами: ключевое слово «all» — событие будет разослано всем пользователям или в массиве перечислить токены сессии тех клиентов, которым адресуется событие.
Событие не привязано к конкретному инстансу класса модели данных и сработают обработчики во всех экземплярах класса, в котором был вызван fireEvent.
Горизонтальное масштабирование бэкенда
Монолитность клиент-серверных моделей в предлагаемой реализации, на первый взгляд, должна накладывать существенные ограничения на возможности горизонтального масштабирования серверной части. Но это не так: технически сервер не зависит от клиента. Вы можете скопировать каталог «public» куда угодно и отдавать его содержимое через любой другой веб-сервер (nginx, apache и т.д.).
Серверную часть можно легко расширять запуская новые экземпляры бэкенда. Для взаимодействия отдельных экземпляров используется Redis и система очередей Kue.
API и разные клиенты к одному бэкенду
В реальных проектах одним серверным API могут пользоваться разноплановые клиенты — веб-сайты, мобильные приложения, сторонние сервисы. В предложенном решении все это доступно без каких либо дополнительных танцев. Под капотом вызова серверных методов находится старый добрый rpc. Сам веб-сервер — это классическое express-приложение. Достаточно добавить туда обертку для роутов с вызовом нужных методов тех-же моделей данных.
Post scriptum
Предлагаемый в статье подход не претендует на какие-то революционные изменения в клиент-серверных приложениях. Он, только, добавляет немного комфорта в процесс разработки, позволяя сосредоточится на бизнес-логике собранной в одном месте.
Этот проект экспериментальный, пишите в комментариях, стоит ли, на ваш взгляд, продолжить этот эксперимент.
