Можно использовать redis(pub/sub) или банальный socket.io, через это есть возможность сделать обмен сообщений между приложениями, даже если они запущены на разных серверах.
Вам надо использовать настроенный сборщик для фронта, который правильно добавлял бы модули зависимости, в скомпилированный код проекта. Так как сейчас у вас получается, что скрипт собирается как для бека, хотя это фронт, фронт не может делать require("vkontakte-api")
Тут либо разбираться как сделать такое через webpack.
Либо использовать готовый фреймворк, в котором уже настроена такая сборка... vuejs, react и тому подобные.
Денис Яковлев, стандарты бывают глобальными, которые используются большинством разработчиков в мире, так и локальными, которые используются только внутри отдельного проекта... любые глобальные стандарты, это когда-то бывшие локальные стандарты, если у вас не получается быстро найти информацию о предполагаемом стандарте, то создайте свой стандарт, пропишите его в документах и используйте.
Денис Яковлев, вы хотите предавать какой-то id, в тех сообщениях, которые отправляете в MQ? Тут я точно не знаю стандартов и не уверен, что они есть... так как использование MQ, это не на столько часто используемая операция, как авторизация в rest-api. MQ системы используются обычно либо в HighLoad системах, либо под специфические задачи, вы можете сами определить, как вам передавать id в MQ сообщениях... например сделать стандартную обёртку для MQ сообщений, типа JSON:
{
id: "*какой то айди*"
data: { ... то, что передаётся в сообщении ... }
}
De1mos, а, вот вы про что... не сразу понял, что дело идёт о MQ системах, стандартов авторизации в таких системах мне не известны, хотя думаю их можно посмотреть в документациях. Так же скажу, что обычно для MQ авторизации не нужно, они просто находятся внутри закрытой сети, как база данных или какой нибудь редис, и те микросервисы, которым необходимо подключиться к MQ, просто берут и подключаются по адресу и порту.
De1mos, если сервер идентифицирует пользователя через этот заголовок (Authorization:) то да.
Обычно клиент логинеться через пост запрос, например /api/user/login, от него в случаи успеха получает JWT токен, который сохраняет, и в дальнейшем встраивается во все запросы к апи, через заголовок Authorization
Sanes, ограничения есть всегда, есть обычные сайты, которые ограничены готовыми решениями, а есть сайты сделанные на более открытых решениях, у всего есть свои плюсы и минусы... Да от реализации тоже зависит... Но в среднем у открытого решения будет больше возможностей и более гибкая архитектура, плюс отсутствует абон плата за лицензию CMS, так как сайт будет принадлежать заказчику от и до.
Sanes, если нужен уникальный функционал, то только так. Битриксы и прочие, они очень ограничены по возможностям, а если нужно что-то не стандартное, то надо искать специалисты по костылям. Да и не так уж это дорого, несколько сотен тысяч за сайт, который гораздо лучше поддаётся модификациям и расширениям, это вполне стоит своих денег.
когда делается var schema = require('./application/config/schema');
то созданная переменная schema будет ссылкой на объект созданный в модуле ./application/config/schema
переменная это только ссылка на объект, на один и тот же объект может указывать несколько переменных, изменив объект через одну переменную, он изменится и на других переменных
Должны быть признаки, что запись создалась или обновилась : время создания и обновления например. И действительно должен быть отдельный слой в виде модуля, который работает с бд через драйвер или орм. И хорошо бы, чтобы названия методов отражали суть изменений и с какими данными они работают -- страницы, юзеры, комментарии, записи в логи. Запутанность вложенных каллбеков надо компенсировать большей ясностью и оптимальностью всего остального, что их окружает в коде.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.