Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
Это больно читать.
броузере
денных для бакэнда
Больше, больше таких гениальных статей на Хабре!!!
Во-первых, всё это имеет достаточно условный смысл при условии, что клиент и сервер пишется на одном языке.
Во-вторых, та же валидация на сервере может быть более сложной, нежели на клиенте. Условно, на клиенте проверяется заполнение какого-либо поля, а на сервере помимо заполнения ещё и само значение проверяется на корректность.
Если так не хочется пилить отдельную валидацию на клиенте, то самым правильным вариантом будет валидация на сервере.
Во-вторых, та же валидация на сервере может быть более сложной, нежели на клиенте. Условно, на клиенте проверяется заполнение какого-либо поля, а на сервере помимо заполнения ещё и само значение проверяется на корректность.
Если так не хочется пилить отдельную валидацию на клиенте, то самым правильным вариантом будет валидация на сервере.
Во-первых, всё это имеет достаточно условный смысл при условии, что клиент и сервер пишется на одном языке.
да, речь идет только о js, я это в тегах отметил.
Во-вторых, та же валидация на сервере может быть более сложной, нежели на клиенте.
Серверная валидация, как правило, или такая-же как клиентская или расширяет ее. Если это не так, то возможны казусы. Недавно здесь была статья, как человек хакал госуслуги из-за разной валидации в бакенде и фронте. Так что без дубляжа не обойтись.
Но это одна из возможностей. Интересной фишкой, на мой взгляд, может быть упрощение перемещения функцональности от клиента к серверу и обратно. Например, у вас работает какой-то сложный алгоритм обработки данных на серверной стороне. В какой-то момент вы решили перенести этот алгоритм или его часть на клиентскую сторону (что бы не переплачивать за AWS, например). В моем случае сделать это легче. Ну и тестировать всю бизнес-логику, когда она сконцентрирована в одном месте тоже проще.
В 1С уже все придумали
Идея очень похожа на Meteor.js.
Про него, к сожалению, слышал только негативные отзывы, что он плохо масштабируется и не гибкий совсем. Интересно, чем эта затея кончится у вас.
Ещё можешь посмотреть в сторону haxe. Отлично собирается в js, и богатый функционал для написания макросов. Я год назад делал похожую библиотеку, только вместо server function writeDataToDb использовал function srv_writeDataToDb. При компиляции в эту функцию добавлялась проверка на то, что этот фрагмент выполняется на сервере, иначе нужно упаковывать все аргументы функции в пакет и отправить на сервер.
Хм… очень спорно…
Пытался придумать «плюсы», но в голову лезут одни «минусы».
«Зависимости» на фронтэнде и бэкэнде имеют свою специфику.
Придется пилить костыли для DI.
Какой-то части серверного кода противопоказано находиться на клиенте.
Значит его как-то придется всеравно «делить» на серверный и клиентский.
и еще куча минусов если копнуть по глубже…
Если уж попытаться объединить бэкэнд и фронтэнд, то наверное таким способом:
1. Специализированная структура проекта, позволяющая без больших заморочек «разделить» проект на клиент и сервер.
2.Специальная система сборки проекта, которая его и «поделит» на клиент и сервер.
Но все равно сомневаюсь, что плюсы такого подхода перевесят минусы.
Пытался придумать «плюсы», но в голову лезут одни «минусы».
«Зависимости» на фронтэнде и бэкэнде имеют свою специфику.
Придется пилить костыли для DI.
Какой-то части серверного кода противопоказано находиться на клиенте.
Значит его как-то придется всеравно «делить» на серверный и клиентский.
и еще куча минусов если копнуть по глубже…
Если уж попытаться объединить бэкэнд и фронтэнд, то наверное таким способом:
1. Специализированная структура проекта, позволяющая без больших заморочек «разделить» проект на клиент и сервер.
2.Специальная система сборки проекта, которая его и «поделит» на клиент и сервер.
Но все равно сомневаюсь, что плюсы такого подхода перевесят минусы.
Я исходил из того, что у клиента и сервера общие только модели данных. Остальное у каждого свое. Структуры файлов внутри каталогов protected и public так же могут быть специфическими.
Если Вы имеете ввиду синтаксис подключения зависимостей, то ES-модули для того и придуманы, что бы унифицировать клиент и сервер в этом вопросе.
Если речь идет о зависимостях которые используются только на серверной стороне или только на клиентской, то с ними поступаем ровно так же как с клиентскими и серверными методами, т.е. отмечаем соответствующими директивами:
Вот от какой-то специфичности как раз и хотелось уйти. Если в двух словах, то вся идея заключается в том, что бы выделить в обеих частях классы, отвечающие за бизнес-логику и совместить их в каком то одном месте.
Насчет минусов. Я не думаю, что подобный проект на проде будет чем-то отличаться от обычного, изначально разделенного на бакенд и фронтенд.
Насчет плюсов. Конкретно этот подход я еще не пробовал в реальных проектах. Но нечто подобное на базе ExtJs использую уже несколько лет (у меня в профиле есть пара статей на эту тему). Чисто по опыту, могу сказать, что когда бизнес-логика модуля под рукой и не нужно прыгать между клиентом и сервером, как минимум, это удобно.
«Зависимости» на фронтэнде и бэкэнде имеют свою специфику.
Если Вы имеете ввиду синтаксис подключения зависимостей, то ES-модули для того и придуманы, что бы унифицировать клиент и сервер в этом вопросе.
Если речь идет о зависимостях которые используются только на серверной стороне или только на клиентской, то с ними поступаем ровно так же как с клиентскими и серверными методами, т.е. отмечаем соответствующими директивами:
!#server
import db from "pg";
....
Если уж попытаться объединить бэкэнд и фронтэнд, то наверное таким способом:
1. Специализированная структура проекта, позволяющая без больших заморочек «разделить» проект на клиент и сервер.
2.Специальная система сборки проекта, которая его и «поделит» на клиент и сервер.
Вот от какой-то специфичности как раз и хотелось уйти. Если в двух словах, то вся идея заключается в том, что бы выделить в обеих частях классы, отвечающие за бизнес-логику и совместить их в каком то одном месте.
Но все равно сомневаюсь, что плюсы такого подхода перевесят минусы.
Насчет минусов. Я не думаю, что подобный проект на проде будет чем-то отличаться от обычного, изначально разделенного на бакенд и фронтенд.
Насчет плюсов. Конкретно этот подход я еще не пробовал в реальных проектах. Но нечто подобное на базе ExtJs использую уже несколько лет (у меня в профиле есть пара статей на эту тему). Чисто по опыту, могу сказать, что когда бизнес-логика модуля под рукой и не нужно прыгать между клиентом и сервером, как минимум, это удобно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бесшовный клиент-сервер