The Cognitive Distortion Journal (CDJ) is a smart journaling tool that helps remedy distorted thinking. It can feel impossible to follow the CBT technique of labeling distorted thinking and finding alternative modes of thought (i.e. reframing) while cognitive distortions are occurring. The CDJ does that work for you. -- The CDJ is in beta testing!!
This PR adds server-side events. Server-side events make the code more modular and streamlines creation routes. An analysis and LLM chat responses generally take several seconds longer than posting content created by a user. This is due to the extra step the server must make to the external API providing the LLM resources.
Currently, on every POST requiring an LLM, e.g. entry creation/update, and chat creation/update, the controller couples the creation logic with an LLM response if the LLM is connected. This logic should be decoupled whereas a createEntry/createChat controller should only post a new entry or chat to the database regardless of whether or not an analyses or chat response is made and the server should simply respond with the entry/chat and post it to the react app with a loading visualizer telling the user the LLM response has been requested and to please wait.
Currently, the user makes an entry/chat post, the textfields/buttons are disabled with a loading visualizer, and only when a response is made or fails is the users post posted. It's more natural to post it first, then await a response, simialr to how text messages work—you can see your post even if the other user didn't respond yet. The LLM should be treated like a separate user, but its being coupled with the user model in some sense.
The route on which these creation controllers are used should then call next() to use a separate getAnalyses/getChat middleware. Since the creation route is sending a response, and closing the socket, due to how HTTP request/response protocols work, another communication channel, either web socket or SSE, should be established. Since the user is only ever making one request, a web socket is unnecessary, making a server-side event ideal for this situation, as it allows only the server to push messages to the client without requiring a response.
The initial commits of this PR include creating an sse util (probably worth moving to middleware directory) to track connected clients to send server-side events to, creating an initial createAnalysis middleware to create analysis (needs to be implemented fully using the EntryAnalysis model method getAnalysisContent), adding the new SSE utility middleware to app, and adding the createAnalysis middleware to entries POST route.
This PR adds server-side events. Server-side events make the code more modular and streamlines creation routes. An analysis and LLM chat responses generally take several seconds longer than posting content created by a user. This is due to the extra step the server must make to the external API providing the LLM resources.
Currently, on every POST requiring an LLM, e.g. entry creation/update, and chat creation/update, the controller couples the creation logic with an LLM response if the LLM is connected. This logic should be decoupled whereas a createEntry/createChat controller should only post a new entry or chat to the database regardless of whether or not an analyses or chat response is made and the server should simply respond with the entry/chat and post it to the react app with a loading visualizer telling the user the LLM response has been requested and to please wait.
Currently, the user makes an entry/chat post, the textfields/buttons are disabled with a loading visualizer, and only when a response is made or fails is the users post posted. It's more natural to post it first, then await a response, simialr to how text messages work—you can see your post even if the other user didn't respond yet. The LLM should be treated like a separate user, but its being coupled with the user model in some sense.
The route on which these creation controllers are used should then call
next()to use a separate getAnalyses/getChat middleware. Since the creation route is sending a response, and closing the socket, due to how HTTP request/response protocols work, another communication channel, either web socket or SSE, should be established. Since the user is only ever making one request, a web socket is unnecessary, making a server-side event ideal for this situation, as it allows only the server to push messages to the client without requiring a response.The initial commits of this PR include creating an sse util (probably worth moving to middleware directory) to track connected clients to send server-side events to, creating an initial createAnalysis middleware to create analysis (needs to be implemented fully using the EntryAnalysis model method
getAnalysisContent), adding the new SSE utility middleware to app, and adding thecreateAnalysismiddleware to entries POST route.