Investigate what good function-level input/output we should use and how it looks like

[lwjohnst86]

And like how to convert that in a relatively easy way to convert into Django Model structure?

[martonvago]

I think this is hopefully very straightforward: basically, pull all code that doesn’t access properties on incoming requests and is not concerned with formatting information for displaying it to the user out into separate functions. These functions will have well-defined inputs and unambiguous outputs, whatever is convenient in a given context. Both the web and the cli component will pass relevant bits of user input to these functions, have the functions execute the core logic, and then format the output of the functions for user display (using Django templates or printing to the terminal, respectively).

I think there was some discussion about wanting to avoid union return types (e.g HttpResponse | HttpResponseRedirect). We can easily avoid these in our functions implementing core logic, and we could follow whatever pattern is recommended by Django for request handling.

As for Django models, if we want, we can use them, alongside the Django ORM, as they come out of the box. We can define them e.g. in the core component and import them in other components easily. The only difficulty is that if the application is accessed "directly" through a CLI command (more detailed description here), then we'll have to set up Django manually beforehand for that command to have access to the models and the database.

[lwjohnst86]

Great 😁 I've already commented in #479, but to add to here specifically, I think that makes a lot of sense, and it will be infinitely easier to test when we split the functions into "only for Django/web" vs "generic context" (at least I know I will have an easier time). Not sure yet how I feel about the union return types, but we will cross that when we get there.