Application Structure

Backend

The application backend exists within the app/ directory in root. Within app/, lies 5 JavaScript files and four folders. The root .js files are related to starting up the server and handling (and directing) requests. lib/ is a library folder for specific tasks that is referenced by the Controllers.

Main app.js file

If you look in the app/app.js file you will see that secrets, dependencies, and then configuration variables are first set. After that, there is a section where each request in run through a bunch of middleware functions. These all exist within the middleware.js file in the app/ directory. These are tools that are used for nearly every request as well as setting local variables for the request (for example, who is the user and client that have information being retrieved about them).

After the middleware.js functions have all been run, then all the Controllers are set. Each of these Controllers handles a different aspect of the application, from, say, Notifications to Templates. This is followed by the url endpoints and for each, a method from the relevant Controller is passed as the callback function.

At the end of the file is a catch all (shown below).

app.get('/*', (req, res) => {
  res.notFound();
});

This is followed by a number of scheduled operations. This section needs to be moved to standalone functions that are called by a Cron job, really. But, for the time being setIntervals are being used for 3 functions. The first sends out email notifications to users if they have any unread messages at the end of the day and have elected to receive an update at that time. The second checks and sends any messages that were scheduled to be sent in the future. This is run every 15 minutes. The final setInterval runs Messages.findNotClearedMessages() to find whether or not there are messages that have not been cleared. If they have not, it asks Twilio again for the status of the message via smsStatusCheck.checkMsgAgainstTwilio(message). If that message has not successfully sent after 5 minutes, then an alert will go to the case manager in the form of an email that the message may not have been sent successfully.

URL Structure

Almost all Controller methods are repeated twice, once under there URL endpoint (for example, app.get('/clients', ClientsController.index)) and once under the org/ prefix. In this same example, '/clients' returns the case load view page which has all clients whose cm column value is equal to the case manager's cmid (case manager id, which should be called user id, really, for clarity). Now under the /org/clients URL endpoint, the same method ClientsController.index is used, but this time it is at the organization level. To determine what organization a client belongs to, the client is left joined to the case manager who has the organization foreign key. If the organization matches the same as the user making the request, then that client is added to the response array.

There are query parameters that can be set to refine the query results further. For example, starting with the org level query, you can limit by a single department by specifying department number in the query parameters. You can do the same if user is set to a certain user id. These will filter down the result from within the resulting array from that organization query.