Boundary, Core, or Script?
Explore how to organize Phoenix LiveView code into boundary, core, and script layers. Understand using with statements for uncertain operations in the boundary and pipe operators for predictable core functions. Learn how schemas fit into core code and where to place scripts for deployment or testing tasks.
We'll cover the following...
As we add new functions, we can think about them in this way: any function
that deals with process machinery (think “input/output”) or uncertainty will
go in the boundary, or context. Functions that have certainty and support
the boundary go in the core. Scripts that support operational tasks, such as
running tests, migrations, or seeds, live outside the lib codebase altogether.
Let’s dive a little deeper.
The context API is for with
The context module is the API for a service. Now we know that the context module acts as the application’s boundary layer. Boundary layers handle uncertainty. This is why one of the responsibilities of the context is to manage the database interactions, for example—database requests can fail.
In Elixir, we can use with statements to manage code flow that contains uncertainty. The with/1 function allows us to compose a series of function calls while providing an option to execute if a given function’s return doesn’t match a corresponding expectation. Reach for with/1 when we can’t pipe our code cleanly.
So, we can think of the boundary as with-land––a place ...