<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
