Using WebSockets

WebSockets are useful for having a very dynamic application, where data is shared in near real-time between the server and its clients.

JHipster currently uses Spring WebSockets as its implementation, so you will find a lot more information on this feature on the Spring WebSockets website.

This option has a few limitations:

• The browser auto-reload feature, provided by BrowserSync, that you get when running gulp will not work for the WebSockets. This is because BrowserSync acts as a proxy between your browser and your application, and it cannot handle the WebSockets protocol.
• Token-based authentication doesn’t work with Spring WebSockets: if you use this authentication mechanism, you will be able to use WebSockets, but without authentication. As our base example (the tracker) uses authentication, it will not work correctly.
• By default, we use the dispatcher provided by Spring Security, which is an in-memory implementation. Obviously, it will not scale if you want to use several servers. If you want to do so, have a look at the Spring WebSockets documentation which explains how to configure an external broker.
• In WebsocketSecurityConfiguration, the CSRF protection is turned off as it caused too many issues

The “Tracker” example

JHipster provides a simple “tracker” example out-of-the-box. Located in the admin menu, it will track the other users’ behavior: you will see their login and IP, and which page they are currently viewing.

• This is provided as an example so you can easily get started using WebSockets, not as a “production-ready” user tracker, but it works quite well.
• It will show you how to integrate WebSockets with Spring Security, which is quite a complex topic
• This works because JHipster is a Single-Page Web Application, so the WebSockets connections are not reinitialized between each page: this is where you get one of the big benefits of JHipster’s architecture