Любой клиент-серверный проект подразумевает четкое разделение кодовой базы на 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')
    }
    
}

Таким образом, вся бизнес-логика модели у нас перед глазами. Поддерживать такой код проще. Вот плюсы, которые может принести совмещение клиент-серверных методов в одной модели:

1. Бизнес-логика сконцентрирована в одном месте, нет необходимости разделять ее между клиентом и сервером.
2. Можно легко переносить функциональность от сервера к клиенту или от клиента к серверу в процессе развития проекта.
3. Нет необходимости дублировать одинаковые методы для бэкенда и фронтенда.
4. Единый набор тестов для всей бизнес-логики проекта.
5. Замена горизонтальных линий разграничения ответственности в проекте на вертикальные.

Последний пункт раскрою подробнее. Представим обычное клиент-серверное приложение в виде такой схемы:



Вася отвечает за фронтенд, Федя — за бэкенд. Линия разграничения ответственности проходит горизонтально. Эта схема имеет недостатки любой вертикальной структуры — она сложно масштабируется и имеет низкую отказоустойчивость. Если проект расширяется вам придется делать довольно сложный выбор: кого усилить Васю или Федю? Или если заболел или уволился Федя, Вася не сможет его заменить.

Предлагаемый здесь подход позволяет развернуть линию разграничения ответственности на 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

Предлагаемый в статье подход не претендует на какие-то революционные изменения в клиент-серверных приложениях. Он, только, добавляет немного комфорта в процесс разработки, позволяя сосредоточится на бизнес-логике собранной в одном месте.

Этот проект экспериментальный, пишите в комментариях, стоит ли, на ваш взгляд, продолжить этот эксперимент.