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
grunt
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