Клиент-серверный подход к построению торгового робота для MetaTrader 4/5 и других торговых платформ. Преимущества.

Задумкой статьи было постараться использовать свой опыт, который был получен в процессе долгой практики создания торговых систем и другого софта на языках MQL4, MQL5 и других языках программирования, например, C#. В результате исследований и многочисленных попыток была рождена идея и целый подход к трейдингу, а также к тому, как нужно строить продукт, который ты публикуешь на маркетплейсах по продаже торговых роботов для рынка Форекс и других. Уверен, мой опыт поможет людям. Даже если не удастся скопировать мой подход, то по крайней мере выделят для себя базовые принципы, которые позволят сделать вашу систему (торговый робот) более надежной, гибкой и расширяемой, а также гораздо безопаснее с точки зрения защиты от пиратства и бережного отношения к своей интеллектуальной собственности.

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

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

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

Здесь следует ввести вас в курс дела. Представьте, что вы разработчик торговых систем. Если вы создаете торговую систему, то вам периодически, в процессе написания кода, нужно проверять, как этот код работает на истории котировок (исторические ценовые данные торговых инструментов, например "EURUSD"), нет ли ошибок, и при их обнаружении вносить правки, чтобы со временем довести продукт до приемлемого состояния. Это такой же необходимый инструмент для разработчика роботов, как отладчик для обычного программиста. Считайте его вторым отладчиком.

Теперь представим, что вы покупатель продукта. Представим, кто-то нашел ваш продукт на маркетплейсе. Как проверить его работоспособность более тщательно, не полагаясь лишь на красивые речи в описании продукта и скриншоты об успешном успехе? Тут применяется тот же инструмент. То есть его применение многофункционально. Человек может скачать ваш продукт и проверить, как он работает на истории, чтобы получить дополнительное понимание о том, что он собирается купить. Данный инструмент называется "Тестер стратегий".

Теперь вы будете понимать, о чем я говорю. Начнем с того, что, разрабатывая и тестируя достаточное количество классических торговых систем в тестере стратегий, мы приходим к пониманию того, что со временем вы будете создавать более сложные торговые системы, что неизбежно повлечет за собой замедление тестирования. Основная мысль в том, что в данном случае сложность системы будет напрямую ограничена характеристиками компьютера пользователя, ведь при ее увеличении время тестирования такой системы может оказаться непомерно большим. Иначе говоря, ваша система становится очень сложной, и рано или поздно сложность вашей системы становится настолько высокой, что в рамках "mql5" кода крайне тяжело, а в некоторых случаях практически невозможно усложнять систему, не увеличивая нагрузку на тестер стратегий и вообще на саму торговую платформу. Тут мы рано или поздно натыкаемся на ту же самую проблему, с которой сталкиваются абсолютно все системы — клиентская часть не предназначена для расчетов. Это можно понять по нескольким позициям:

1. Замедление тестирования в тестере стратегий, вплоть до практически полной его остановки. Это же касается режима оптимизации.

2. Слишком высокие требования к железу, на котором запускается терминал MetaTrader. Проблема становится на порядок актуальнее, если мы запускаем несколько торговых терминалов внутри одного ПК.

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

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

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

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

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

Неприятные моменты для разработчика:

1) Усложнение процесса разработки в силу ограничения вычислительных мощностей.

2) Как следствие — невозможность масштабирования торговой системы и интеграции с другими платформами и решениями.

3) Ухудшение качества итоговой торговой системы и результатов торговли.

4 )Замедление разработки, возникновение дополнительных проблем, увеличение трудозатрат.

5) Возможные специфические проблемы у пользователя.

Неприятные моменты для конечного пользователя будущего продукта:

1) Запуск на слабом железе или виртуальной машине может стать проблемным или невозможным.

2 ) Успешный запуск на слабом железе может привести к ошибкам при работе советника, что ухудшает качество работы системы.

3) Медленное тестирование в тестере стратегий ограничивает возможности продукта уже на начальном этапе, так как тратит время.

Следствие недовольства пользователя продуктом на начальном этапе:

1) Повышенная вероятность негативного отзыва: тяжело будет спорить с таким отзывом, так как он в большей степени будет основан на объективных причинах, чем на субъективных суждениях потенциального пользователя.

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

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

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

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

