The rough determination is the following:

Context at their core are nothing more than what you did before: Put business logic into modules. This is mostly something special in the context of webframeworks, because people tent to not separate this from the actual code handling specifically webrequests.

Now the code in context cannot yet be called via web requests. This is what your endpoint/router/controllers are for. They receive requests and handle them in various ways. The endpoint is for stuff affecting any requests coming in, the router handles forwarding to controllers based on things like paths or other determinations, while controllers/their actions are there to handle the specific task the request is trying to affect. This could be requesting e.g. a list of users as well as submitting changes. The controller itself should at best only handle logic, which is specific to a http request, like reading params or headers or stuff like that and use functions of your context modules to handle the actual business logic. It’s like a translation from http request to function call of context modules. A good comparison would be a CLI controller, which translates argv input into actual function calls.

The second part of the controller is to respond to the request with data formatted in json/html/…. So the returned values of the context function calls need to be converted. This task is usually delegated to the view layer. The view layer is responsible for converting the retrieved data into the proper binary (or textual) representation for the http response. For markup languages it’s often quite strange to work with elixir code to build the markup, therefore view layers come with templating capabilities, which allow you to mix static markup with dynamic code parts. But e.g. for json data you usually don’t use templates, but you’ll prepare the structure in a native datatype and just convert it at once to a json string. Again the comparison would be a CLI controller calling into an extracted module to convert data into a table for shell output, because you don’t want each controller to implement the table formatting again.

You need to learn about MVC. Obviously there are no models in Phoenix, but that would be Schema and Context.

Most of the time You will put your code in contexts.

I wanted to write a nice post but @LostKobrakai was quicker also since you’ve never used any Full Stack framework @kokolegorille has also a good point, in that case I can recommend this page Backend Developer Roadmap: What is Backend Development Because elixir & phoenix have an awesome documentation I will go with that after you gather knowledge what exactly is an Full Stack framework and what are its main parts (MVC, REST etc…)
Keep going, everything takes some time