Консьерж-служба, предоставляющая широкий спектр услуг в сфере персонального менеджмента и консалтинга. Предоставляет услуги по требованию для клиентов, которые варьируются от руководителей бизнеса до сотрудников и частных лиц.
APC_14_Presentation.mp4
APC_Stage.mp4
Concierge Service - это SPA с архитектурой и структурой реализованной на стеке MERN.
Документация backend и frontend.
В целом, общей темой консьерж-сервиса является предоставление индивидуальной помощи и внимания к потребностям клиента, независимо от отрасли, в которой он предлагается.
Основная идея проекта - Консьерж-сервис — это индивидуальная помощь, оказываемая профессионалом, который стремится удовлетворить потребности и запросы клиента. Эту услугу можно найти в различных отраслях, таких как гостиничный бизнес, здравоохранение, недвижимость и путешествия. Консьерж выступает в качестве посредника между клиентом и услугами или продуктами, которые ему требуются, договариваясь, резервируя и предоставляя рекомендации для обеспечения удовлетворения потребностей клиента. Цель услуги — обеспечить беспрепятственный и беззаботный опыт для клиента, а консьерж выступает в качестве универсального магазина для всех их потребностей.
- Локальная аутентификация
- OAuth (Microsoft Azure)
- Работа с сессиями, сохранение сессий в базе
- Локальное хранение файлов и их защита
- Процесс заказа с помощью multistep form
- Спроектированная база данных
- Защищенный API для взаимодействия клиента с БД
- Динамичное обновление контента на клиенте
- Chat с разными типами сообщений (текст, формы, документы)
- Flight Tracker
- CRM
- Переводчик в чате на разные языки
- Автоматическая генерация документов для бухгалтерии (приложение 50 форма P-1)
В проекте используется OAuth и локальная аутентификация. Авторизация происходит посредством сессий, которые сохраняются в базе данных, благодаря чему при перезагрузке сервера сессии не удаляются.
Сейчас реализована аутентификация OpenID Connect от Microsoft Azure с помощью Passport.js. Логика реализации позволяет добавлять и другие OAuth сервисы.
Если потребуется дополнить проект JWT-токенами нужно будет переделывать как фронт часть, так и бэк часть.
В этом проекте при потребности авторизации по JWT, нужно реализовывать Refresh Token несколько на один аккаунт. Refresh Token в идеальном случае реализации JWT-авторизации лучше использовать один на аккаунт клиента, что может быть полезно в приложениях требующих большей безопасности, но в таком случае при смене на другое устройство каждый раз придется вводить логин и пароль.
Также JWT-авторизация была бы удобна при использовании микросервисной архитектуры, где можно было бы, например, запускать /auth, /file, /mail сервисы отдельно друг от друга. Сейчас мы ограничены монолитной архитектурой.
Файлы хранятся локально в файловой системе сервера. Требуется доработка в случае, если придется использовать распределенные серверы.
Реализована загрузка файлов кусками(chunk of data) и буферизация на диске, вместо хранение в памяти. Нельзя хранить файлы в памяти, так как может достаточно быстро произойти переполнение памяти.
Реализована абстракция логики создания последовательных, множественных форм и сохранения их в контексте.
В проекте мы используем документоориентированную базу данных MongoDB и ODM mongoose для взаимодействия с базой данных. REST API предоставляет CRUD операции для моделей базы данных с функциями защиты от пользователей, не имеющих доступ к определенной операции.
С помощью websocket реализовано динамическое обновление данных на клиентской стороне, например, браузере, с помощью выполнения функций после изменения документа, которые, в свою очередь, работают наподобие алгоритма наблюдателя (все, кто должен получить обновление, получают обновление). Например, менеджер загрузил данные цен на отели и при изменении цены на этот отель менеджер сразу же уведомляется об изменении и меняет её.
Если в базе данных хранятся все нужные данные о том, какие пользователи должны получать обновление, в терминах socket.io, какому сокету скидывать эти обновления?
Каждый раз при подключении пользователя к сайту мы производим авторизацию и добавляем сокет клиента в комнату user.id. Теперь мы знаем в какую комнату скидывать уведомления изменений. Даже если пользователь зайдет с нескольких устройств, сокеты соединения с этими устройствами добавятся в комнату user.id, оба, и оба будут получать изменения.
Websocket и динамическое обновление контента позволило реализовать обмен сообщениями между клиентом и менеджером-Concierge посредством чата.
У сообщения есть типы, что дает масштабируемость возможных типов сообщений. Уже реализованы текстовые, файловые сообщения и сообщения-формы.
В проекте используются только диалоги, хотя сама логика реализована с учетом групп, где могут переписываться неограниченное количество человек.
На стороне клиента, мы загружаем всю историю переписки, что в некоторых случаях может быть ненужно. Требуется оптимизация, которую можно представить ленивой загрузкой или чем-то вроде пагинации.
Реализована CRM для админов Concierge и менеджеров. В проекте должна быть реализована удобная CRM система, не только для Concierge, но и для партнеров Concierge.
- Flight Tracker - отслеживание авиарейсов и их визуализация на сайте. Данные авиарейсов берутся из открытого API.
- Перевод текста сообщений на разные языки. Используется открытый API MyMemory.
- Анализ тональности текста сообщений. Используется открытый API Ninjas.
- Автоматическая генерация документов для бухгалтерии (приложение 50 форма P-1) последующей реализацией возможности цифровой подписи документов, есть возможность полного избавления от "бумажной волокиты". Используется библиотека Docx.js
- MongoDB
- Express JS
- React
- Node JS
В процессе разработки front и back два отдельных приложения.
React будет общаться с API через proxy.
В производственном окружении SPA React собирается в 2 файла(html, js)
и будет выдаваться сервером.
Инструкции, которые помогут вам запустить
backend
и frontend
проекта на вашем локальном компьютере для целей разработки
и тестирования
смотреть в соответствующих README.
Здесь перечислены основные фреймворки и библиотеки, используемые в проекте. Полный список используемых технологий для каждой части проекта находится в файлах package.json в папках frontend и backend.
- Alar Akilbekov (Backend, React) - Alar-q - @alar4j
- Ayan Ualiev (Backend, Frontend) - Ualiyevvv - @mitxp
- Dinara Dandibayeva (UI/UX Designer) - Dina - @dandi_w
- Ernar Tursinaly (DevOps) - Ernar - @merura
See also the list of contributors who participated in this project.
██████╗ ███████╗███╗ ██╗ █████╗ ██╗███████╗███████╗ █████╗ ███╗ ██╗ ██████╗███████╗
██╔══██╗██╔════╝████╗ ██║██╔══██╗██║██╔════╝██╔════╝██╔══██╗████╗ ██║██╔════╝██╔════╝
██████╔╝█████╗ ██╔██╗ ██║███████║██║███████╗███████╗███████║██╔██╗ ██║██║ █████╗
██╔══██╗██╔══╝ ██║╚██╗██║██╔══██║██║╚════██║╚════██║██╔══██║██║╚██╗██║██║ ██╔══╝
██║ ██║███████╗██║ ╚████║██║ ██║██║███████║███████║██║ ██║██║ ╚████║╚██████╗███████╗
╚═╝ ╚═╝╚══════╝╚═╝ ╚═══╝╚═╝ ╚═╝╚═╝╚══════╝╚══════╝╚═╝ ╚═╝╚═╝ ╚═══╝ ╚═════╝╚══════╝
Perhaps it was too big a scale for me and my development team at the time to qualify for venture capital investment. Although there were a few project managers in the company along with top managers, it didn't affect anything.
During the initial phase of our project, coinciding with the emergence of ChatGPT, our team explored the possibility of integrating its API. The objective was to develop a prototype with potential for venture capital investment. This approach, however, did not align with the CEO's preference for a simpler, more linear website design. Despite efforts to adapt our complex solution to meet these requirements, the project did not progress as anticipated.
Subsequently, I made the decision to depart from the Concierge Service project. My involvement primarily entailed database planning, implementation of authentication methods, and the development of real-time functionalities. As the project evolved, it became clear that the direction of our technical contributions was diverging from the overall strategic goals of the company.