1) Вычислительные серверы (облачные сервисы или собственное компьютерное железо).

2) Многопоточные вычислительные модули для постоянной работы (например, как агенты оптимизатора в "MetaTrader 5").

3) Сервер для бесперебойной работы "API" (как правило, хостятся на облачных сервисах).

4) "API" — прослойка для общения советника с серверами (синхронизация или отправка вычислительных заданий).

На общем уровне я думаю, тут все понятно. Данная схема реализации в любом случае будет в той или иной степени избавлять нас от части вышеперечисленных проблем. Но я думаю, любой на моем месте начнет размышлять уже о деталях, а именно о том, как наиболее эффективно ее применить, например, с учетом возможностей платформ"MetaTrader 4" и "MetaTrader 5", "CTrader", "TradingView" и других. Иначе говоря, чтобы было понятно, что схема одинаково легко и эффективно реализуется на каждой из платформ.

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

Предварительно хочу остановиться на важнейшем элементе — "API". В языках "MQL4" и"MQL5" существует один и тот же предопределенный метод "WebRequest", который и позволяет создавать роботы, способные принимать дополнительные данные из внешних источников, в том числе из правильно созданного "API", учитывающего особенности метода "WebRequest". В других торговых платформах есть аналогичные методы, которые реализуют схожий функционал, что позволяет экстраполировать все мои решения на другие платформы. Подход универсален, и это главное. "API" — это ваш мост между вычислительными серверами и клиентской частью, которой и должен являться ваш торговый робот.

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

1) Открытие и закрытие позиций (или ордеров), установка или отмена отложенных ордеров.

2) Переустановка стоп-лоссов и тейк-профитов (или их уничтожение).

3) Опрос серверов с помощью "WebRequest" или аналогичных инструментов на других платформах в поисках новых торговых команд.

4) Код исполнения новых торговых команд.

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

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

1) Минимальное увеличение нагрузки на систему при увеличении количества одновременно работающих клиентских приложений (торговых роботов).

2) Получение уже готовых торговых заданий вместо отправки собственных заданий каждым торговым роботом.

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

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

1) Вычисления на своем железе

2) Переадресация вычислений в облако (интеграция с нейросетями и другие подобные решения)

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

1. Практически все нейросети платные, а это — лишние издержки.

2. Выбор нейросети не очевиден сразу и потребует тестирования различных вариаций взаимодействия с ней.

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

4. Нейросеть в любой момент может перестать работать или изменить свою политику в отношении вас как пользователя, особенно в наше время.

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

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

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

1) Максимальная надежность всей системы в целом, поскольку надежность всегда выше при максимально простых решениях и максимальной надежности отдельных её элементов.

2) Максимальный контроль всех составных элементов системы и оперативность в локализации проблем, а также их устранении.

3) Более широкий спектр направлений для масштабирования и дальнейших улучшений: свой софт и архитектуру проще поддерживать и модифицировать, без необходимости учитывать ограничения со стороны интегрированных внешних решений.

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

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

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

Этот раздел занимает особое значение среди всех прочих. В чем же его особенность? Мало кто задумывается о защите своих продуктов даже на таком популярном портале, как "mql5.com". Я беру его лишь в качестве примера, но вовсе не считаю его эталоном;хочу, чтобы все поняли: просто мне проще рассматривать это на данном примере,поскольку у меня большой опыт работы с данным маркетплейсом.

Как известно, площадка "mql5.com" обеспечивает базовую защиту своих продуктов, ноэтого, мягко говоря, недостаточно. Уже давно появился софт, который способенвзламывать купленные продукты и избавлять эти копии от активаций и лицензий. Прощеговоря, продукт становится полностью свободным для использования любымпользователем MetaTrader.

Дополнительной опцией подобного софта является возможность декомпиляции кодов MQL4 советников, что позволяет всем желающим углубиться в секреты того или иного продукта. Про версии советников для MetaTrader 5 пока мне мало что известно, потому что я сильно не углублялся в вопрос, но мое MQL5 чутье подсказывает, что такой софт существует, и он находится в добром здравии, обеспечивая целостность теневого рынка взломанного софта с "mql5.com".

