Инвестиционный кабинет брокера
- Клиент
- Брокер · NDA
- Тип проекта
- wordpress / Интеграции
- Год разработки
- 2023
- Доступ
- NDA
О проекте
Закрытый онлайн-кабинет для брокера, разработанный в 2023 году на WordPress с кастомной логикой на PHP и JavaScript. Пользователи работают в отдельном интерфейсе без доступа к админке CMS: фиксируют сделки, просматривают связанную с ними статистику и рейтинг. Для проекта также реализован парсинг необходимой информации с биржевых сервисов.
Что было сделано
- Разработка отдельного пользовательского кабинета на WordPress
- Авторизация и ограничение доступа пользователей к админке CMS
- Кастомная логика личного кабинета на PHP и JavaScript
- Журнал сделок с привязкой записей к пользователю
- Подключение личной статистики и рейтинга пользователей
- Парсинг необходимой информации с биржевых сервисов
Результат
Я создал отдельный личный кабинет, связал с ним журнал сделок, пользовательскую статистику и рейтинг. WordPress позволил использовать готовую основу для пользователей и авторизации, а кастомная логика на PHP и JavaScript обеспечила необходимую функциональность проекта.
В результате пользователь получил единый рабочий интерфейс для фиксации сделок и анализа своих результатов. Получение информации с биржевых сервисов стало частью общей работы с данными кабинета.
Задача
Разработать закрытый онлайн-кабинет для брокера: фиксировать сделки каждого пользователя, объединить личную статистику и рейтинг участников, получать необходимую информацию с биржевых сервисов.
Ограничения NDA
Проект выполнен в 2023 году. Название, логотип, адрес сервиса и реальные пользовательские данные не публикуются.
Как устроен кабинет
Кабинет объединял работу с торговым журналом и анализ результатов. Каждая сделка относилась к конкретному пользователю, а статистика помогала видеть общую картину по его записям: изменение счёта, прибыльные и убыточные сделки, результаты за выбранный период.
В одном интерфейсе пользователь мог фиксировать параметры сделки и переходить между графиками и таблицей. Рейтинг участников дополнял индивидуальную статистику общей картиной результатов в системе.
WordPress и логика приложения
На старте было важно снизить стоимость разработки. WordPress давал готовую основу для учётных записей, авторизации и управления пользователями. Это позволяло сосредоточиться на функциональности кабинета, используя существующие возможности CMS.
Логику для проекта я реализовал на PHP и частично на JavaScript. WordPress стал основой приложения, поверх которой появился собственный пользовательский интерфейс и работа с данными сделок. Для администратора сайта, вся информация показывалась уже в вордпрессе.
Вход и журнал сделок
Пользователю требовался понятный рабочий экран со своими сделками и показателями. Я создал отдельный кабинет и форму входа, а доступ обычных пользователей к административной части WordPress ограничил. Работа со статистикой происходила в интерфейсе проекта.
В журнале предусмотрены дата и время входа и выхода, инструмент, направление Long или Short, цены, объём и размер стоп-лосса. Интерфейс также включал основания для входа и выхода, оценку состояния, скриншот сделки и комментарий наставника.
Личная статистика и рейтинг
Записи журнала нужно было связать с учётной записью пользователя и его статистикой. В кабинете появились общий результат по счёту, начальный и текущий баланс, соотношение прибыльных и убыточных сделок и другие показатели торгового журнала.
Графики давали быстрый обзор динамики, а табличное представление позволяло разбирать отдельные записи. Я привязал статистику к пользователям и реализовал их рейтинг, объединив эти данные с личным кабинетом.
Получение и обработка внешних данных
Отдельной частью разработки стало получение необходимой информации с биржевых сервисов, где пользователи торговали. Основные сложности были связаны с разными форматами данных и ограничениями доступа к источникам.
Информацию из разных источников требовалось привести к виду, с которым мог работать кабинет. Самого получения данных было недостаточно: нужно было сопоставить их с внутренними записями и корректно использовать в общей статистике.
Возможность получения информации зависела от условий конкретного сервиса. При разработке приходилось учитывать доступность нужных данных и ограничения источника, подстраивая получение информации под эти условия.
Поэтому парсинг был связан с дальнейшей обработкой и привязкой данных внутри системы. Названия источников, способы доступа и детали реализации остаются за рамками публичного кейса.