search

rabbitmq / rabbitmq-server

Open source RabbitMQ: core server and tier 1 (built-in) plugins
https://www.rabbitmq.com/
Other
11.97k stars 3.9k forks source link

Migrate UI to a modern framework #2619

Open michaelklishin opened 8 years ago

michaelklishin commented 8 years ago

It's 2016 and we use a library that is decent but isn't well known or actively maintained. We should consider moving to React (my personal candidate, feel free to suggest yours) and Bootstrap 3. Note that we should try to keep the themes plugin functional.

essen commented 8 years ago

I always got the impression that React was a good lib if you're a large company (in amounts of developers) like Facebook, and not very useful for small projects.

My web designer friend looks to be of the same opinion. He points me to this link https://medium.com/@ericclemmons/javascript-fatigue-48d4011b6fc4#.w9fb0smnj and suggests looking at VueJS instead (http://vuejs.org/).

My personal opinion is that it's probably too early to worry about this. From what I understand Sammy just needs first to be updated, and then might require a few small patches to keep it working on new versions, but nothing big. Considering how fast the JS world moves, we should try to seek stability. Also very interesting standards like Web components need a couple more years to mature and become more widely available natively. The shadow DOM also made its way in standards, I believe it came from React initially.

On these kind of things I'd be more than happy to play the wait game.

michaelklishin commented 8 years ago

This is not about the short term. I've been watching Sammy development for the last 6 months and it is stale. Issues and pull requests are ignored. We can use VueJS if it is maintained but the problem is, it is probably about as well known as Sammy.

React is well known and I know folks who use it in medium to small projects, and find it worth using.

williamsjj commented 8 years ago

Is the current framework actively hampering adding new features to the management UI?

Refactoring the entire UI to wire in a new framework, especially one as architecturally different as React, seems to invite a bundle of bugs for code that already is largely defect free and with no perceptible experience or feature improvements for users.

PolCPP commented 8 years ago

"Web designer friend" here ;)

Mentioned vue to essen because you can start smaller and use the extra tooling as you grow the project, but considering it's a 'young' library, and we're talking here about a long term effort i wouldn't go for it to avoid another 'Sammy'.

The issue i see with React is how fast it's moving + that we're not only talking about react alone since you'll probably end needing a few more extra libraries, adding extra 'points of failure'. So maybe it would be a good idea to just look for something more monolithic in that aspect.

michaelklishin commented 8 years ago

@williamsjj Sammy works OK but it is effectively unmaintained. I'm not looking to move to a new framework because "it is cooler". We just want to reinvent fewer wheels, make things easier to maintain and contribute to. Having a dependency that is not widely known and is largely unmaintained doesn't tick any of those marks.

michaelklishin commented 8 years ago

I take my words about Vue's popularity back: it seems to be more than 1 order of magnitude more popular than Sammy. Not that we're having a popularity contest.

williamsjj commented 8 years ago

@michaelklishin Hm. I guess if there was a backlog of UI features that Sammy was holding up, or it was contributing to a buggy experience I would agree.

However, in my experience any time you change a framework, you trade bullet-proofed debugged code you built on the last framework, for bug-ridden versions of the same code that have to be debugged all over again just to get you back to the level of stability you started with. Debugged, burned-in lines of code are worth their weight in platinum.

essen commented 8 years ago

I agree there, plus Sammy is a pretty small library with a tiny learning curve. It took me a few minutes to figure things out to fix a bug today. And even if it's unmaintained, it's pretty easy to fork and fix the issues RabbitMQ will encounter in the future. The same won't be true when Facebook drops React.

You mention making it easier to contribute to, which doesn't favor React. It's a well known fact that React has a very steep learning curve, at least when you start a project from scratch.

Anyway, just my 2 cents. :-)

Gsantomaggio commented 8 years ago

I'd use boostrap 3 for the layout.

About react the only problem I see it is this:

React is a JavaScript library for creating user interfaces by Facebook and Instagram. Many people choose to think of React as the V in MVC.

So, as model/store you usually should use flux or redux, it means other stuff.

I personally used http://knockoutjs.com/ it supports two ways binding, modelling etc. It is very easy and has a good community.

Never used https://angularjs.org/ but it should work in the similar way as knockoutjs.

For my point of view I see only two candidates form model/view: react world or knockoutjs/angularjs.

They are popular and it is important future contributors.

michaelklishin commented 8 years ago

