In Phoenix, contexts provide the interface to your data layer. They are used to read and write data to your database, but the context model can also be used to talk to external APIs or resources that don’t come from a database.
In a datbase-backed application, schemas describe the resources in your database. For a blog, your might have an Article schema to store the articles, and a Comment schema to store comments users post to your articles. Your schemas are used to model the data for both of these, encoding them to be stored in the database, decoding data from the database, and validating data to make sure it’s fit to be stored.
A context is tasked with communicating with the repository. Our blog can have a Publications context to handle dealing with articles and their comments. To create a new article, the context knows to create a new Article struct, and use the Article.changeset/2 function to convert the passed attributes to an article, which is can then pass to the repo via Repo.insert/1.
To add a new comment to an article, it knows how to find the correct article, create a comment, and add it. It might also increase a comment counter which is cached on the article row in the database, for example.
Coming from a traditional MVC framework like Ruby on Rails, contexts may seem like an extra layer to worry about. Other frameworks use a model layer, which essentially does the work of a schema and a context by handling both validations and database commnunication.
This makes database communication, which is an implementation detail, leak into the rest of the codebase. To add a comment to an article, the controller now needs to find the article to add the comment.