Evaluating FeatherJS Authentication Needs

问题:

My collegues and I want to build a chat application (ReactJS <-> NodeJS), and we have been looking for the best framework to do so. FeathersJS seems undoubtedly the most stable and feature-rich socket.io wrapper.

However, as we want to allow our application to scale up, we have decided to split this chat feature in a different node process than our main node backend.

The chat functionalities still requires authentication and authorization however, and we would like to avoid duplicating authentication for the two services. Hence what we have come with as a solution is to query the main node backend with the session cookie to authenticate the user before letting them use the chat service.

Does FeathersJS establishes long-lasting socket connections or would it establish a socket connection for every message sent/received? In the first case we could proceed with our architecture, whereas on the second we'd have to review due to the high load this would produce on the main backend.

Thanks!

回答1:

There are several ways of splitting up services each with their own advantages and drawbacks. One generally important thing for Feathers is that there are no sessions, just JSON web tokens. JWTs are stateless and can be read by any server that shares the same secret so there does not have to be a central session store. The two main options I can think of are:

1. Have a main application that handles authorization and managing all connected clients but instead of having services that talk to the database they connect to separate simple individual API servers in the internal network. This is the easier setup and the advantage is that the internal API servers can be super simple and don't need authentication at all (since the main application is allowed to do everything and will make queries according to the authenticated users restrictions). The disadvantage is that the main application is still the bottleneck (but with a decreased load since it basically acts as a proxy to internal APIs).

2. Every client connects to every API server they need using a JWT. The JWT is created by a separate authentication (or user) API. This is the more scalable solution since the only bottleneck is retrieving the most up-to-date user information from a common users service (which might not even always be necessary). The disadvantage is that it is more complex to manage on the client side and authentication (at least for JWT) will have to be configured on every server. Due to the statelessness of JWT however, there does not need to be any shared sessions.