@essen we are moving away from unmaintained or barely maintained projects everywhere else. Why would we maintain an old JavaScript library?

On top of that, please take a look at the code in main.js. It's a mess with plenty of wheels re-invented and no automated testing. Is this really something we should hold on to?

There is a chance that Facebook will drop React development but it's probably fairly low. React has a sizeable community. Sammy is unmaintained today (1.0 probability), has no community in comparison to React, VueJS, probably Knockout and a dozen of others options.

essen commented 8 years ago

I'm not saying maintain it indefinitely. I'm saying don't go too fast.

It's not the same as, say, JSON, because the move to a new JSON lib will make it trivial to switch JSON libs in the future (because now that we have maps, all maintained libs are basically just different implementations of the same interface). So the work you do there is a one time thing. This is not true when switching JS frameworks, because those never agree on anything.

Facebook probably won't drop React anytime soon, but they will make React evolve, and there's currently no guarantee you won't have to rewrite your project completely in a year or two just to keep up to date (I have the same criticism about the Bootstrap upgrade from 2 to 3, which is why I'll soon remove Bootstrap from the 99s website and just use plain CSS). As far as stability is concerned, Angular seems to have proven they care, at least (https://angular.io/docs/ts/latest/guide/upgrade.html).

Same goes for Bootstrap really. Its main point is the grid system, but that grid system can easily be replaced by flexbox (https://css-tricks.com/snippets/css/a-guide-to-flexbox/). Bootstrap components can easily be replaced by web components (http://webcomponents.org/). Both of those techs are "almost there" in terms of browser support, and are standard (unlike Bootstrap). Web components also have JS libs for browsers who lack support. I don't remember what we use for graphs but these days D3 is pretty much "it".

So while I do think Sammy should get replaced eventually, I just don't think now is the best time. If you disagree, and after reviewing everything, I will recommend Angular 2 (should be out of beta by the time this is done), as it should be around in this form for the next 5 years, is popular, and shouldn't require any extra lib.

michaelklishin commented 8 years ago

Quoting myself from earlier in this thread:

This is not about the short term

essen commented 8 years ago

I am aware but I'll probably say the same thing when this becomes short term. :-)

PolCPP commented 8 years ago

I personally don't like angular (my experience comes from 1.x not 2.x). But probably it's the best option. Big maintainer and you shouldn't need extra libraries like with react.

@essen Well the Bootstrap team has stated they won't do the same thing again with Bootstrap 3. (http://blog.getbootstrap.com/2015/08/19/bootstrap-4-alpha/#supporting-v3) but since this is meant to be long term maybe bootstrap 4 when it hits beta would be a better option?

gmr commented 8 years ago

Everyone has a favorite framework. My vote would be for Backbone for dealing with the interface, React for the view, and Bootstrap 4. The choice in graphing is a pretty big one as well. I'd say d3js should be seriously considered.

Backbone would be an ideal choice for dealing with routing, events, and dealing with the models+collections for things like exchanges, queues, users, policies, etc.

Perhaps a good solution would be to allow for the plugin static assets route to be configurable. Then it'd be pretty easy to test out different interfaces or allow people to write a custom replacement interface (which I'm interested in prototyping).

What would probably be ideal is enumerating the requirements or desired features. For example, I think the plugin should:

yordis commented 7 years ago

My 2 cents on this.

Please understand that English is not my first language and I am trying to express my thoughts really quick so please any error or struggling understand, just let me know because I don't want to get people confuse also I don't trying to be mean or rude and if you don't agree with me, it's just another opinion.

I came from Component (Element/Custom Element in modern web) Based Interfaces, which is pretty much where the web is moving btw.

Costumer focus vs internal tool focus

2016, we have such of things like Web Components, ES6, WebRTC ... all of those amazing features. As everyone is aware of browser vendors can't agree on something and at the end of the day we pay the cost as engineers and costumer as well.

Answer me something. Who are the users of this application, Engineers?

If your answer is yes, then as a Engineer probably will upgrade the browser, understand the limitations of the systems and probably as an Engineers you will Chrome or at least something that don't limit a great product because the vendor issues.

The point I am trying make is: don't stress out that much about the current state of the web. This application is not for costumer facing (correct me if I am wrong) so let's think in the future with another focus.

Let's use the modern web practices: Shadow DOM, ES6, new CSS selectors ... Everything from the latest browser vendors only and probably everything that we know will be available but we have to hold 5 years until Microsoft decide to do it, it's what it's. This is an internal application.

CSS frameworks

If you ask me which framework should I use from the market I will choose 100% Bootstrap. There is no way you will such of support from the community around it, just google admin templates and you will notice that most of them use Bootstrap (with jQuery/Angular) in a way of another one. But also look the history of Bootstrap and breaking changes in every single major upgrade, which could be fine for me if it's only imply styles, but isn't the case.

If you ask me what will I actually do I will say do it from scratch. In component based architecture or component based UI which ever you want to see it. The component is a small piece of the whole application which knows how to render, adapt and do everything itself. One of the big problem with Bootstrap is that everything is a global selector or have too many things predefined which will be great if you think your UI as pages. In component based, you think your UI as a composition of components which make the development easier. Think one, reuse everywhere.

Take a look to some implementations in Paper Element (using Polymer but Polymer is not my concern here). Using Shadow DOM probably the thinking of UI as page is a huge failing and also themes problems are resolve in a elegant way and proper way as well with Shadow DOM + Custom Properties.

As you can see, I just want to use the Browser specs because is an amazing movement for the web development today days, still with some vendors being slow but definitely is not what was even 3 years ago.

Javascript frameworks/Libraries

React, Angular, Backbones, Polymer, Ember ... Every single one have trade off. I never will blame Angular (like people do), or React or which ever one. Because I notice that at the end of the day is the lack of understand what the actual problem is. I develop amazing applications on top jQuery/Angular/React and most of the time I am the one who was wrong. Using it in the incorrect way or misunderstand what I was doing.

Point to make, don't blame technologies because Engineers mistakes. Let's understand that.

In between, because something is easier doesn't make it valuable. ErLang is a valuable programming language. Easier?! Probably not for most of the Engineers I bet you.

I want to stress out something related to React that people tend to forget. We tried to put everything inside Javascript at some point (like CSS), we failed.

Also React is not how browsers normally works. What I mean by that, you as a developer deal with Javascript all the time now (because everything is Javascript). You can't think as HTML because there is not such of thing as HTML (JSX is not HTML), yes you had Virtual DOM (which is not DOM either) and don't forget that HTML and DOM are not the same (even worse because we replace both implementations), DOM used HTML and browser understand how to do that, they don't understand JSX and Virtual DOM.

We will have to deal with issues from Virtual DOM because they missed something from the regular DOM. We will dealing with issues in how server side rendering works because you don't have HTML anymore.

Worse case for me, you can't use people like designers that probably know a little bit about CSS and HTML because know the have to understand Javascript and the whole implementation of the Components. There is not longer a easy way to tell them to update something that they could be capable of in such of easy thing as CSS file or HTML file.

I would continue talking about it but I also want to point that React is amazing but there is some big concerns about it. Don't go crazy. Facebook is not RabbitMQ Management Tool. I really don't care how many use X or Y thing if isn't gonna work for me.

Browser are having some concern for the future, like Custom Elements. Which probably once we have it React is not a need at all in the market.

Thinking on the future

I don't like to rewrites things just because could be better, everything could be better. People go crazy jumping between technologies and specially in the front end stacks, just because the want to follow the lead. Google, Apple, Facebook, Netflix ... they have the money for do that. Probably we don't have money at all. We relay in people times and contributions so let's appreciated that.

Which ever is the case, ask yourself: what would make you to change something in the future from your chooses?

Think in long term because every time you think in short term you will delay the new futures just because your short term just work as it was designed: for short terms ...

My final though

Stack

michaelklishin commented 7 years ago

We still see some management plugin users forced to use IE7 or 8 by their IT departments so I doubt we can use all the cutting edge ES or CSS features. Not that we need them anyway, this plugin's UI is hardly particularly advanced.

yordis commented 7 years ago

@michaelklishin if you asked me. The same way you create versioning in API and they need to understand the consequence of being in legacy is the same way I would tackle the problem.

Imagine been in old tech because those people don't want to upgrade or change some rules in their company. The companies that forced to use using IE7 - IE8 (No even Microsoft support) are the problem. We can't be taking ownership on those problems. We should't move slowest because those companies/people.

They could fork it, continue maintaining by them self, they deserve it, as a company, they do! And imagine we are holding better implementations because of that!

In my opinion.

P.S: I would argue you if we need those cutting edge tool but everything is about "relativity"

michaelklishin commented 7 years ago

@yordis I'm sorry but we as maintainers absolutely cannot claim that "those companies are the problem" and ignore their needs entirely. Some of them are paying customers. And no, they will not fork it because they don't have the in house expertise to maintain a fork.

Let's not turn this into a deeply philosophical discussion. We have no control over when and why people upgrade so covering reasonably popular browser version remains a requirement. Our needs here are fairly modest.

yordis commented 7 years ago

@michaelklishin everyone is talking about solutions that doesn't work in IE7-8, React, VueJS so on so I didn't expect that you came with those things in mind.

Why would you support something that no even the creator (Microsoft) supports? Indeed, we have different point of view in term of responsibilities 😄 ...

michaelklishin commented 7 years ago

It doesn't have to be IE7 specifically, that's was just an example. For 3.7.0 or 3.8.0 we can probably go with IE 10+. But I still fail to see how ES6 or the cutting edge CSS features can be justified in our case.

yordis commented 7 years ago

The same way you saying right now versions for be specific for those that should use it when make sense the same way we go from here with new versions. In term of breaking changes point of view and supporting old legacy companies/people.

Justify, well that depends. I really came here because there is a lot of tooling around Queues/RabbitMQ that could be implemented.

Rich UI, new charts, components, new data ... so on, "the sky is the limit, don't limit yourself mate"

How many new features could be introduce with a good foundation that really help the development and it works for long term? Probably way more than what we have right now. That's something that you probably could answer better than me.

P.S: Microsoft only support IE11 and Edge if I am not wrong, why would be even think about older ones then.

nick-keller commented 4 years ago

This has been opened for over 4 years now.

I truly believe that having a better looking and easier to use UI would benefit. And migrating to a well-known JS framework and CSS lib would make the project more accessible for people to contribute.

lukebakken commented 4 years ago

What is the state of this?

There is no progress on this item as there are more important issues for the RabbitMQ team to work on.

What is the best way to help?

Good question. I would start by reviewing the comments in this issue, especially those by @essen. Reasons that the UI refactor has not happened, in my opinion -

I'm sure @michaelklishin will have something to add as well.

michaelklishin commented 4 years ago

@nick-keller as @lukebakken explained, this is not a critically important issue because the current UI is both optional (Prometheus and Grafana is a first-party alternative) and is good enough with all of its warts.

You don't have to wait for our team to contribute, however. We know of companies that have built their own management UI on top of exactly the same HTTP API that this plugin uses today. So you can build a single page app that authenticates the same way or using OAuth 2 (this is much more involved, so I'd not worry about it initially) and looks the way need, uses modern libraries you'd like to use, and so on.

