Introducing Persistence

How our projects work

Congratulations on making it through all the layers in a single OTP project, from data to workers. In this chapter, we’re going to focus on putting these layers into context. We’ll help you answer the core question:

How do our projects work with others, whether they are external dependencies or projects we build?

This overarching question has two underlying concerns.

Interacting with dependencies

The first concern is how components interact with dependencies, particularly in more complex interfaces. The questions this concern opens up are serious:

• How might we implement persistence?

• How do our layers relate to user interfaces?

• Generally, how do our components connect to the rest of the world without coupling too tightly?

Consider persistence. Suppose we rush into designing a new project by going straight to a database schema and wiring that schema directly to database functions. In that case, we’ll be running to the boundary layer before building a core. We’ll miss an opportunity to explore a true functional core free from boundary concerns of heavy side effects and process machinery. For example, business problems often demand state machines, and those types of projects benefit tremendously from delaying the persistence implementation until the transitions of the state machine are fully settled.

Fitting into existing frameworks

The second concern is how components fit into existing frameworks. The questions in this area are weighty:

• Do worker-bees play nicely with emerging frameworks like LiveView or Scenic?

• How do these components play with Phoenix Channels?

---