I don't think *we* should build a UI. Moreover, I think we shouldn't keep the current UI. The reason I say this is because as a community we don't have UI expertise. Hence, I don't want us to support a UI that can break over time as we add/deprecate/update our features without being able to fix the UI too. Supporting a UI will slow us down.
I'm +1 to collaborate outside of Apache to build such a standalone UI. On Wed, 8 Apr, 2020, 11:35 am Marcus Eagan, <marcusea...@gmail.com> wrote: > <david.w.smi...@gmail.com> wrote: > >> >> At the risk of displaying my ignorance for the current state of the art >> in front-end dev/tech: >> Why would we need a Node.js backend or any backend for that matter if >> this is purely a browser front-end based UI that will be deployed? I'm >> aware there needs to be a webserver of course, but jeesh, Jetty is >> competent at that! >> > > WRT to separate. The Node.js backend I suggest is a backend that is used > for transpiling code that isn’t JS into JS, and for packaging apps or > running the tests. Almost all new apps use some permutation of this pattern > afaik. Could and probably should still use Jetty or keep things as simple > as possible. The Hetty dependency still may put us at risk for boxing out > some UI devs. So, perhaps there is an option for running the app as a > node-only app locally for development purposes. These are implementation > details, though and I don’t have answers. > > As a first step, I’ll test the existing work Jan pointed to and see how > the apps behave with Solr to identify gaps and share my findings. Feedback > always welcomed > > Marcus > > On Tue, Apr 7, 2020 at 21:05 David Smiley <david.w.smi...@gmail.com> > wrote: > >> I sympathize with what Gus wrote 100%. For "small" users, I even say run >> ZK on those Solr nodes if you like, but that still leaves you with 3 >> machines. >> >> At the risk of displaying my ignorance for the current state of the art >> in front-end dev/tech: >> Why would we need a Node.js backend or any backend for that matter if >> this is purely a browser front-end based UI that will be deployed? I'm >> aware there needs to be a webserver of course, but jeesh, Jetty is >> competent at that! >> >> > As a disenfranchised volunteer to the project, I also assume voters on >> specific choices like frameworks will be helping build in some respect at >> some point now or in the future. Is that a fair or misguided assumption? >> >> Eh... are you saying either we vote (e.g. express opinions) + (actively) >> help or neither? LOL. You'll gets votes from any/everyone because they >> are cheap to give. Maybe you'll get coding help or maybe not, but I think >> you can count on sufficient attention to get good code that works >> committed, especially since you are also discussing design/architecture now >> to get buy-in. You will not waste your time. If there are sacred cows to >> butcher then NOW is the time to be up front about what some of the most >> opinionated amongst us can accept. >> >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Tue, Apr 7, 2020 at 9:06 PM Marcus Eagan <marcusea...@gmail.com> >> wrote: >> > >> > Gus, >> > >> > Your $.02 are worth a lot more than $.02 USD, so thank you. >> > >> > By separate app, I think I mean to endorse managed by a Node.js process >> started by NPM. I don’t think that conflicts with what you have proposed. >> The NPM command should be issued by Java || or Bash but I don’t think it >> would add significant overhead. Also, seems like on CI and or precommit >> hooks front end could be sizzled in parallel without adding much overhead. >> > >> > As for the front end framework, the most important things to consider >> in my view are simplicity and maintainability. We need to do a thorough >> analysis on the ecosystem and issues like the size of a React project vs >> Angular project vs Vue project, but React and Vue certainly have the >> velocity and the hearts if the front end community more than Angular. React >> is MIT license now and for the foreseeable >> > future thanks to the power and reach of its developers. >> > >> > <gus.h...@gmail.com> wrote: >> >> >> >> +1 for Angular CLI / Typescript since I've fiddled with this in a >> minor way recently, Also MIT license is super friendly. >> >> >> > >> > As a disenfranchised volunteer to the project, I also assume voters on >> specific choices like frameworks will be helping build in some respect at >> some point now or in the future. Is that a fair or misguided assumption? >> > >> > Marcus >> > >> > On Tue, Apr 7, 2020 at 17:15 Gus Heck <gus.h...@gmail.com> wrote: >> >> >> >> +1 for Angular CLI / Typescript since I've fiddled with this in a >> minor way recently, Also MIT license is super friendly. >> >> >> >> Separate App - hmm... that's got some attraction, but also gives my >> stomach some churning when I think about solr now requiring management of 3 >> different servers (solr, something to serve UI and zookeeper). Adding more >> infrastructure gives me pause with respect to all the smaller >> installations. I've had several small self funded startup clients and a few >> clients with existing initial installs that they are outgrowing in places >> where procuring new machines and new software is a 6-12 mo endeavor and >> both types seem to squirm when I make suggestions such as running zookeeper >> separately, (let alone 3 of them). I think separate looks good for medium >> to large folks or very large companies that **already have** a solr expert >> on hand, but hurts the small clients and the departments in large orgs that >> got started with insufficient advice/expertise, so maybe >> >> >> >> - The UI should be installed by default >> >> - it should be easy to remove it, or start with it disabled >> >> - it should be self contained and separately downloadable. >> >> >> >> My recent fiddling included figuring out how to make angular CLI play >> nice in a J2ee war file structure seen here: >> https://github.com/nsoft/ns-login >> >> >> >> By play nice I mean, >> >> - build creates a war file that "just works" when installed >> >> - Angluar CLI commands work >> >> - Angular serve command works (for auto-reloading ui changes, running >> on port 4200; note the use of proxy to allow it to talk to an already >> running web container) >> >> >> >> My $0.02, >> >> >> >> -Gus >> >> >> >> On Mon, Apr 6, 2020 at 11:03 AM Jörn Franke <jornfra...@gmail.com> >> wrote: >> >>> >> >>> I think standalone would be very useful. >> >>> I propose Angular with Typescript - it fits to a more data centric >> approach with data types etc. >> >>> Maybe even two types of UIs - Admin UI and a simple Search UI. >> >>> >> >>> >> >>> Am 06.04.2020 um 16:53 schrieb Jan Høydahl <jan....@cominvent.com>: >> >>> >> >>> Thanks for kickstarting this and bringing some fresh blood and >> enthusiasm :) >> >>> >> >>> Looks like others have had similar wish for a standalone Solr Admin >> App, here’s a quick GitHub search for inspiration: >> >>> >> >>> https://github.com/savantly-net/solr-admin (Angular, nice >> screenshots, 1y old) >> >>> https://github.com/kezhenxu94/yasa (vuejs, impressive screenshots, >> 2y old) >> >>> https://github.com/thereactleague/galaxy (React, no screenshots, >> 4y old) >> >>> >> >>> They all seem abandoned but perhaps a new official effort could bring >> their developers in as contributors again? >> >>> >> >>> the people who work on the Admin UI do not need to be expected to >> know the Java workflow, necessarily. This reality widens the net for who >> can contribute. >> >>> >> >>> >> >>> Agree. Frontend devs have been a shortage in this project, and if we >> can make it easier to attract UI committers who feel at home and productive >> with the UI code, that would be a win. On the other hand, if we expect that >> the UI will be maintained by regular Java committers, then anything that >> makes it easier for them/us to contribute is also a win, like perhaps >> strongly-typed. >> >>> >> >>> Again, thanks Marcus for reviving this topic. Let us all try not to >> be overly ambitious here or shoot the initiative down with bikeshedding. It >> is far more important to fuel the energy and momentum and get something >> built than to remain stuck :) >> >>> >> >>> Jan >> >>> >> >>> >> >>> 6. apr. 2020 kl. 13:47 skrev Marcus Eagan <m...@marcuseagan.com>: >> >>> >> >>> Coming back to these existential questions from my phone: >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> Jan Høydahl >> >>> Added 1 hour ago >> >>> There are many opinions around admin UI. So I think the best place to >> start would be a new mail-thread in dev@ to discuss the way forward. >> Before we start a major re-work, we should probably ask ourselves a few >> existential questions: >> >>> >> >>> Should we turn Amin UI into a standalone app instead of embedded in >> Solr? >> >>> >> >>> >> >>> I think it should be a standalone app. There are many advantages >> gained from a separation of such concerns. Some of the ones include, the >> people who work on the Admin UI do not need to be expected to know the Java >> workflow, necessarily. This reality widens the net for who can contribute. >> >>> >> >>> Testing becomes a lot easier because JS developers are accustomed to >> building tests for static assets and self-contained node apps. They >> generally know less about testing a bit of JS within a massive Java >> project. The test could also run independently for changes that only >> affect the front end. Adding test coverage without adding time to tests >> sounds awesome. >> >>> >> >>> There are quite a few tickets over the years that have seemed to >> suggest that people want more fine-grained control over the Solr admin UI >> overall. Two recent tickets discussed topics like running a Solr Admin app >> on only one node and disabling it al together for whatever reason. See: >> https://issues.apache.org/jira/browse/SOLR-14014. >> >>> >> >>> What UI framework? Guess anything is better than current EOL, but >> will largely depend on who is willing to do the job! >> >>> >> >>> I’m happy to take this on (and willing to follow through on >> completing in my nights and weekends), but I am mostly framework agnostic. >> My stronge preference would be React, provided the license is kosher. There >> was one blip of “practically unusable for most orgs” a couple years back, >> but Facebook made it right really soon after. However, I’m flexible. >> Angular (not JS) and Vue are also great. I would recommend we consider >> Typescript also because of the size of project and number of strongly-typed >> devs on this mailing list. My only reservation with TypeScript, though it >> may not apply in this case, is that the supersets of JS have changed a lot >> more than the frameworks. While CoffeeScript was an unnecessary layer of >> abstraction from my limited perspective, TypeScript might make JS more >> embraceable to a list of Java hackers. >> >>> >> >>> Current UI has no test coverage, can we do better with the new UI? >> >>> >> >>> >> >>> It’s imperative.React, Angular, and Vue each make it easy to include >> tests. >> >>> >> >>> >> >>> >> >>> >> https://issues.apache.org/jira/browse/SOLR-12276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076204#comment-17076204 >> >>> >> >>> >> >>> >> >>> >> >> >> >> >> >> -- >> >> http://www.needhamsoftware.com (work) >> >> http://www.the111shift.com (play) >> > >> > -- >> > Marcus Eagan >> > -- > Marcus Eagan > >