FWIW we are leaning towards using TypeScript with cutting edge React over Elm, although Elm is certainly appealing to our team. There is no reason why this new UI cannot be a standalone SPA in a separate repo which is packaged in a way that's easy to ship together with this plugin. How exactly that can/should be done today, we are not opinionated about. We do not develop interfaces for a living so would happily listen to those that do. Note that our build system is geared towards multi-repo Erlang and Elixir systems, not Web apps, but there should be a way to bridge this gap.

gmr commented 4 years ago

This is something I've really wanted to do, but haven't had much time to work on. I've started and stopped a few times.

I imagine the best way to do this is to start a project on my own with a hope that one day it could be built-in. If I did that, and it was interesting enough for the project, what would be the best from a licensing perspective? I usually use the 3-Clause BSD license.

michaelklishin commented 4 years ago

@gmr we will be transitioning to Mozilla Public License 2.0 in the next few months. You can always double license under the MPL2 and 3-clause BSD, MPL2 is more compatible with both copyleft and ASL2-style permissive licenses.

Thank you for your ongoing contributions!

gmr commented 4 years ago

I've started a prototype @ https://github.com/gmr/rabbitmq-management-ui-prototype

It's written in TypeScript using React. While it's super in super rough initial form, it has i18n support, and after a day of hacking, I can login and logout. I'm going to focus on getting some core functionality into it, then work through development and contributing documentation. Hopefully as it starts to take shape, I can entice others to contribute.

I've made an effort to make sure that I'm following 2020 best practices and using current tooling. Man does the JS community change its tooling and stack too regularly.

I'm using Bootstrap 5 alpha, which is more React-friendly than previous versions. It's easy to change while it's early-days, so if there is a preferred CSS framework and component library, please let me know.

If you're curious as to what it looks right right now, there are a few screenshots @ https://github.com/gmr/rabbitmq-management-ui-prototype/tree/master/screenshots/2020-07-04