This is the place that James and I always came back to throughout this book. “Let’s see how far we can get without persistence.”
We found that thinking about the solution in these terms shaped the way we thought about the problem.
redrapids
Author of Adopting Elixir
venomnert
@redrapids and @JEG2 are there more sample repos that you can share with the community to get a better grasp of the concept taught in the book. I love to see the principles applied from multiple angles.
1
JEG2
Author of Designing Elixir Systems with OTP
The following is an early example of me playing with deferred persistence:
1
redrapids
Author of Adopting Elixir
I would say the ideas are more common in Haskell and other functional languages. The idea of supporting a full functional core and handling boundary concerns with callbacks is a popular one in other languages, but not as much in Elixir.
I do see that James hooked you up. I think that he did a talk or a training several years back. Also, Brooklyn Zelenka has a bunch of talks about this general idea. It’s not exactly about this concept, but she gave a talk at CodeBeam SF that was out of this world, and you should look at how she shaped the core code and used her witchcratt library to wrap it.
Sorry I can’t do better. It’s really a good question.
-bt
0
finkef
First of all, big thanks to @JEG2 and @redrapids for the awesome book. Loved it!
I’m also struggling with the question of when, where and how to introduce persistence.
Especially when working with a rather simple and traditional CRUD model, like users for example (sorry for bringing this example back up), where there may only be simple persistence and query-related operations, the functional core (if any) would probably end up being very slim and all logic would end up in the boundary layer.
In this particular case, I would intuitively use an Ecto schema to model the data, but I feel like that defeats the purpose of “Do Fun Things” and might even introduce a lot of cross-context shenanigans especially if the data is of rather relational nature.
My question is, how would we build a functional core if most use-cases depend on persistence, simple CRUD and query operations? (I think this also works for the ecommerce example.)
1
JEG2
Author of Designing Elixir Systems with OTP
I’ll make a few general comments:
- If a traditional CRUD design is meeting your needs, it doesn’t sound like you have any problems that need solving
- However, I don’t think of users—the most likely “god object” in any system—as simple
- And I suspect you can learn something by trying experiments where you add persistence as you would any other feature (because I definitely have every time I’ve done so)
But yeah, don’t overthink it. If you don’t have a problem, there’s no reason to change your design. (Except to run experiments to learn new things!)
3