Стоит ли переносить логику работающего онлайн-калькулятора с JS на PHP ради защиты формул от копирования?

Question

[Михаил]

Привет всем!

Есть работающий проект — алкогольный калькулятор для водителей. Сейчас вся математика (модифицированная формула Видмарка с кучей наших кастомных коэффициентов и эмпирических поправок) крутится на клиенте на чистом JS. Пользователь меняет значения в форме, график мгновенно перестраивается — интерфейс летает, UX идеальный.

Но встал вопрос защиты интеллектуальной собственности. Формулы и веса выверялись долго, а сейчас конкуренты в нише могут просто открыть DevTools и скопировать всю логику за две минуты.

Задумался о переносе расчетной части на бэкенд (PHP), чтобы отдавать на фронтенд только готовый массив данных для графика. Но есть сильные сомнения, стоит ли ломать то, что отлично работает:

1. Потеря интерактивности: Сейчас расчет происходит за доли миллисекунды. Если перенести на PHP, то при изменении параметров придется слать AJAX-запросы. Будет ли задержка критичной для восприятия (интерфейс перестанет быть «живым»)?
2. Нагрузка на сервер: Когда пользователи начнут активно дергать ползунки, сервер получит лавину мелких запросов. Как это обычно оптимизируют? Дросселированием (debounce/throttle) на фронтенде или агрессивным кэшированием на бэкенде?
3. Целесообразность: Спасает ли вообще перенос на PHP от парсинга, или умный конкурент точно так же напишет скрипт, который задублирует запросы к нашему обработчику и вытянет те же данные?

Поделитесь опытом, стоит ли ради защиты алгоритмов переходить на серверные расчеты в интерактивных калькуляторах, или в вебе проще смириться, накатать обфускатор на JS и оставить все на клиенте?

Comments

[szQocks]

мне кажется нужно всё оставить без изменений, потому что этот алко-калькулятор на уроне детсада, проще написать с нуля, чем брать тот ковнокод который у вас

[Михаил]

Если для вас «уровень детсада» — это калькулятор с учётом абсорбции, TBW, Widmark correction, метаболизма и таблицами выветривания, то окей

Переписать «с нуля» всегда можно. Вопрос только в том, что 90% тех, кто такое пишет, в итоге делают формулу из трёх строк и называют это «архитектурой».

Код рабочий, читаемый и решает задачу. Да, он разросся и требует рефакторинга — это нормально для живого проекта. Но рассказывать про «говнокод» без конкретики может любой.

Если есть реальные замечания по:
— математике,
— производительности,
— архитектуре,
— безопасности,
— UX,

то давайте по пунктам....

[Михаил Р.]

Михаил,

1. Потеря интерактивности: Сейчас расчет происходит за доли миллисекунды. Если перенести на PHP, то при изменении параметров придется слать AJAX-запросы. Будет ли задержка критичной для восприятия (интерфейс перестанет быть «живым»)?

Разница между 1 или 300 миллисекундами незаметна для восприятия большинством пользователей, особенно если после этого меняется ui. Можно добавить индикатор загрузки, который на себя возьмет еще 200 мс, в итоге ваш запрос спокойно улетит и прилетит с сервера, а клиент все равно будет приятно удивлен такой скоростью. Проблемы начнутся, когда счет пойдет на секунды.

2. Нагрузка на сервер: Когда пользователи начнут активно дергать ползунки, сервер получит лавину мелких запросов. Как это обычно оптимизируют? Дросселированием (debounce/throttle) на фронтенде или агрессивным кэшированием на бэкенде?

Зависит от конфига сервера и нагрузки, и по этому вопросу написано множество материалов, которые легко гугляться.

3. Целесообразность: Спасает ли вообще перенос на PHP от парсинга, или умный конкурент точно так же напишет скрипт, который задублирует запросы к нашему обработчику и вытянет те же данные?

Cors -> referer -> csrf -> подпись запроса на сервер со своим алгоритмом. Но я рекомендую не банить конкурентов сразу, а выдавать теневой бан, например, по рандому отправлять неверные данные для него, тогда он рано или поздно забьет на ваш (для него кривой/непредсказуемый) алгоритм.

