Using Pow without Ecto or an RDBMS

Haven’t looked into most of Pow’s guts but I’d guess it’s not tightly related to a RDBMS; only to Ecto.

So if you find – or invent – a way to access those files through an Ecto interface then I’d expect Pow to work just fine after.

I suspect that you’re right, but I’d like to avoid adding Ecto to the project at the moment.

Maybe @danschultzer will correct me but I’m not seeing such a tightly bound to Ecto project to invest in an arbitrary storage mechanism without a standardised API.

Out of curiosity, what’s the problem in including Ecto in your project?

@dimitarvp is right, there’s no tight coupling so you should be able to get Pow working without Ecto or a DB. There are several ways to do it, but I would just set up a custom context and user module.

This is also how I unit test Pow so I’m not relying on Ecto/DB. The user module is necessary because it’s used to generate a changeset for the form, and to fetch the user id field dynamically for the form. Depending how your app works, you could also use the the user module to load the password from the TOML file on compile.

config :my_app, :pow,
  user: MyApp.Users.User,
  users_context: MyApp.Users

defmodule MyApp.Users.User do
  defstruct email: nil, password_hash: nil

  use Pow.Ecto.Schema

  def changeset(user, _params), do: user

  def verify_password(user, password), do: # Verify password here
end

defmodule MyApp.Users do
  use Pow.Ecto.Context

  def authenticate(_params), do: # Use params to look up user and verify password with `MyApp.Users.User.verify_password/2`

  def create(_params), do: {:error, :not_implemented}

  def update(_user, _params), do: {:error, :not_implemented}

  def delete(_user), do: {:error, :not_implemented}

  def get_by(_clauses), do: {:error, :not_implemented}
end

I imagine that since you use TOML files there will be no user create/update/delete, but only authentication. In that case, you should ensure that there is only the session controller. You can take a look at the context callbacks for specs.

You are the first person I’ve heard from that wants to use Pow in this way. I built Pow so it’s easy to decouple any group of modules (Ecto, Phoenix, Plug), but I would love to hear how it works in practice and if there’s something that can be improved. Please don’t hesitate to open any issues or PR on github

Thanks to @dimitarvp for his feedback and for bringing @danschultzer into the conversation. Many thanks to Dan for creating Pow and supporting it in such a helpful manner.

It may be useful to explain a bit about why I’m trying to stay away from Ecto, if only because I may be confused about some of its characteristics. Here goes…

I imagine that since you use TOML files there will be no user create/update/delete, but only authentication.

My project is a bit like a wiki, so it uses persistent data in a read-mostly manner. It uses a tree of TOML files (with Markdown inclusions) for data storage and loads the data into Actors for use.

Authentication would let me (safely) provide persistent session history, user preferences and profiles, etc. I’m thinking about adding Neo4j or another backend service to support structured searching, but I don’t expect to need an RDBMS.

The project uses an umbrella app, in a variation on the approach suggested by Dave Thomas in his Coding Gnome course. The Phoenix app only handles web interaction. Other apps act as libraries and/or components (e.g., data sources).

My impression is that Ecto is closely coupled to the Phoenix app (e.g., by changesets). I’d rather avoid this kind of coupling as much as possible, keeping most of the “business logic” in the other apps.

I’m not using either changesets or contexts at the moment. Is it reasonable to assume that I won’t have to use them pervasively in order to use Pow? Any other comments or suggestions?

Yeah, my reply above should give you the building blocks so you can prevent using changesets at all with Pow.

Edit: One caveat is that you should generate the templates so you can remove the @changeset.data.__struct__.pow_user_id_field() call. I don’t think there’s any other places with expections for ecto changeset.

There were intentional efforts to keep them loosely coupled. The only coupling I’m aware of are 3 protocols that the phoenix_ecto package implements for Ecto (see Phoenix/Ecto — Phoenix/Ecto v4.7.0) though you could implement those same protocols for your own data structures.

You probably already know this but Changesets by themselves are not at all bound to any storage mechanism. You can use them just for your convenience. Ecto’s validation stack brings a lot of value even if you never persist the data.

(Ab)using Ecto as Elixir data casting and validation library | AmberBit Sp. z o. o.

As far as I can see using Changesets couples you to Ecto.Schema for describing any data that you care to validate (aside: as of 3.0 adapters, sandboxes and migrations are only included in ecto_sql, not ecto).

A decoupled way of using Schema/Changeset inside the web portion of the Phoenix app (just for validation) would require Schema/Changeset ↔ “domain types” conversion logic in the web portion in order to keep ecto out of the business logic.

Whether or not that is a worthwhile effort depends entirely on the application.

If the actual changeset (rather than validation) capability isn’t needed then using something like Vex and converting directly to-and-from the domain types may be the preferred option.

Quick update: I just released 1.0.8 today where there is no longer an expectation that @changeset is an Ecto.Changeset struct. This should make it easier for you to use Pow without Ecto