Next, we need to determine what functionality should be tied to messages in our application so that we can figure out what code we should be writing in our context. While you can always just default to implementing full CRUD (create, read, update, delete) for each of your schemas, you may specifically want to avoid doing this. One good thing about not just implementing these by default is you standardize the API for your database models that other developers can see and interpret. Doing so allows you to specify safe boundaries for how to interact with various models (for example, there may be a database table of constants that you do not want the user to be able to modify). In the case of our application, with messages for our chat application, maybe we don't intend for a user to ever be able to edit their own messages. This is a sound reason for us to completely avoid implementing an edit or update function in our context and controllers! Now we have less code to write, less code to maintain, and fewer entry points for bad data into our table. The surface area is reduced while the intended functionality remains the same, and of course, we can always go back and add more code later to cover any gaps.

Let's design the functionality for our chat messages just to make sure we cover these same rules and assumptions:

• Users should be able to make new messages
• Users should be able to see chat messages for polls
• Users should be able to see chat messages for the lobby

That's a good first pass and tells us that we will need to implement a list function for messages (and one with the poll ID specified), as well as a create function. That's an easy first pass of functionality to implement in our context!