Я создаю два набора сервисов на веб-сайте (все написаны в NodeJS на сервере), оба используют подход RESTful. Для модульности я решил сделать обе службы отдельными объектами. Первая услуга относится к продуктам сайта, а вторая специально относится к функциям, связанным с пользователем. Таким образом, у первых могут быть такие функции, как getProducts, deleteProduct и т. Д. У второго будут такие функции, как isLoggedIn, register, hasAccessTo и т. Д. Модуль продукта совершит несколько вызовов к пользовательскому модулю, чтобы убедиться, что человек, совершающий вызовы, привилегия сделать это.Связь между API RESTful на том же сервере с NodeJS
Теперь причина, по которой я их разделял, состояла в том, что в ближайшем будущем я предвижу разворот отдельного ассортимента продуктов, но мне нужно будет использовать ту же систему пользователей, что и первая (даже совместное использование одной и той же базы данных). Пользовательская система будет использовать базу данных, охватывающую весь сайт и все последующие продукты.
Мой вопрос касается коммуникации между этими проектами и проектом пользователей. Каков наиболее эффективный способ разделить модуль пользователей без каких-либо значительных ударов по скорости. Если API-интерфейс продукта сделал вызов API-интерфейса пользователя на том же сервере (localhost), существует ли значительная стоимость для этого, а также для создания пользовательского API в каждом последующем проекте? Есть ли лучший способ сделать это через межпроцессное общение? Просто ли API пользователей запускается как собственная услуга?
Спасибо, Хосе, есть ли у вас какие-либо рекомендации по связи сокета? Будет ли socket.io быть эффективной библиотекой для сокета? – Mat
Вы можете использовать socket.io между двумя узлами, но на первый взгляд может быть немного сложнее. Мой первый выбор - пакет npm «запрос» (https://www.npmjs.com/package/request) или использовать собственный xhr. Во всяком случае, вы можете протестировать на своей локальной машине реализацию с помощью socket.io и запросить с помощью «apache benchmark [ab]», чтобы иметь представление о том, что вы предлагаете больше скорости для ответа на запросы. –