brrcrites / reach-out Goto Github PK

Because types! It would be ideal if we could switch both the server and client side code to typescript, and if #6 is complete update the ESLint rules as well.

The app currently uses the default HTML style except where it is specifically overridden using styled components (which for now is only in the nav bar). We should apply some generally nice looking style sheet globally and then use the styled components to override where necessary, and we'll probably want to use a pre-built stylesheet (because who wants to put together all that style info from scratch?)

Breaking this out of #11 because its dependent on #8 for getting a full history of scheduled recurring jobs while the create/delete endpoints are not. Additionally we may want to have various filters that can be applied to this endpoint to show either currently enabled and running scheduled recurring jobs and/or all historical scheduled recurring jobs.

Recurring job sent message, I responded to the message and the last sent message had 0 replies but the first sent message had +1 reply.

The RecurringJobSystem doesn't check the mongo db to see what jobs are set as enabled when it boots, so if there is data leftover in the mongo db when we shut down the server and we boot it back up the job cache is out of sync with what we would expect from the mongo. Part of this can be addressed by sending the data from the job cache always in the list endpoint, but that doesn't solve the problem that when the server does down (and it will) it won't reload the jobs and start executing them again.

There is also a scalability problem here in that we don't have a method for dividing up the cron jobs across multiple servers for execution as the process scales, but thats future us' problem.

Right now there is absolutely no linting being done (or really anyway to lint) we should implement basic linting (maybe with use strict) and if possible add it as a pre-commit hook.

Whenever I try and execute it after #19 was merged I get the following

mongo uses an image, skipping
Building webapp-server
ERROR: Cannot locate specified Dockerfile: Dockerfile - PORT=8081

When there is at least one number present a blank option appears in the drop-down for numbers that are available but there aren't any matching messages for it when using it as a filter.

The webpack-dev-server has a hot-reloading system built into it which we can't directly use because the code lives within the docker containers. It would be ideal if we could add hot-reloading to the docker system to speed up development by not requiring a rebuild and redeploy every time there is a code change.

Here is one article which is supposed to allow hot-reloading in the webpack-dev-server

Multiple children (A, B, C) all schedule a message to check-in on the same parent (D). When parent D replies, how do we know which of A,B, C they were responding too, or do we forward their response on to all of them and associate it with all of them?

This endpoint show allow you to get the messages sent through the twilio API and should include both 1-off messages and cron based messages (perhaps with a way to distinguish between them). It will need some query ability and needs to be able to display all message (just for debug and likely to be removed in the future) as well as based on the number the message was sent to.

We need to create an endpoint allowing the user to retrieve all messages that were sent and have not been responded to. This should take parameters to determine what to number you are searching for and how long the message has been not been responded to.

The project currently only exists as a locally deployable docker-compose system. We should leverage docker-compose to setup a deployment pipeline so that whenever master is updated the changes are pushed to a server and re-deployed (either through docker image updates or directly)

Create a table on the Dashboard for recurring jobs. Should contain a column for
| To | Time | DoW | Active |

