miguelcoba
Oban on phoenix apps with scope contexts
Hi there, I would like to know your thoughts about how to use Oban workers in a Phoenix app with Scopes.
When using scopes the context functions receive as first parameter the scope, f.e.
# lib/my_app/blog.ex
def list_posts(%Scope{} = scope) do
Repo.all(from post in Post, where: post.user_id == ^scope.user.id)
end
If I needed to use the list_posts inside a worker, I’ll need somehow to build a scope in order to use those scoped functions:
defmodule MyApp.MyWorker do
use Oban.Worker
@impl Oban.Worker
def perform(%Oban.Job{args: %{"id" => id}}) do
scope = # ? how to get the scope at the time the worker runs
list = Blog.list_posts(scope)
# Do something with list
:ok
end
end
Option 1.
Pass the scope (or enought data to rebuild the scope) as params to `Worker.new()`
%{user_id: scope.user.id, other: "data"}
|> MyApp.Worker.new()
|> Oban.insert()
and in the worker use user_id to build a `scope` and continue from that.
Option 2.
Add additional heads in the Context that don’t require scope and are only used by trusted callers (in this case Oban)
# lib/my_app/blog.ex
# additional function head that does not use scope
def list_posts(user_id) do
Repo.all(from post in Post, where: post.user_id == ^user_id)
end
defmodule MyApp.MyWorker do
use Oban.Worker
@impl Oban.Worker
def perform(%Oban.Job{args: %{"id" => user_id}}) do
# use the non-scoped functions
list = Blog.list_posts(user_id)
# Do something with list
:ok
end
end
None of the options is optimal, but from those two, the option 2 is the worst as it totally breaks the idea of scopes in the context modules by allowing anyone to bypass the scoped functions and use the non-scoped ones.
So I’m leaning on passing enough info to the worker params and use that to build a scope inside it and then use it to do whatever thing the worker needs to do using the scoped context functions.
Is there another way?
Do you have suggestions/ideas/experience implementing something like this?
Thanks in advance,
Miguel Cobá
Most Liked
tfwright
My point was that this is all just business logic, so yeah. There is no “idea of scopes” that can be violated in this way. Usually validating at the edges is fine but depending on the specific requirements of the app/business it might not be. Even if you need to care about permission changes (it might even be the case roles/access are immutable!), it can also go the other way, that you need to respect what they were at the time of the request, or it might be necessary to raise a more specific error, etc etc. Checking on mount in a LV may very well be acceptable or exactly what’s required. I don’t think there is any general rule for any of this, and so there is no utility that Phoenix can/does provide that you can use to ensure you are using scopes “the correct way,” it’s just a nudge to start with a basic pattern in place.
pjode
I think it depends on the type of worker. If the job being run is a deferred action a user is making that should be run in the scope of a user, putting the data necessary to reconstruct a user scope in the job is the right choice IMO. If the job is something that executes in a more privileged way, I actually define a new scope for that. For example, I have a scope defined for ingest and use that in function heads instead of a user scope. So you could imagine something like
defmodule MyApp.Accounts do
def create_user(%Accounts.Scope{admin: true} = scope, attrs) do
# ...
end
def create_user(%Ingest.Scope{} = scope, attrs) do
# ...
end
end
and again you’d store what you need in the job to construct such a scope. This way functions still expect some form of scope regardless.
miguelcoba
Interesting. I was trying to follow the docs and use the scope to harden/validate access to data. I didn’t even consider to break that “contract” as it seemed to me like diverging of the “good practices”. Maybe I should relax my view and view unscoped functions that are called from places where validation has already happened and it is safe to do so, is ok.
Yeah, maybe I’m reading too much and assigning too much weight to them and that introduces unflexibility
I’ll take a good thinking on this.
Thank you!
Last Post!
miguelcoba
That’s interesting. I like that it can be used for auditing/logging purposes.
Unfortunately the “real” scope data that spawned the oban job is being used in the context scoped functions to scope the data accessed/modified by the function to the tenant/organization represented by the info stored in the scope. Because of that, even if the “myworker” was a good improvement to track who actually did something, I still need to pass the scope data (for example an organization id, and a user id) in order for the worker to affect only the data that belongs to that organization or user.
That said, this is definitely something that can be used to improve code quality by tracking the worker that did something.
Thanks!
Trending in Questions
Other Trending Topics
Latest Oban Threads
Latest on Elixir Forum
Sponsor Spotlight
Producing high quality Elixir screencasts since 2017.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #elixirconf-us
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"