Article technique non traduit en français.

(p)repair is a project to help people reduce their consumption of products. Firstly, we bet on building a mobile application. You can read more in the project’s manifesto.

This article is part of the Migration to Ash series. Click for the summary, or just pick what you want here!

For more context, read our previous article: Why Ash?

After we decided to migrate our project, there are a lot of things to modify in our code. Putting our app development code in a broken state for an unknown amount of time is really unpleasant. No one likes to see red lines all the day on the terminal.

We decided to create our Ash Resources in parallel of our Ecto Schemas. It works fine, and it allows you to migrate step by step.

Our overall strategy for now consists to:

Generalities

  • install and configure Ash for our project

Add “legacy_contexts” and “ash_domains” folders

  • create a legacy_contexts folder and put inside all the Phoenix Context files + the subfolders containing all the Ecto Schemas
  • create an ash_domains folder which for now is empty but will receive all the Ash Domains and Ash Resources

Migrate Ecto Schemas into Ash Resources

  • create new files for Ash Resources and Ash Domains
    • each Ecto Schema will be doubled with an Ash Resource (need a data layer, plus attributes, relationships and identities sections only)
    • each Phoenix Context will doubled with an Ash Domain (need a resources section only)
    • we keep our Ecto Schemas because they are used inside our Phoenix Context functions
    • we keep our Phoenix Context functions because they are still used throughout the app: in Controllers, Liveviews, Tests…
  • generate the ash migration file with mix ash.codegen <name_of_the_migration_file>
  • update the ash autogenerated migration file to fit our already existing database
  • run our first migration under ash framework with mix ash.migrate

Migrate the Phoenix Context functions into Ash Resource Actions

  • create code_interface and actions section into each Ash Resource (code_interface can be created in Ash Domains instead or also)
    • populating these sections with actions to trace functions located in Phoenix Contexts
  • if needed, create other sections such as agregates and calculations
  • test these functions
    • migrate the Phoenix Context fixtures
    • migrate the Phoenix Context tests

Migrate the Phoenix generated Auth into AshAuthentication extension

Declare Authorization policies through Ash

Migrate the web part

  • migrate the API controllers, using AshJsonApi
  • migrate the Phoenix Liveviews, using AshPhoenix

Read our next article: Generalities on the migration to Ash

Guillaume, from the (p)repair team