Create a new page that allows a user to create a new scheduled recurring job. This page should be able to take all the fields for creating a scheduled recurring job from the user and make a request to the server to create said schedule recurring job (requires #11). Ideally this page should also use proper input fields (date and time pickers for example) and do some basic validation before sending the request to the server.

Create a new schema and collection to that will allow us to save scheduled recurring event jobs so these can be later read by the system and executed. While these jobs will likely be registered with another system to actually fire on a schedule, the registration of those events may not be synchronous (i.e. the request to create a recurring job may happen and it may be registered with the firing system later) or it may be necessary to recover from server downtime (i.e. on server boot it reads the scheduled recurring jobs and registers them with the firing system)

This will minimally need the information for how often the message should be sent (its likely we will use a cron style package like node-schedule so you may want to base that info off their needs) as well as what message they want to send and will likely also want to include what format (sms, voice, etc.) to allow us to support multiple formats, though we should start with sms.

Create a page that allows the user to see all messages that have been sent but have not yet received a response. This should likely allow you to filter by to number and by length of time (with either being blank meaning to get everything).

Warning: Each child in a list should have a unique "key" prop. From browser debug window.

1. Create recurring job
2. Received message from job
3. Respond to message
4. View chat/results on Dashboard and ChatHistory

The frontend needs much better testing. An example of this can be seen where I made a code change that added a random s to a file and had a missing include and this wasn't picked up by the travis automated testing. In fact the only testing we do for the frontend is a build test which apparently doesn't catch this sort of issue.

We should refactor the homepage to simply include some usage instructions and information about the other tabs. The send a single message functionality should either be removed or moved to the recurring job page as a special feature (or perhaps its own page)

Add a user model with a name / phone number / password and authentication. Only provide them the information associated with their account. Messages sent from them and messages they've received.

https://thinkster.io/tutorials/node-json-api/creating-the-user-model

Docker build reruns npm install everytime. Explore how to cache the results and only run it if additional packages have been added.

As part of the contest we need to add a permissive license (they recommend Apache or MIT)

Create a new page that allows a user to view all the currently created scheduled recurring jobs and choose delete a subset. This should query the server for all currently scheduled recurring jobs and allow for a user to select one to be deleted, and then make a request to the server to have that job deleted (requires #11).

Sent a message through a recurring job and then checked dashboard and chat history before responding. The message showed up under "sent message history" but not the chat history until after I responded.

Now that we have some basic endpoints in the server we should add some basic sanity tests to the system to protect against regressions. Since jest is the most popular testing framework for JS its probably what we should use. We will definitely want to enable it for the server, and should investigate if its makes sense to add it to the client as well. As a proof of concept we should create a jest test that writes a number of records to the database (mocking the /send-sms endpoint) and then validates that they are all returned from the /message-history endpoint (this may require some refactoring of the express routes to make testing easier). The test execution should also be registered with Travis to automatically validate we aren't regressing before merging to master.

The scheduledMessage schema stores the details of the messages to send including it's frequency. There is also a field to hold the uuid for a RecurringJob and whether that is enabled or not. Should hook into DB update on enabled job to either (re)start or cancel RecurringJob based on status change (on creation start).

The RecurringJobSystem allows us to register new jobs which will send out messages (hopefully of various types) but in addition to this we will need a system which can receive messages from the twilio endpoints and log some basic information (the message received, when it was received, and who sent it).

It may also be good at this stage to start thinking about how those messages will be correlated to messages sent to determine if a message that was sent was not responded to within some amount of time. This may be something we implement in this replied messages system or a different system that uses the replied and sent messaging histories to do the correlation and generate alerts.

Building a lot of components ourselves is going to be tedious and error prone (and we probably won't be able to make everything we want) so ew should instead add an existing react component library to the system. I've worked with antd before which seems pretty popular but had a bit of trouble installing it due to css issues.

Some components I think we are going to want:

• Time Picker
• Day of the Week Picker
• Date Picker (maybe?)

When the minute is 0, the scheduled rule has null for minute causing it to send every minute. Possibly caused by 0 being nullish in the null propagation operator. ?. is also not the most supported operator, may want to reconsider it's use.

Using docker-compose -f or using docker-compose.override work on smoothing over the "prod" and "dev" workflows of the docker-compose files. This will potentially aid in issue #9 using docker volumes for hot-reloading in the dev environment only
Medium article to start:
https://medium.com/softonic-eng/docker-compose-from-development-to-production-88000124a57c
Docker documentation:
https://docs.docker.com/compose/extends/

We need to keep a historical log of all messages which we receive with basic information (what number it came from, when we received it, what the response was, etc.). This information may include a link to what message it was sent in response to, but that is mostly determined by how #19 is implement so a basic message schema here we can expand on later should fulfill this ticket.

The recurring jobs page needs to be refactored to be more user friendly (and possibly to hide any rough edges in that currently existing the RecurringJobSystem). We need to refactor the way the recurring job creation form looks so its more user friendly as well as the list of recurring jobs (preferably turning that into a table).

Some other programatic things we might want to hide for the submission:

• Remove the voice and debug options for the recurring job system
• Convert the recurring job list display to only be those enabled in the cache (can be done by changing what the endpoint for getting that list sends by asking for cached jobs rather than mongo jobs)

When the cron job is being created if you pass it an empty dayOfWeek array it seems to lock up the system. We need to screen the values being passed so that whenever an empty array is passed its converted into a null when being set in the rules.

Person A sends a message to person B. Person B responds and it is logged. Person B forgot they responded and responds again. Does it log again? Does it alert someone that they responded twice?

• Add filtering to the chat system (ideal) or make it more obvious who the messages are being sent to (we assume only one from message at this point)

• Remove response text from the various pages (recurring page, home)

• Consider removing or moving the send single text messages panel (perhaps to the chat history page)

• Hide the recurring jobs table when its empty and just print "no recurring jobs"

• Remove the non-unified chat history (received/sent) from the chat history page

• Reorder the header to dashboard comes after home

Many of the pages submit new data which updates a table and should cause a refresh, but currently don't. We should create a reusable system or pattern for reloading on submission.

Create a new endpoint that sends back all the to numbers from the messages sent/received tables. This will be used in frontend filtering to to allow users to pick which to number they want to see chat history or missed responses for.

The testing implementation of the createJob() function in the RecurringJobSystem as a debug step we have the cron job create a console.log with some basic information about the message that would have been sent. This needs to be replaced with a twilio sms call followed by a Message creation and save to mongo.

Ideally we would also add a debug boolean to the endpoint (and make it usable in the front end) that would switch from sending the sms to console.log that the message would have been sent, but both would save the message to the mongo

Create a page for seeing the messages sent/received (in the short term this will be based on the to and from numbers, long term we will have to think about what happens if the twilio number changes). A nice view for this may be to create a chat log showing both parties messages (the automated and the received) to give the user a better understanding of the context.

We need to create an endpoint that allows us to query for messages that have been sent back to our twilio number. This endpoint will need some amount of query ability with it minimally being able to return all messages (for debug only, and possibly removing this in the future) and based on the number the message comes from.

Create a system for executing the scheduled recurring jobs when they are scheduled to be executed. Rather than building a system from scratch (which would be very hard to get right) we should use an existing system like node-schedule. This system will require a way for new scheduled recurring jobs to be registered, either from reading the mongo db directly or through a secondary registration system.

Create endpoints that allow you to create, retrieve and delete scheduled recurring jobs. These endpoints should add/remove the scheduled recurring job from the mongo database (requires #8) and should either register the schedule recurring job with the system which will run it on schedule or queue it to be registered in the future (requires #10). The retrieve endpoint should simply return a list of all currently scheduled recurring jobs, sanitizing out the db specific information. In the future we will likely want to retrieve the scheduled recurring jobs by user, however since we don't currently have a user model this should be considered as a future requirement but not yet implemented.

Add a docker-compose build test in travis for all of .prod, .dev, .test to avoid regressions breaking any of the compose files. Also, remove the docker-compose.yml default file since it isn't used anymore.