Idea: Use gen server to avoid round-trip to database about guardian_db HOT 9 CLOSED

@doomspork Yes exactly. My idea was to have a gen server in front of the DB as a cache layer, and then only save to the database once in a while. This would enable the users to still be able to invalidate tokens without the cost of doing a db lookup every time

from guardian_db.

This is based on #129 & #131, an adapter that merges both together for a DB-cache combo.

This is untested

defmodule Guardian.DB.CachedEctoAdapter do
  @moduledoc """
  An experimental Adapter that leverages both Ecto and ETS for a cached backed
  storage lookup.
  """

  @behaviour Guardian.DB.Adapter

  alias Guardian.DB.{EctoAdapter, ETSAdapter, Token}

  @impl true
  def insert(changeset, opts) do
    with {:ok, token} <- EctoAdapter.insert(changeset, opts),
         {:ok, _} <- ETSAdapter.insert(token, opts) do
      {:ok, token}
    end
  end

  @doc """
  Attempt to fetch our token from our ETS cache first, if that fails look up 
  in the database and store the retrieved token in the cache
  """
  @impl true
  def one(claims, opts) do
    with nil <- ETSAdapter.one(claims, opts),
         %Token{} = token <- EctoAdapter.one(claims, opts),
         {:ok, _} <- ETSAdapter.insert(token, opts) do
      token
    else
      _ -> nil
    end
  end

  @impl true
  def delete(token, opts) do
    ETSAdapter.delete(token, opts)
    EctoAdapter.delete(token, opts)
  end

  @impl true
  def delete_by_sub(sub, opts) do
    ETSAdapter.delete_by_sub(sub, opts)
    EctoAdapter.delete(sub, opts)
  end

  @impl true
  def purge_expired_tokens(exp, opts) do
    ETSAdapter.purge_expired_tokens(exp, opts)
    EctoAdapter.purge_expired_tokens(exp, opts)
  end
end

from guardian_db.

Awesome! I am going to be leveraging GuardianDB in a project at work and will keep an eye on the number of queries and how to reduce them (something I've been trying to been doing with our legacy systems already).

from guardian_db.

really nice idea with GenServer, I did this but with Redis, maybe this will help someone https://github.com/alexfilatov/guardian_db_redis (also maybe make this as a PR #119)

from guardian_db.

I was thinking about the issue #119 and concepting the idea of an Adapter for the DB layer. As we can improve the access to database, with good indexes to reduce the reading strategy, we can make the GenServer became real and load all tokens at startup.

from guardian_db.

@Hanspagh could you add some description to it? Otherwise in the PR would be good as well.

from guardian_db.

@Hanspagh are you thinking we leverage a GenServer as a sort of cache to avoid having to go to the DB for every check?

from guardian_db.

With the new Adapter pattern @alexfilatov put together this is now possible with a custom adapter that wraps a cache around ecto. After we work through #129 I'll take a look at tossing together a ETS Adapter and a CachedEcto adapter.

from guardian_db.

Lets move the conversation over #131

The Adapter is already there with the Ecto implementation by default

from guardian_db.