2015-05-08 2 views
3

Я создаю два набора сервисов на веб-сайте (все написаны в NodeJS на сервере), оба используют подход RESTful. Для модульности я решил сделать обе службы отдельными объектами. Первая услуга относится к продуктам сайта, а вторая специально относится к функциям, связанным с пользователем. Таким образом, у первых могут быть такие функции, как getProducts, deleteProduct и т. Д. У второго будут такие функции, как isLoggedIn, register, hasAccessTo и т. Д. Модуль продукта совершит несколько вызовов к пользовательскому модулю, чтобы убедиться, что человек, совершающий вызовы, привилегия сделать это.Связь между API RESTful на том же сервере с NodeJS

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

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

ответ

2

Если у вас есть два узла на одном сервере (машине), то у вас есть плохая производительность с точки зрения сетевой латентности, потому что оба находятся на локальном хосте. Затем узлы будут обмениваться сообщениями с помощью rest api, поэтому на метро вы будете использовать сокеты узла js. Вы можете использовать unix-сокеты вместо http-сокетов, потому что быстрее, но хуже всего отлаживать, поэтому я рекомендую вам не делать этого (но это нормально знать альтернативы).

И, наконец, ваша система выглядит как «шаблон дизайна актера». На первый взгляд этот дизайн скороговоркой немного трудно понять, но вы могли бы посмотреть на это, если вы хотите получить больше информации о актер модели шаблона:

+0

Спасибо, Хосе, есть ли у вас какие-либо рекомендации по связи сокета? Будет ли socket.io быть эффективной библиотекой для сокета? – Mat

+0

Вы можете использовать socket.io между двумя узлами, но на первый взгляд может быть немного сложнее. Мой первый выбор - пакет npm «запрос» (https://www.npmjs.com/package/request) или использовать собственный xhr. Во всяком случае, вы можете протестировать на своей локальной машине реализацию с помощью socket.io и запросить с помощью «apache benchmark [ab]», чтобы иметь представление о том, что вы предлагаете больше скорости для ответа на запросы. –

Смежные вопросы