You are currently viewing Storing User Settings on Server in SUSI Web Chat

Storing User Settings on Server in SUSI Web Chat

One of the important features of SUSI Web Chat is that the state of the application is maintained upon logout-login and across all clients. The web chat application provides various settings to a logged in user and each user has his own preferences. So all the settings chosen accordingly by the user must be stored on the server so that whenever a user logs in we pull the users data from the server and initialise the application according to his chosen settings and whenever settings are changed we update them on the server. This helps us maintain the state of the application specific to a given user and also across all clients.

The flow behind the implementation is:

  1. The client fetches the settings upon login and initialises the app accordingly.
  2. Whenever user settings are changed, the client updates the changed settings on the server so that it can be accessed by other clients as well and so, the state is maintained across all chat clients

Let us visit SUSI Web Chat and try it out.

How is this implemented?

We use UserPreferencesStore to store all the settings, and Actions to push and pull user data from the server and update the UserPreferencesStore.

Initialising the User Settings

Whenever the app is initialised, getSettings() function is called first which checks if the user is logged in or not. If the user is not logged in then it returns, else an ajax call is made to the server to get the user settings from the server.

The endpoint used to fetch User Settings is : 


where BASE_URL is either the standard server i.e or the custom server user used while logging in.

The server returns a JSON object with the existing settings stored for that user

  "session": {
    "identity": {
      "type": ,
      "name": ,
  "settings": {

These settings are sent to the UserPreferenceStore thorugh the initialiseSettings action.

export function initialiseSettings(settings) {
  type: ActionTypes.INIT_SETTINGS,

The UserPreferenceStore has a _defaults object which stores all the user settings and is initialised with default values. The store listens to ActionTypes.INIT_SETTINGS event which is triggered by initialiseSettings and the settings are updated in the UserPreferenceStore.

let _defaults = {
  Theme: 'light',    //Theme of the ChatApp
  StandardServer: '',  //Standard SUSI AI Server Endpoint
  EnterAsSend: true,  //Send Messages on ENTER Key Press
  MicInput: true,  //Enable Speech Input
  SpeechOutput: true,  //Enable Speech Output For Speech Input
  SpeechOutputAlways: false,  //Enable Speech Output regardless of Input    Type
  SpeechRate: 1,  //Rate of Speech Output
  SpeechPitch: 1,  //Pitch of Speech Output

Once the settings are updated in UserPreferencesStore, the corresponding changes are emitted which trigger the update of all the components using the values present in UserPreferenceStore.

Pushing the User Settings to Server

Whenever the user changes any settings, apart from updating them locally within the UserPreferenceStore, we also have to push the changes to the server.

When user settings are changed, we first find out only those settings which have been changed and send these changed settings to the UserPreferencesStore to update _defaults through settingsChanged action which calls the dispatcher using SETTINGS_CHANGED action type to pass the data to UserPreferencesStore.

export function settingsChanged(settings) {
  type: ActionTypes.SETTINGS_CHANGED,

This data is then collected in UserPreferencesStore where the _defaults are updated accordingly.

case ActionTypes.SETTINGS_CHANGED: {
  let settings = action.settings;
  Object.keys(settings).forEach((key) => {
    _defaults[key] = settings[key];

We also need to push the user settings to server. We make an ajax call to the server for each setting that has been updated in the pushSettingsToServer action.

The endpoint used to add or update User Settings is : 


where BASE_URL is either the standard server i.e or the custom server user used while logging in.

Here, the access_token is also passed in the server call as it is needed by the server to distinguish between logged in and anonymous users. The access_token is stored in cookies when a user logs in and is accessed from cookies whenever required.

This is how user specific data is maintained on the server and is pushed and pulled from the server to maintain the state of the chat app upon login-logout and also across all chat clients without using any local database specific to the clients.

The entire code can be found at SUSI Web Chat Repo.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.