The Generated Boundary
Explore how Phoenix contexts define the boundary between your application's core and external services. Understand the role of contexts in managing uncertainty with changesets, abstracting tedious Ecto operations, and providing a unified API for CRUD tasks. This lesson helps you effectively use generated contexts to interact with databases, handle errors, and seed data in Phoenix LiveView projects.
We’ve spent a little time in the functional core, and we’ve seen that our schema and changeset code is predictable and certain—it behaves the same way given the same inputs, every time. In this lesson, we’ll shift away from the core and into the places where the uncertain world intrudes on our beautiful assumptions. We’ve come to the Phoenix context.
Phoenix Context
Contexts represent the boundary for an application. As with all boundaries, it defines the point where our single purpose code meets the world outside. That means contexts are APIs responsible for taking unsanitized, unvalidated data and transforming it to work within the core, or rejecting it before it reaches the core.
The boundary code isn’t just an API layer. It’s the place we try to hold all uncertainty. Our context has at least the following responsibilities:
-
Access External Services: The context allows a single point of access for external services.
-
Abstract Away Tedious Details: The context abstracts away tedious, inconvenient concepts.
-
Handle uncertainty: The context handles uncertainty, often by using result tuples.
-
Present a single, common API: The context provides a single access point for a family of services.
Based on what you’re doing in your code, the boundary may have other responsibilities as well. Boundaries might handle process machinery. They might also transform correct outputs to work as inputs to other services. Our generated Phoenix context doesn’t have those issues, though. Let’s dig a little deeper into the context we’ve ...