I’ve posted a “recipe” on enforcing unique jobs with Oban. It is the first in a series of recipe posts, and was largely drawn from the discussion in this thread. (This is also linked in the monster “Blog Posts” thread)
sorentwo
Oban Core Team
sorentwo
Oban Core Team
Personally, no, I’m trying to avoid heavy JS where possible.
The current live view powered UI works wonderfully and I’m really pleased to be writing Elixir for everything. The remaining blockers are:
- Some ugly bugs (literally)
- A few missing core features
- Install and usage documentation
- The dependency on phoenix_live_view means I can’t release it on Hex
8
wolfiton
wolfiton
Also can oban be used for email marketing self solution as a newsletter sender?
Thanks in advanced
0
sorentwo
Oban Core Team
Not exactly. The writing effort is around integration, a changelog, subtleties of behavior, and establishing a roadmap. The process of explaining those things to somebody (or multiple somebodies) would be equivalent to writing the docs 
Certainly. It’s up to you how you make use of it!
2
wolfiton
dch
awesome! Is there (in the code) a pretty hard dependency on PG? I have a use case for a similar front end but with a distributed DB, I’d be interested in extending it at some point.
1
sorentwo
Oban Core Team
Yes, there are a number of hard dependencies on PG features. A few off the top of my head:
- Pub sub through pg_notify
- Software advisory locks
- Use of
SKIP LOCKED - Partial indexes
There are probably others that I’m missing, but those are fundamental enough to how Oban operates that I can’t foresee porting it.
Dropping Ecto as a requirement or writing a port in another language is more likely that working with a different database.
2