Как избежать повторения бизнес-логики между клиентом и сервером?

Question

По мере роста потребностей веб-приложений я обнаружил, что я пишу все больше веб-приложений, управляемых API. Я использую фреймворки, такие как AngularJS, для создания богатых веб-клиентов, которые общаются с этими API. В настоящее время я использую PHP (Lumen или Laravel) для серверной части/API.

Проблема заключается в том, что я часто повторяю бизнес-логику между клиентом и сервером.

Когда я говорю бизнес-логики я имею в виду правила, как следующий за форму заказа:

• Вы можете купить X, если вы покупаете Y.
• Вы не можете купить Y, если у вас есть Z.
• Если вы купите 10 из них, вы получите 10% скидки.
• Высота x Ширина x Глубина x Стоимость = Окончательная стоимость.
• Высота должна быть в пределах от 10 до 20, если ваша ширина больше 5.
• Etc и т.д.

Чтобы сделать это приложение как реагировать и быстро, логика для вычислений (наряду с другими бизнес-логики) выполняется на стороне клиента. Поскольку мы не должны доверять клиенту, я затем повторно проверяю эти номера на стороне сервера. Эта логика может стать довольно сложной и написание этой сложной логики в обоих местах кажется опасным.

У меня есть три решения в виде:

1. сделать все, что требуется бизнес-логика сделать AJAX вызов к API. Вся бизнес-логика будет жить в одном месте и может быть проверена один раз. Это может быть медленным, так как клиенту придется ждать каждого изменения, которое они вносят в форму заказа, для получения обновленных значений и результатов. Благодаря этому очень быстрый API. Основной недостаток заключается в том, что это может не сработать, когда пользователи плохо подключены (мобильные устройства).

2. Напишите бизнес-логику на стороне клиента И на стороне сервера. Клиент получает мгновенную обратную связь, поскольку они вносят изменения в форму, и мы проверяем все данные после их отправки на сервер. Недостатком здесь является то, что мы должны дублировать всю бизнес-логику и тестировать обе стороны. Это, безусловно, больше работы и сделает будущую работу хрупкой.

3. Доверьтесь клиенту!?! Напишите всю бизнес-логику на стороне клиента и предположите, что они не вмешиваются в данные. В моем текущем сценарии я работаю над создателем цитат, который всегда будет проверяться человеком, поэтому, возможно, это действительно нормально.

Честно говоря, я не доволен ни одним из решений, поэтому я обращаюсь к сообществу за советом. Я хотел бы услышать ваши мнения или подходы к этой проблеме!

Answer 1

Вы можете сделать еще одну вещь.

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

Затем установите сервер nodejs рядом с сервером PHP, чтобы обслуживать эту логику для клиентов. Так что на стороне клиента он может использоваться без вызова AJAX.

Затем с серверной стороны (PHP), когда вам нужно проверить и запустить всю эту бизнес-логику, вызовите cURL nodejs для проверки этих данных. Это означает, что это HTTP-вызов с сервера PHP на сервер nodejs. У сервера Nodejs будет другой код, который будет принимать эти данные и проверять с помощью того же кода и возвращать результат.

По этому пути вы можете сделать

1. Ускорение разработки (Одно место для блока проверить свою логику)
2. Faster выполнение кода клиента (Нет необходимости Аякса так же проверки файлов JavaScript в настоящее время служит by nodejs на вашу клиентскую сторону)
3. Вся бизнес-логика перейдет на сервер nodejs. (При изменении бизнес-логики вам нужно коснуться только этой части, так что в ближайшем будущем, если вам нужно создать некоторые другие интерфейсы, вы также сможете использовать этот сервер для проверки ваших данных. Он будет работать так же, как ваш сервер бизнес-правил)

Только то, что вам нужно сделать, это setup nodejs рядом с сервером PHP. Но вам не нужно менять весь свой код на сервер nodejs.

Answer 2

Я чувствую, что вариант 1 является лучшим в будущем. Первая разработка API позволяет проверять и работать всю бизнес-логику и разрешать доступ к интерфейсам. Никогда НИКОГДА не доверяйте пользователю!

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

Answer 3

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

Client-side vs. Server-side

Answer 4

Я была такая же проблема, когда я решил создать приложение, использующее Laravel для задней части, и угловые 2 для переднего конца. И мне кажется, что нет решения избежать дублирования бизнес-логики до сих пор, потому что:

В настоящий момент PHP и JavaScript не могут быть преобразованы из одного в другой. Было бы неплохо, если бы мы могли использовать один и тот же язык для написания бизнес-логики, а затем встраивать их в оба конца и на передний план. С этого момента это приводит меня к другому моменту:

