aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David McLaughlin <>
Subject Redesign of the Aurora UI
Date Wed, 19 Jul 2017 05:55:46 GMT
Hey all,

At Twitter we have had a long-standing desire to be able to put custom
widgets and other UX enhancements into the Aurora UI. Recent prototype work
to do this in a clean way has proved fruitful and I'd like to present this
approach to the community and get feedback on the overall approach.

The basic approach is simple:

1) Use the node plugin for gradle to bootstrap a modern web development
build system using webpack and npm.
2) Use a modern JS view library like ReactJS (or Preact depending on the
Facebook+Patents license issues for Apache projects) to have all UI
components defined as ES6 modules.
3) Use webpack to set up a custom plugin directory that modules should be
loaded from first. This would allow anyone with custom Scheduler builds to
also drop in custom JS files to replace selected OSS UI components.
Example, you could drop a "Navigation.js" into the plugin directory, and
the build system will use that module instead whenever it sees a
<Navigation /> used by parent components. Basically: it's a hybrid
plugin/dependency injection (similar to Guice) approach to customization of
the UI.

The nice thing here is that since every single part of the application is a
module you could take your customizations to any level of precision that
you need. You could replace (or add) key pages or components, or just keep
it as simple as adding some helper text to one of the pages.

Some use cases this could enable:

* A <ConfigurationViewer /> widget that you can replace with configuration
parsing that understands special processes and/or custom executors.
* Integration with your telemetry stacks to add resource utilization
feedback or other performance indicators into the job page.
* Adding custom stats tracking widgets for internal analytics.

Some points from my prototype work:

1) Switching to npm for JS asset management allows us to delete the vast
majority of our 3rdparty assets that we had to copy into the repo. We can
most likely extend this to remove all of them, including our CSS frameworks
like Bootstrap.
2) ReactJS was proposed before (by Joshua Cohen) and ironically I was one
of the main voices against. The argument I used at the time was lack of
familiarity with the stack within the community, as well as concerns about
the complexity. So what changed? Almost the entire Aurora team at Twitter
has ReactJS experience now - from working on our internal Continuous
Delivery system. I also believe that as a view layer, ReactJS is
conceptually very simple and that most of the complexity in these modern JS
applications is in a state layer like Redux. The Aurora UI is currently
read-only and relatively simple, and we can avoid much of the complexity by
just using component state instead.
3) Unit tests are trivial to add as part of this work.
4) I'd like to move to modern, maintainable CSS tooling - SASS - as part of

My prototype is (hastily) published here:

Some highlighted changes:

1) Bootstrapping the modern UI toolchain from gradle:

2) The webpack configuration to enable loading from a plugin directory (and

3) The Hello, World of the plugin mechanism:

Is replaced by:

4) Unit test example:

My goal now is to take the prototype to completion and upstream to Aurora
OSS. If the community is in favor, we should also discuss how to handle the

I would propose two options:

* a massive code-dump with the entire UI rewritten in ReactJS.
* an incremental approach where I (for example) post one page at a time,
allowing those unfamiliar with JS to see the step by step process that can
demystify the tooling. The new UI would not be enabled incrementally due to
the issues with "greedy" one-page frameworks.. instead we'd just enable it
at the very end. The major downside here is just maintaining all the weight
of two UI frameworks, etc. in that period of development.

Please let me know any questions, concerns or feedback.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message