[Adamos]

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

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

А вот клиенты, которым вы такой переделкой сделаете неудобно, вполне могут существовать в реальности.

Так что перенос расчета на сервер может иметь смысл, если это поможет дальше развивать проект, но не по озвученной причине.

[Ankhena]

Пользователь меняет значения в форме, график мгновенно перестраивается

Какое мгновенно, если у вас там кнопка Рассчитать.
Графика вообще не нашла. Таблицу вижу, но она не интерактивная.

Начинаю думать, что это спам, а не вопрос.

[Михаил]

Графика вообще не нашла. Таблицу вижу, но она не интерактивная.

Извините, неправильно донес поставленную задачу.... суть в том что код будет переписываться, дорабатываться и оптимизироваться.

[Adamos]

Ankhena, даже если это попытка спама - в вопросе поднята реальная проблема, встающая перед реальными разработчиками. Такой спам на QnA, имхо - простителен ;) тем паче, что на Тостере спам все равно не работает.

[Ankhena]

Adamos, в принципе, да, логично, я не нажимала на кнопочку. Просто пачка несоответствий смутила.

тем паче, что на Тостере спам все равно не работает.

А вдруг мы та самая целевая аудитория :))))))

[Adamos]

Ankhena, та хай ему грець, что тут той аудитории.
За себя могу гарантировать, что нет - по обоим пунктам ;)

[Михаил]

Даже не знаю ка быть... оправдываться.... доказывать? Решать сообществу. В любом случае спасибо за ответы!

[Adamos]

Михаил, если вы искренни - то и не волноваться.
Ибо сказано: "Живи так, чтобы никогда не было стыдно, если то, что ты сказал или сделал, станет известно всему миру, — даже если то, что станет известно, будет неправдой" (с)

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

[alekssamos]

А можно и не переписывать, сделать через nodejs + websocket и получим такую же мгновенную отдачу и на js и на сервере, и на клиенте.

[Adamos]

alekssamos, задержки между фронтом и бэком можно не учитывать только в том случае, если они работают на одном и том же компьютере.

[alekssamos]

Adamos, Процетирую:

Разница между 1 или 300 миллисекундами незаметна для восприятия большинством пользователей,

И если сравнивать http запросы и websocket - второй будет чуточку быстрее.

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

[Adamos]

alekssamos, а разница между "есть интернет" и "интернет по [s]карточкам[/s] белым спискам" - таки заметна.

[Александр Васильев]

Дано - Мужчина: рост 140, вес 40, 80 лет. 1,5л водки.
На выходе-
Вызывайте скорую. За руль нельзя.
Это точно для водителей калькулятор («с учётом абсорбции, TBW, Widmark correction, метаболизма и таблицами выветривания»)?

[Михаил]

Александр Васильев,

А что именно вас смущает в результате?

Мужчина:

40 кг,
80 лет,
140 см,
1.5 литра водки.

Это экстремально опасная доза даже без всяких «кастомных коэффициентов». В таком сценарии калькулятор и должен показывать критическое состояние, а не «подождите 8 часов и можно ехать».

Калькулятор для водителей не означает, что он считает только «после двух бокалов пива». Он должен адекватно реагировать и на смертельно опасные значения.

Если где-то есть конкретная математическая ошибка — например:

неверный BAC,
неправильное время выведения,
ошибка в коэффициентах,
баг в формулах,

то это можно обсуждать предметно.

Но сам вывод «за руль нельзя + вызывайте скорую» для такого набора параметров выглядит вполне логично.

[Александр Васильев]

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

[Alexey Epsilon]

Во-первых, спасибо за калькулятор. Скопировал себе код, может пригодится где-нибудь.
Во-вторых, если сделать для калькулятора отдельный эндпоинт (скрипт), в котором не создаётся коннект к БД при каждом запросе, не читается и не парсится session и не делается вся та куча ненужной лабуды, которая обычно висит на входе в каждый PHP скрипт, то ваши вычисления будут производиться за те же самые миллисекунды.
Но если нужно прям единицы миллисекунд - перегоните код в Nodejs и коннектитесь к нему через вебсокеты. Отдача будет мгновенной.
Кстати в этом случае вам даже формулы переписывать не придётся - это ж тот же js.

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

