Pull to refresh

Comments 15

Это больно читать.
броузере

денных для бакэнда

Во-первых, всё это имеет достаточно условный смысл при условии, что клиент и сервер пишется на одном языке.

Во-вторых, та же валидация на сервере может быть более сложной, нежели на клиенте. Условно, на клиенте проверяется заполнение какого-либо поля, а на сервере помимо заполнения ещё и само значение проверяется на корректность.

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

да, речь идет только о js, я это в тегах отметил.

Во-вторых, та же валидация на сервере может быть более сложной, нежели на клиенте.

Серверная валидация, как правило, или такая-же как клиентская или расширяет ее. Если это не так, то возможны казусы. Недавно здесь была статья, как человек хакал госуслуги из-за разной валидации в бакенде и фронте. Так что без дубляжа не обойтись.

Но это одна из возможностей. Интересной фишкой, на мой взгляд, может быть упрощение перемещения функцональности от клиента к серверу и обратно. Например, у вас работает какой-то сложный алгоритм обработки данных на серверной стороне. В какой-то момент вы решили перенести этот алгоритм или его часть на клиентскую сторону (что бы не переплачивать за AWS, например). В моем случае сделать это легче. Ну и тестировать всю бизнес-логику, когда она сконцентрирована в одном месте тоже проще.
Я ждал, что будет такой комментарий))

Идея очень похожа на Meteor.js.


Про него, к сожалению, слышал только негативные отзывы, что он плохо масштабируется и не гибкий совсем. Интересно, чем эта затея кончится у вас.

Да, идея использовать один код на клиенте и сервере не нова. Очень хотелось сделать так, что бы не было завязки на какой-то конкретный фрэймворк. В моем случае на сервере стандартный express (не сложно и что-то другое подключить), на клиенте, так же, может быть что угодно.
Ещё можешь посмотреть в сторону haxe. Отлично собирается в js, и богатый функционал для написания макросов. Я год назад делал похожую библиотеку, только вместо server function writeDataToDb использовал function srv_writeDataToDb. При компиляции в эту функцию добавлялась проверка на то, что этот фрагмент выполняется на сервере, иначе нужно упаковывать все аргументы функции в пакет и отправить на сервер.
haxe — отдельный язык. Тут уже упоминали 1С. Вопрос в том, на сколько реально найти спецов на haxe? Особенно, в свете загибания флэша. Все-таки, js-программеров несравненно больше.
UFO just landed and posted this here
Не нужно извинений, душевное состояние чувствительных читателей важнее) Поправил
Хм… очень спорно…

Пытался придумать «плюсы», но в голову лезут одни «минусы».

«Зависимости» на фронтэнде и бэкэнде имеют свою специфику.
Придется пилить костыли для DI.

Какой-то части серверного кода противопоказано находиться на клиенте.
Значит его как-то придется всеравно «делить» на серверный и клиентский.

и еще куча минусов если копнуть по глубже…

Если уж попытаться объединить бэкэнд и фронтэнд, то наверное таким способом:
1. Специализированная структура проекта, позволяющая без больших заморочек «разделить» проект на клиент и сервер.
2.Специальная система сборки проекта, которая его и «поделит» на клиент и сервер.

Но все равно сомневаюсь, что плюсы такого подхода перевесят минусы.
Я исходил из того, что у клиента и сервера общие только модели данных. Остальное у каждого свое. Структуры файлов внутри каталогов protected и public так же могут быть специфическими.

«Зависимости» на фронтэнде и бэкэнде имеют свою специфику.

Если Вы имеете ввиду синтаксис подключения зависимостей, то ES-модули для того и придуманы, что бы унифицировать клиент и сервер в этом вопросе.
Если речь идет о зависимостях которые используются только на серверной стороне или только на клиентской, то с ними поступаем ровно так же как с клиентскими и серверными методами, т.е. отмечаем соответствующими директивами:
!#server
import db from "pg";
....

Если уж попытаться объединить бэкэнд и фронтэнд, то наверное таким способом:
1. Специализированная структура проекта, позволяющая без больших заморочек «разделить» проект на клиент и сервер.
2.Специальная система сборки проекта, которая его и «поделит» на клиент и сервер.

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

Но все равно сомневаюсь, что плюсы такого подхода перевесят минусы.

Насчет минусов. Я не думаю, что подобный проект на проде будет чем-то отличаться от обычного, изначально разделенного на бакенд и фронтенд.
Насчет плюсов. Конкретно этот подход я еще не пробовал в реальных проектах. Но нечто подобное на базе ExtJs использую уже несколько лет (у меня в профиле есть пара статей на эту тему). Чисто по опыту, могу сказать, что когда бизнес-логика модуля под рукой и не нужно прыгать между клиентом и сервером, как минимум, это удобно.
Sign up to leave a comment.

Articles