评估FeatherJS身份验证需求

时间:2016-12-10 14:27:48

标签: node.js sockets feathersjs

我的同事和我想建立一个聊天应用程序(ReactJS< - > NodeJS),我们一直在寻找最好的框架。 FeathersJS无疑是最稳定,功能最丰富的socket.io包装器。

但是,由于我们希望允许我们的应用程序扩展,我们决定将此聊天功能拆分为与主节点后端不同的节点进程。

聊天功能仍然需要身份验证和授权,我们希望避免重复两种服务的身份验证。因此,我们作为解决方案提供的是使用会话cookie查询主节点后端,以便在让用户使用聊天服务之前对用户进行身份验证。

FeathersJS是否建立了持久的套接字连接,或者是否会为发送/接收的每条消息建立套接字连接?在第一种情况下我们可以继续使用我们的架构,而在第二种情况下我们可以继续由于主要后端产生的高负荷,必须进行检查。

谢谢!

1 个答案:

答案 0 :(得分:4)

分解服务的方法有多种,各有各的优缺点。 Feathers的一个重要的事情是没有会话,只有JSON web tokens。 JWT是无状态的,可以被任何共享相同秘密的服务器读取,因此不必是中央会话存储。我能想到的两个主要选择是:

  1. 拥有一个处理授权和管理所有连接客户端的主应用程序,但不是将数据与数据库通信的服务连接到内部网络中的单独的简单单独API服务器。这是更容易的设置,其优点是内部API服务器可以非常简单,并且根本不需要身份验证(因为允许主应用程序执行所有操作并根据经过身份验证的用户限制进行查询)。缺点是主应用程序仍然是瓶颈(但负载减少,因为它基本上充当内部API的代理)。
  2. Main server configuration

    1. 每个客户端使用JWT连接到他们需要的每个API服务器。 JWT由单独的身份验证(或用户)API创建。这是一种更具可扩展性的解决方案,因为唯一的瓶颈是从普通用户服务中检索最新的用户信息(这可能甚至不一定是必需的)。缺点是在客户端管理更复杂,并且必须在每个服务器上配置身份验证(至少对于JWT)。然而,由于JWT的无国籍状态,不需要任何共享会话。
    2. Distributed services