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 
> <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
>  
> <https://issues.apache.org/jira/browse/SOLR-12276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17076204#comment-17076204>
> 
> 

Reply via email to