Алгоритм, лежащий на сервере никто не стырит. Переиспользование перекрёстным запросом очень легко предотвратить.

Удачи.

[MoonMeTwice]

Не очень понятно, что вы собираетесь защищать интеллектуальной собственностью, если у вас весь сайт сугубо нейрослоп, где вы, уверен на 99.9%, максимум тыкали Enter и указывали, что "расчёты какие-то не такие повтори ещё раз".
С учётом всего этого, и в целом информации по алкоголю/расчётам/формулам в интернете, любой первый встречный сделает аналогичный калькулятор, которых итак как грязи.

[Евгений]

Ankhena, так спам видимо и есть, для обычных вопросов бы не проставляли бы текст для ссылки, а оставили бы просто ссылку

Answer 1

[Пума Тайланд]

конкурент задублирует запросы к API — и по входам-выходам всё восстановит

Answer 2

[AlexVWill]

WebAssembly

Answer 3

[Shrizt]

Однозначно да, если алгоритм того стоит, на клиенте это не защитить

Answer 4

[Константин Б.]

На мой взгляд это десткий сад. Ну можете усложнить ненмого логику минимизировав JS
Но в целом любой ИИ агент наделает этих формул на раз два и на ваш сайт даже не придётся заходить

Comments

[Михаил]

По поводу ИИ соглашусь. Но в данный момент есть трафик, и трафик неплохой. Что будет дальше - будем посмотреть.

Answer 5

[Артём Дайнов]

Вы можете зарегистрировать патент на формулу. или как там это сейчас называется. Короче, получить авторское право.
А дальше пусть кто копирует, вы просто жалобу на хостинге, а хостинг бан делает. Или суд на владельца сайта. Главное в html, желательно вначале где-то, укажите что код под авторским правом.
back-end можно защитить, к примеру принимаем домены только от себя.
Ну к примеру, условный a.com и всё. Пришел b.com, мы ему показываем 403 или вообще 404. Берем и путаем тех, кто пытается в back-end стучать.
Ну а вообще, можно придумать безопасность и тд, потому что и домен можно подделать.
Но я бы не стал выдумывать. Авторское право на код и всё. Кто украл, того в суд или хостинг бан.

Comments

[rPman]

не очень понимаю, как 'по честному' доказывать в суде что формулы украдены? по совпадению ответов? а если они будут отличаться на epsilon?

патент на формулы? на константы? 2+2=4 в бан?
помнится тут народ плакали что oracle из-за java (там буквально судом из 11к изначальных были признаны 9 строчек кода украденными, но признаны добросовестным использованием, и вроде бы речь идет о простом rangeCheck) на google android руку подняли... двойные стандарты?

[Владимир]

rPman, 100% да. Товарищ начитался всякого и поверил, но в реале это не сработает, там патентовать вообще нечего, разве что только сам сервис в совокупности, но оно того не стоит.

Answer 6

[rPman]

Переноси код на бакэнд, вводи лимиты на количество запросов, авторизацию пользователя, капчи от ботов и т.п.

Правильно разработанный бакэенд и фронтэнд будут давать задержку ровно на величину ping + время на вычисления (скорее всего считанные миллисекунды), если пинг меньше 200мс то пользователь даже не заметит (как сейчас практически никто не замечает что калькулятор в windows запускается пол секунды).

Просто не переусложняй, обычный http rest или лучше websocket.

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

p.s. не уверен что выбрали удачный бизнесплан.
Попробуй найти другие способы отбить затраты на разработку.

Answer 7

[Василий]

может что то вроде https://github.com/spinframework/spin использовать скомпилировать js в wasm и скорость не уменьшиться оно в браузере работает. И код так просто не увидишь. Хотя можно

Answer 8

[Николай]

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

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

Comments

[Михаил]

По поводу формул — да, это не лабораторная медицинская система и не судебная экспертиза. Любой онлайн-калькулятор- это модель с допущениями и усреднениями. Основная задача тут — дать человеку ориентировочную оценку состояния, а не заменить алкотестер или анализ крови.