Oban Web: Private Beta

Challenge accepted!

Array.from(document.querySelectorAll(".btn--destructive")).forEach((el) => el.click())

                                                    A few attempts later …

Well … good job!

It’s why I love fault-tolerant so much!

Ha !

Thanks for accepting the challenge. That was largely a test of LiveView more than anything else!

Those buttons could really use a confirmation…

One more thing about joining the beta: please include the email you would like to register with.

I made a few guesses for email requests but that didn’t work when I received DMs!

It is far too late to edit the main post, but to anybody wanting to join the beta now please go to https://oban.dev

The site has a little more info and a tiny little signup form for the beta.

This looks really nice and sure beats manually running queries.

But one question for you, and don’t take this is an attack or a challenge to defeat your ways to generate revenue, but have you thought about what would happen if someone makes an open source web UI on top of Oban?

I only bring that up because the project is so polished and it sounds like you want to go all in and work on this as much as possible and it would be great for you to be able to sustain that work by generating income but it would also suck if you put in all of that time and effort and then all of that comes crumbling down because someone else makes a web UI that’s not being charged for.

I know you’re not going to add paid features to Oban (which I think is great because that has always been something that bothered me a lot with Sidekiq). I’m mainly writing this because maybe it will spark some ideas in other ways you can generate income on top of the web UI. I know consulting is a big one.

Have you considered offering premium support? This would be beyond github issues. People could pay you X amount per month or year and that would allow them to get X amount of hours of your 1 on 1 time to help on something specific to their app. This basically becomes a safety net and you become the person to call if something goes wrong with their Oban set up. It’s sort of like consulting but it’s more of a retainer / insurance based form of it.

My family was traveling yesterday, sorry I didn’t get the chance to write back.

That doesn’t seem like an attack at all! This is certainly something I’ve thought about, and something that my wife brings up all of the time. It will always be a possibility (just like somebody replicating Oban is a possibility). There are a few plans to guard against this, some of which you touch on in your message.

That would certainly suck. I’m primarily relying on the fact that the amount of time to build a UI isn’t trivial—at least not one that has much functionality. The price of the license is still up in the air, but one of my selling points is that it costs less than you would pay an entry level dev for one week of work.

That will never stop a student or somebody who has free time from taking a stab at it though. Then again, there are plenty of gems out there that replicate part of Sidekiq Pro / Ent and that doesn’t seem to impact sales much.

That’s a great idea. Offering support is definitely something I’ve thought about. Bundling it as part of the license, or using it as a add on would be great.

Thanks for your comment. I really appreciate your time, your concern, and the thought you put into it.

Hey beta people! ObanWeb v0.6.2 is released today with a nuanced bug fix for users that are running queues on dedicated workers and no queues on their web nodes.

Changes

• Add support for explicitly disabling stats rather than inferring based on queue configuration. This prevents issues in production environments where certain nodes (i.e. web) aren’t processing any queues, but the the UI is accessed.

  ObanWeb configuration now differs from Oban configuration and you’ll need to specify it separately. Specify the repo in config.exs:

  config :my_app, ObanWeb, repo: MyApp.Repo
  

  Disable the stats tracker in the test environment:

  config :my_app, ObanWeb, stats: false
  

  Then, be sure to use the ObanWeb config in your application supervisor:

  {ObanWeb, Application.get_env(:my_app, ObanWeb)}
  

Thanks to @bgentry for identifying the issue.

This fixed our issues, thanks @sorentwo!

Oban 0.7.0 is out today with a new and long overdue feature: a details view that shows job state, timing, full arguments, errors and some control buttons. It is now possible to kill, discard, start, rerun or delete a job from the details view. The jobs table is getting an update currently and all of those actions will be available there, without having to jump into details.

Screenshots are attached and the live demo is running as always.

Changes since 0.6.2 (including some bits that were part of 0.6.3):

Additions

• Add detail modal for inspecting job arguments, errors and state timings.

Changes

• Display duration or distance in words depending on job state. This clarifies timestamp information. Relative timestamps have an formatted absolute value as the “title” attribute as well.

• Improved ordering for various job states. Many states were reversed, making the table view seem broken.

Completed:

Screenshot_2020-01-08 Oban • Jobs1440×803 120 KB

Waiting for a retry after failure:

Screenshot_2020-01-08 Oban • Jobs(1)1440×803 115 KB

I neglected to announce the release of ObanWeb v1.0 here last week. It was rolled into the Oban v1.0 announcement and didn’t get the proper “release notes” treatment.

From the CHANGELOG:

The biggest change is that this version relies on Phoenix LiveView v0.6, which itself has breaking changes. Be sure to upgrade LiveView along with ObanWeb using this guide: https://hexdocs.pm/phoenix_live_view/installation.html

Changes for V1.0.0 and v1.0.1

Fixes

• Display discarded_at time in detail timeline view
• Prevent jitter when clearing stats cache

Changes

• Upgrade to LiveView ~> 0.5 and test with 0.6.
• Upgrade Oban and set dependency to ~> 1.0.0
• Update stats and the queries that power stats to rely on more frequent
  refreshes and fewer database calls. The average refresh time dropped from
  ~310ms to ~180ms.