[Enhancement] WebUI

[j-mcnally]

Would be nice to have an admin panel similar to sidekiq where you can see running tasks / workers etc.

We could develop it as a plug so it can be added to Phoenix and other frameworks using Plug.

[akira]

👍 this would be great to have. Would be preferable to structure it so Phoenix is not a dependency unless you use the UI - so not sure if this would mean a separate repo etc...

[j-mcnally]

Yea, i dont think we need a dependency on Phoenix but i think a dependency on plug is reasonable, most web servers use it.

[j-mcnally]

ok so ive got a basic plug module working that will run our webui and is mountable under phoenix, will also look into running it standalone. We maintain no dependency on Phoenix only plug.

Checkout https://github.com/structtv/exq/tree/webui for progress.

https://github.com/structtv/exq/blob/webui/web/router.ex

which is a plug that can be used with any server supporting plug. i think its sort of like elixir's rack.

It can be injected into phoenix's router like this

defmodule ExqUi.Router do
  use Phoenix.Router


  pipeline :before do
    plug :super
    plug Exq.RouterPlug, namespace: "exq"
  end


  scope "/" do
    # Use the default browser stack.
    pipe_through :browser
    get "/", ExqUi.PageController, :index, as: :pages
  end

  # Other scopes may use custom stacks.
  # scope "/api" do
  #   pipe_through :api
  # end
end

[j-mcnally]

It is alive!!!!

[j-mcnally]

Created a mix task for starting the webui independent of an existing server.

Standalone web server uses the plug and cowboy, connection details to redis are passed at the command line.

defmodule Mix.Tasks.Exq.Ui do
  use Mix.Task

  @shortdoc "Starts the Exq UI Server"

  def run(args) do


    {opts, args, _} = OptionParser.parse args,
      switches: [host: :string, port: :integer, namespace: :string, queues: :string, webport: :integer]

    webport = Keyword.get(opts, :webport, 4040)

    Exq.start(opts) 
    IO.puts "Started ExqUI on Port #{webport}"
    Plug.Adapters.Cowboy.http Exq.RouterPlug, [namespace: ""], port: webport

    :timer.sleep(:infinity)
  end

end

ran as

mix exq.ui --namespace structtv --webport 7898

Where the redis namespace is structtv and the webui would run on port 7898.

Supports redis port and hostname via

mix exq.ui --namespace structtv --host 555.555.555.555 --port 5943

also

[akira]

Nice! 👍 for client JS client / API approach. I noticed some coffeescript, what is the approach compile assets?

I was having issues running due to the 'static' symlink, but I'm assuming I was missing the build step.

[j-mcnally]

Hey Alex,

Yes you will need to install ember-cli and inside the priv/ember folder run
ember build i think before a release we would included the compiled code,
thats just me being lazy, ill also commit the built files incase you dont
want to dick with ember cli.

See: http://www.ember-cli.com/

On Sat, Oct 25, 2014 at 2:04 PM, Alex Kira notifications@github.com wrote:

Nice! [image: 👍] for client JS client / API approach. I noticed some
coffeescript, what is the approach compile assets?

I was having issues running due to the 'static' symlink, but I'm assuming
I was missing the build step.

—
Reply to this email directly or view it on GitHub
#7 (comment).

[j-mcnally]

I've included the built files on my branch.

[j-mcnally]

This has me thinking that prior to a release of this we should probably do a seperate repo for exq-ui which would be the source ember project, and the just include the build as the priv/static. I want to keep the ui source open of course, but we probably dont need to bundle the enitre ember project as part of exq and it can be somewhere else, and just ship the build/dist with exq.

[akira]

I haven't used ember previously (only angular / react). Is the compilation step required only for coffeescript, or is there things it is needed for? Just thinking, does switching to JS eliminate the build step?

[j-mcnally]

All of the templates and es6 modules require compilation

Sent from my iPhone

On Oct 25, 2014, at 5:38 PM, Alex Kira notifications@github.com wrote:

I haven't used ember previously (only angular / react). Is the compilation
step required only for coffeescript, or is there things it is needed for?
Just thinking, does switching to JS eliminate the build step?

—
Reply to this email directly or view it on GitHub
#7 (comment).

[j-mcnally]

Ember cli also provides the sass compilation.

Sent from my iPhone

On Oct 25, 2014, at 5:38 PM, Alex Kira notifications@github.com wrote:

I haven't used ember previously (only angular / react). Is the compilation
step required only for coffeescript, or is there things it is needed for?
Just thinking, does switching to JS eliminate the build step?

—
Reply to this email directly or view it on GitHub
#7 (comment).

[akira]

A bit torn on this - on one hand it's not the best practice to check in compiled artifacts to a repo. However, it's also not that great to require all the additional dependencies just to run the UI, especially since it's just an admin interface. In an ideal world it would be great to have a solution where we can minimize asset build dependencies and just have the same code base to be able to edit and run.

However, given the two choices above, I can see going with checking in the compiled assets to the exq code base like you mentioned, and having a separate code base to generate them - this would lean towards it being easier to use by the end users versus it being easier to develop. We can go with that for now.

[j-mcnally]

Got a graphing library installed gonna hook up to live data next: What do you think, obviously still needs some customization.

[j-mcnally]

Queues view

[akira]

👏 That looks awesome!

[j-mcnally]

Added some process info stuff. Lets regroup on it when we're done with the PR because i think it could be tidied up to be closer to sidekiq, will want your input.

[akira]

Sure, let me know where to look at it. Also, not sure how to build the ui with ember-cli or where the assets go, let me know if I need to do that to get it running.

[j-mcnally]

i can jump on a google hangout tomorrow if u want me to walk you through the ember stuff.

[akira]

Cool, google hangout could be helpful, not sure about exact timing though. I can message you about timing tomorrow when I find out more.

[j-mcnally]

Sounds good, will be fun to talk face to face :)

On Wed, Oct 29, 2014 at 12:14 AM, Alex Kira notifications@github.com
wrote:

Cool, google hangout could be helpful, not sure about exact timing though.
I can message you about timing tomorrow when I find out more.

—
Reply to this email directly or view it on GitHub
#7 (comment).

[akira]

Not sure if I can tonight, if I can will be late.

On Tuesday, October 28, 2014, Justin McNally notifications@github.com
wrote:

Added some process info stuff. Lets regroup on it when we're done with the
PR because i think it could be tidied up to be closer to sidekiq, will want
your input.

[image: screen shot 2014-10-28 at 3 26 16 am]
https://cloud.githubusercontent.com/assets/892382/4805394/44fc8fbe-5e7c-11e4-9f3d-7a1659806b46.png

—
Reply to this email directly or view it on GitHub
#7 (comment).

[j-mcnally]

Added ability to view failures.

[j-mcnally]

I think for now, im going to remove scheduled / retries, finish a few of the crud related actions in queues/workers/failures, and we can ship. Also need to hook up graphs.

I think i can finish this tomorrow.

We can ammend retries / scheduled tasks once the backend starts to support that type of stuff.

[akira]

👍 for that and shipping

[j-mcnally]

Closing this for now in favor of smaller enhancement issues / requests.