"Do you really need a database?"

@NobbZ’s post sums it up for me:

If it’s data you don’t mind losing in case of a system/power failure (such as temporary user settings) then there’s a good argument not to persist. But if it’s something like User account details, then I would persist.

Also, as you’re interested in application architecture I highly recommend PragDave’s online course - it’s sparked some really interesting discussions about approaches to development in Elixir.

I am reading the same book(functional-web-development-with-elixir-otp-and-phoenix) and this exactly what I am feeling like recently. Initially I was really excited because I feel like it can be a huge performance gain since there is no more back and forth between code/logic and database.

I also ask some questions regarding my specific need on elixir-lang IRC. The specific conversation can be found here beginning 4:06PM between users yial2(myself), @radar, and Zarathu. The preliminary is that GenServer process may not be suitable for my need, but I am still doing some more reading to try to find out more on my own.

Thanks!

Don’t forget, Kernel.put_in/3 is your friend when doing nested structs

(and the only reason that I’m mentioning this is that I had a hard time finding it in the docs when I needed it…)

Thanks again.

That’s actually what I started doing yesterday. With one eye on “To spawn or not to spawn” and one eye on the Functional Web Dev book I began making modules with structs to represent my contexts/units. Let’s see where this leads

I agree with you. There doesn’t really seem to be any reason to put those things into an Agent or process in-of-themselves. They could just as easily be crammed in a struct:

defmodule StrangeBrew.MaltProfile do
  defstruct name: "", base_malt: :two_row, specialty_malts: [], lovibond: 100 # etc

  def to_string(profile), do: "#{profile.name}(#{profile.lovibond}˚L)")
end

By the same token there’s not any particular reason to start out by tying them to a database. In the future, should you want to try some fancy stuff (say estimating Lovibond from the particular grains in the profile) you shouldn’t have to “contaminate” your estimation logic with a bunch of stuff related to database queries and the size of table columns.

I guess what I’m struggling with is see nice pure functions and modules for this use case.

My mind is in object ↔ Database land…

Take malt_profile. It would have a name and some attributes like colour and such. I can’t imagine that cramming stuff like this in an Agent or Process would have any benefits.

There’s no real time commutation going on. The only thing a malt would ever do is being a part of a malt_profile. And that in turn, would only be part of a recipe, which would be part of a batch.

No game dynamics. No chat. Nothing fancy (yet)

yeah. I agree. But I’m too much a noob to take all of this stuff in in one go…

I think the ‘contexts’ that Phoenix 1.3 is introducing are very much in line with the “create an interface for your app’s business domain and implement it for the persistence piece(s) you are considering.”, in that the context module is the only place where the business domain layer and the technical layer meet.

So I guess I’ll just post it here and see what happens…

Basically users have recipes
a recipe have a yest_profile, malt_profile, mash_schedule, hop_profile and adjuncts
a batch will have a recipe, brew_date and other batch spekecific data points
I’m thinking that there should be both public and private repositories for malts, yeasts and hops

I have some other features in mind, but let’s leave that out for now.

If I was to “go the Uncle Bob way” and leave persistence out of this for as long as possible, how would I do this?