The Generated Core

The generated backend code is separated into two layers, the boundary and the core. The Catalog context represents the boundary layer. It is the API through which external input can make its way into the application.

The Product schema, on the other hand, represents the application’s core. The generated migrations are also part of the core. The core is for code that is certain and predictable; —code that will always behave the same way given the same inputs. The core is responsible for managing and interacting with the database. We’ll use code in the core to create and maintain database tables and prepare database transactions and queries. Later, we’ll see how LiveView uses some of this code, through the API provided by the context, to manage product records. Before we get to that though, it’s important for us to understand how the core handles these responsibilities as well as how the context and core work together to expose an API for database interactions to the rest of the application.

Context vs Boundary

A Phoenix Context is a module in your Phoenix application that provides an API for a service or resource. It is responsible for managing uncertainty, external interfaces, and process machinery. The context implements the boundary layer of your application. In this course, we’ll refer to the context to denote such a module, and the boundary to describe the role that a context plays in your application’s architecture.

Let’s walk through the generated core code—the migration file and the Product schema. Then, we’ll take a deep dive into the Catalog context.

The Product migration

We don’t need to understand the whole user interface before we put our backend code to work, but we do need to tweak the database so it supports our new products table. Fortunately, the generator created a migration file for us to do exactly that.

Let’s look at the pento/priv/repo/migrations/20200910122000_create_product.exs migration from the files given below, that looks something like this: