Kue: split express app from library

[defunctzombie]

This would allow iteration on the web UI frontend without bumping the version numbers of the library. This is useful if the library is remaining static but web UI changes are happening. Allows users to avoid constantly thinking they need to upgrade their use of the kue library.

[behrad]

Good rationale behind this one, we had already talked on separating these and I was against it. you can search related issue...
this time I can rethink this... I'd like others to drop in comments

[juanpaco]

I'm also for the separation for the reasons mentioned above and in the previous issue. To them I'd at that then users of other app stacks (koa, hapi, whatever) could also use their preferred module at that level.

It would also be nice if the UI could return an Express 4 router object, so that we could mount it into an existing app at some point of our choosing rather have to spin up another listener. That might be a separate issue though.

[okor]

I have mixed feelings about breaking the UI out of kue core. Separating the two would require a bit more work to keep in sync and introduces some additional complexity, for both maintaining kue and setting up kue in your app. I do understand the motivation but I'm not sure bumping the version is such a bad thing. Are there any good reasons to not bump the version? I vote for simplicity which I think is particularly important for open source projects, we humans are fickle and if we struggle for even a short time to set up the UI we may jump to a different project/solution which fragments similar efforts in the open source community thus subtracting from the projects total awesomeness potential.

I do however want to give a massive :+1: to returning an Express router object for custom mount points. This is particularly helpful in the scenario where you have implemented some kind of authentication. I am building something right now where this would be very helpful.

[juanpaco]

@okor I think your human point is a very valid one. I wrote a little library that separates the core functionality from the Express 4 integration. If you have time, you can look at it. It depends on letter-opener. My intent with it was that if you're using an Express 4 app, you would just use the -express version, but otherwise you could use the core in whatever you want. Thus far, I'm the only confirmed client of either, but as a possibly meaningless data point, setting up the UI was pretty easy using just the -express version. I'm curious, your time allowing of course, what you think of a setup like that. Does it at all address the concern that you raise?

I hadn't even considered the authentication angle you brought up. Yeah, that's a big selling point, IMO. In my head being able to do that simplifies using the kue interface in a production environment.

[lykmapipo]

+1. For ui separation from the library

[lykmapipo]

@behrad

We can have something like:

• kue as a core library which provide all core functionalities
• kue-http / kue-rest as a rest interface for the core kue and which depends on core kue
• kue-ui as a layer on top of kue-http and kue core to provide richer ui which depends on kue-http and kue core

[behrad]

@lykmapipo this segmentation is completely rational by design and modularity of the whole thing of Kue, however Why should somebody bother to install 3 (or even 2) separate modules to achieve a single cohesive functionality? What do we gain in-real !?

[okor]

I think developers tend to get a little OCD about separation of concerns (me included). In this case I don't think that breaking up the app would be that helpful. If it was broken up, I think that kue and kue-ui would be the highest number of partitions I would use. kue would contain kue (core), kue-http and kue-rest apis. kue-ui might be helpful to separate but it's not really necessary in order to use a different interface - as an api already exists.

I do however still feel like the typical use case would benefit from a custom mount point so that we could easily put kue behind the application authentication.

just my $0.02

[defunctzombie]

Just gonna add in that the reason I prefer the split (over what I have
already said) is that the places where I use kue (library) are not where I
mount or use any UI. To me the UI is a totally separate service (you could
even provide a bin file to launch a basic ui). I personally draw no value
from mounting it into an app versus just being able to deploy a standalone
UI.

On Monday, April 13, 2015, Jason Ormand [email protected] wrote:

I think developers tend to get a little OCD about separation of concerns
(me included). In this case I don't think that breaking up the app would be
that helpful. If it was broken up, I think that kue and kue-ui would be the
highest number of partitions I would use. kue would contain kue (core),
kue-http and kue-rest apis. kue-ui might be helpful to separate but it's
not really necessary in order to use a different interface - as an api
already exists.

I do however still feel like the typical use case would benefit from a
custom mount point so that we could easily put kue behind the application
authentication.

just my $0.02

—
Reply to this email directly or view it on GitHub
https://github.com/Automattic/kue/issues/543#issuecomment-92457408.

[okor]

@defunctzombie I could see the benefit for your use case. Perhaps a configuration option for the kue ui would be sufficient? Just trying to ideate on the simplest option.

[lykmapipo]

@behrad
You are right, it does not look ok if you want to achieve the cohesive functionality after separating kue into modules.

But if we favor modularity in kue:

• Core codebase will be minimal and we will be able attain stabiltiy in kue core
• New features will be easy to plugin into kue, as we see now there good number of projects depends on kue
• Will allow framework independent UI Layer and Rest Layer
• Will help to avoid false version change as pointed by @defunctzombie

For the single cohesive functionality we can bundle kue core with any of the well supported kue-rest and kue-ui.

[dmitry]

It would be nice to have a modular application on core, rest and ui. In this case each module should have the integration tests.

[behrad]

We can start to clarify this and plan it for Kue 1.0, any helps and PRs are more than welcome ;)

[lykmapipo]

@behrad

+

[lykmapipo]

Hey @behrad

Give me a light here. Should we create kue organization and have

• kue-core
• kue-rest
• etc
  In it or should we have just branches for the refactor?.

I will appreciate your inputs.

[behrad]

We can split current module into core and rest separate modules as you said @lykmapipo

[lykmapipo]

@behrad

Got it.