Для достижения цели мы должны написать бизнес-логику только на одном языке, и до сих пор JavaScript является лучшим решением. Как вы знаете, скрипт TypeScript/EMCA поможет нам написать код в способе ООП. Meteor инфраструктура Инфраструктура NodeJS помогает нам писать код в JavaScript для работы в обеих сторонах Back-end и front-end.

С моей точки зрения, мы можем использовать TypeScript/EMCA для написания пакетов для бизнес-логики, например, класс для проверки, написанный на JavaScript, может быть реализован с обеих сторон, поэтому вы просто пишите только один раз, но это будет вызываться дважды из интерфейсного и back-end.

Это мое мнение. Надеюсь увидеть некоторые другие решения для этой очень интересной темы.

Answer 5

Я тоже был в этом положении, когда работал над некоторыми из моих собственных проектов. Всегда заманчиво использовать силу клиентского устройства для тяжелого подъема, а затем просто проверять результаты на стороне сервера. Это приведет к тому, что бизнес-логика появится дважды, как для интерфейсных, так и для внешних.

Я думаю, что вариант 1 - лучший вариант, он имеет наибольший смысл и кажется наиболее логичным. Если вы хотите в будущем расширить свое веб-приложение на собственные мобильные приложения, вы сможете повторно использовать всю бизнес-логику, вызвав эти API. Для меня это массовая победа.

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

Большая проблема, с которой я обычно сталкиваюсь, заключается в том, что, поскольку ваше веб-приложение будет разбито на разделы, каждый раздел вызывает соответствующие API. Состояние приложения гораздо сложнее понять, так как пользователь может прыгать между этими состояниями. Вам нужно будет очень внимательно подумать о поездке пользователя и убедиться, что этот процесс не глючит.

Вот некоторые из наиболее распространенных вопросов, которые я имел дело с:

• ли ошибка отображения фронтального если API возвращает один?
• Если пользователь совершил ошибку и отправил форму, он/она должен увидеть сообщение об ошибке. Но как только пользователь исправил ошибку и отправил ее снова, сообщение об ошибке должно скрываться, и сообщение об успехе должно теперь отображаться.
• Что делать, если API является ошибкой или подключение к Интернету нестабильно, поэтому ничего не возвращается. Будет ли интерфейс висит?
• Что делать, если есть несколько сообщений об ошибках, может ли/внешний интерфейс отображать их все?

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

Answer 6

Прежде всего: никогда не доверяйте клиенту.

Это, как говорится, я занимаюсь этим все время, и, к сожалению, я не нашел легкого решения. Вам нужно сделать проверку с обеих сторон, НО, вам не нужно делать всю проверку на них обоих.

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

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

Я думаю, вы поняли. Это то, что я делаю, и это работает очень хорошо для меня, экономит много перекодировки.

Надеюсь, вы сочтете это полезным.

Answer 7

Одним из возможных решений является объявление правил проверки в декларативном абстрактном языке, таком как XML или JSON Schema.

Затем, на стороне клиента, скажем, AngularJS - вы можете преобразовать эти правила в средство рендеринга полки. Итак, теперь на стороне клиента вы получаете формы, которые подтверждают объявленные правила.

Затем на вашем API-интерфейсе на стороне сервера вам необходимо создать механизм повторного использования, который будет проверяться на основе определенных правил.

Что вы в итоге получаете - это одно место, ваша схема JSON или где вы декларативно определяете свои правила, что ваши формы и правила проверки определены.

Answer 8

Сегодня решение явно один из @ParthaSarathiGhosh, но в ближайшем будущем, безусловно, дает нам еще одно решение ...

WebAssembly является язык ассемблера низкого уровня, которые могут быть развернуты с приложением и запустить в браузер. Это позволит вам запросить некоторую логику из JavaScript, вызвав скомпилированный код в сборке. Это рекомендуется для тяжелых сценариев, работающих на стороне клиента, но в то же время позволит вам повторно использовать ваш внутренний код спереди. Таким образом, вы сможете написать свою логику для своего бэкэнд и повторно использовать ее спереди.

Сегодня эта технология уже поддерживается в большинстве современных браузеров, но доступна только для c/C++. Таким образом, вы уже можете использовать его, если у вас есть эти навыки.

Наверняка планируется расширить его и на другой язык (так как уже есть некоторые исследования для c# - ex: blazor - и другие языки). Но уровень зрелости кажется недостаточно стабильным для производства (даже команда разработчиков Blazor еще не рекомендует ее для производства).

Это только мое мнение, но => Логика в NodeJS - это решение для повторного использования кода javascript, но я все еще чувствую потребность в строго типизированном языке, когда речь идет о большом поддерживаемом логическом коде. (Да, я знаю TypeScript, и это действительно хорошо, но я что-то пропустил). WebAssembly все еще немного молод, но наверняка принесет большое улучшение в отношении принципа DRY.