Пиратство на данной платформе цветет пышными букетами. Существует целый теневой рынок взломанного софта; я его видел, знаю Telegram-каналы и все, что нужно для этого. Во многом крайне низкий уровень защиты продуктов платформы "mql5.com" и заставило придумывать методы защиты от данного произвола. Остальные же, наверное, стараются не думать об этом или просто не раздражать платформу.

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

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

Чтобы решить проблему взлома, нужно, чтобы взлом не имел смысла. Взломанный клиент с минимальным функционалом уже сам по себе не представляет никакой ценности без серверной части. Это я имею в виду на уровне кода.

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

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

1) Дополнительный функционал "API" (админка для управления ключами).

2) Клиентское приложение для управления ключами.

3) Мониторинг активности ключей (лично я использую технический Telegram-канал).

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

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

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

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

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

А что если наше "API" загружает настройки к нашей торговой системе, которые являются результатом ее регулярного переобучения на свежих рыночных данных? Все очень просто: нет сервера — нет регулярного обновления настроек системы. При отключении сервера через какое-то время настройки системы устареют и станут терять эффективность, а после какого-то времени и вовсе станут убыточными.

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

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

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

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

Исходя из вышеперечисленного, отсутствие грамотно реализованного клиент-серверного подхода чревато многими негативными эффектами. Я здесь специально уточняю, что это не относится к более чем 99% продуктов на маркетплейсе "mql5.com", которые неплохо чувствуют себя и без наших с вами мудреных схем. Но есть инсайд: как правило, продукты, находящиеся в топе продаж, всегда применяют оригинальные решения, и это неизбежно, если вы хотите конкурировать и делать хорошие продажи.

Что такое конкурентность, в двух словах не обрисовать. Давайте я попробую обозначить основные признаки конкурентности продукта. Есть мнимые, а есть правдивые. Тут у каждого, возможно, может быть свое мнение насчет этого, но я решил включить этот пункт как дополнительное подтверждение правильности моего подхода и его жизнеспособности в рамках конкуренции и её следствия — продаж.

К мнимым конкурентным преимуществам я бы отнес наиболее распространенные подходы в построении торговых систем, такие как, например, сеточная торговля, мартингейл, неправильная докупка или усреднение. Все дело в том, что в основном такие подходы лишь имитируют прибыльность. Для большего числа пользователей это нормально, и им это нравится, потому что такие решения зарабатывают сразу и довольно быстро. Не важно, что потом покупатель сливает депозит в 100% случаев, главное —выдержать прибыль достаточное время. Этого как раз хватает для того, чтобы покупатель оставил восторженный отзыв и продвинул фейковый грааль наверх, на вершину списка. Чем больше он двигается в рейтинге площадки, тем больше таких отзывов он получает. Это цепная реакция, это работа с толпой. Толпа очень хорошо подчиняется прогнозированию.

Такие подходы, как раз таки, позволяют не добавлять сложные вычисления в код и придерживаться стандартных требований маркетплейса "mql5.com", но вместе с тем несут за собой те недостатки, о которых я говорил в одном из разделов выше.

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

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

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

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

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

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

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

Вот примеры компаний, с которыми Россияне до сих пор могут сотрудничать и торговать через них, несмотря на санкции Евросоюза. Я перелопатил их все. Выжили только эти: "RoboForex", "FxPro", "TickMill", "Switch Markets", "Black Bull", "TeleTrade". Остальные отказываются работать с нами. Конечно, скоро они начнут переобуваться, но это уже лирика. Чтобы максимизировать эффект от вашей аудитории халявщиков, вам нужно интегрироваться в партнерские программы как можно большего числа компаний из данного списка. Мне удалось реализовать интеграцию с первыми двумя из данного списка, потому что опять же у них есть свое "API". С помощью данной интеграции работает вот эта версия моего торгового робота.

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

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

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

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

Ссылки для ознакомления (в подтверждение моего опыта):

1. Мой профиль на платформе mql5.com.

2. Моя торговая система на маркетплейсе "mql5.com".

3. Бесплатная версия моей торгового робота работающая через партнерскую программу.

4. Канал с бесплатными, упрощенными торговыми роботами.

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

6. Бесплатный универсальный робот (для которого предназначены настройки из п.5).

7. Брокеры, которые не отказались от обслуживания Россиян - "RoboForex", "FxPro", "TickMill", "Switch Markets", "Black Bull", "TeleTrade"