Thanks for your reply too, Jan. You mention important points. > If frontend devs are to maintain it and we want to attract frontend professionals, then stick to industry standard React or similar.
This is something that troubled me a lot. Following the industry-standards would probably be the safest path. But getting new frontend developers may also be challenging and would probably limit their contribution to only the frontend, which is why I think focusing on the current maintainers would be safe alternative too. > I did Swing programming, which is hopefully far from what Compose offers I also developed a UI with Swing a couple years ago, and I am glad Compose does things different. > I like the simplificy of the current UI I was surprised when I saw it. I think it will be difficult to achieve similar results in simplicity with modern frameworks. > I'd like for the UI to be served by a separate servlet/backend that acts as a proxy, so that the Admin UI could be installed separately in a DMZ network This is something I had to give some thought first. I believe that the UI should be implemented against the API, regardless of the deployment method. It should probably not be the responsibility of the UI how or where it is deployed, but it should be flexible enough so that it can work no matter the environment. I agree that there are probably better ways (security-wise) to host it, but this is a matter of abstraction and should be addressed separately (e.g. different environments may use different proxies). > If we managed to separate the new UI as an independent servlet, perhaps with its own /login logic, it would be so much easier to later move the entire UI to a separate repo, should the need arise. I think it's already quite easy to deploy the UI outside or move the source code to a separate project thanks to Gradle modules and the API abstraction. My thoughts from above apply here too and this proxy could be addressed while the new UI is under development (e.g. in combination with a desktop client for example). > just skip the "new" keywork and semicolons, hehe That's a great way to describe Kotlin to Java devs. :D On Mon, 15 Jul 2024, 22:39 Jan Høydahl, <jan....@cominvent.com> wrote: > > - What technology stack would you consider and why? > > - Would you consider a web-based / javascript-based framework easier to > get > > started with, or a JVM-based / kotlin-based UI framework? > > I consider these related. And it boils down to who will maintain the Admin > UI app. > If frontend devs are to maintain it and we want to attract frontend > professionals, then stick to industry standard React or similar. > However, for the lifetime of the project it's been Java devs who have > maintained the UI with a few huge re-writes being the exceptions, but those > were mostly one-offs or at least one-person. > > So I see why you propse the Kotlin based Compose. In a previous life in > the 90's with Java 1, I did Swing programming, which is hopefully far from > what Compose offers, which I know nothing about. > > > - What was your experience so far with Solr's UI code? What would you > avoid > > doing again, what did you like before? > > I helped patch both the jQuery and the Angular UI. Notable contributions > include the OIDC auth impl, the Nodes screen and the ZK Status page. > On one side I like the simplificy of the current UI, just some JS/HTML/CSS > files, not build, compiling etc. > On the other hand, it makes it hard to add 3rd party modules, upgrade libs > etc. > I dislike the fact that the UI is hosted by the main Solr process and > talks directly to Solr backend APIs. I'd like for the UI to be served by a > separate servlet/backend that acts as a proxy, so that the Admin UI could > be installed separately in a DMZ network and poke a hole in firewalls > between the AdminUI's own backend and the Solr cluster (which would be on a > secure inner network). > > If we managed to separate the new UI as an independent servlet, perhaps > with its own /login logic, it would be so much easier to later move the > entire UI to a separate repo, should the need arise. > > > - Would you be interested in contributing to the UI implementation? > > I could probably lend a helping hand here and there, do some reviews, and > if we manage to partition the elephant, pick a few tasks further down the > road. > > I do Kotlin in day job, and it is an absolute joy to work with. Not hard > at all, so to committers fearing a "new" language, it is actually not that > different, just skip the "new" keywork and semicolons, hehe. > > Jan Høydahl > > > 15. juli 2024 kl. 15:49 skrev Christos Malliaridis < > c.malliari...@gmail.com>: > > > > Thanks for the references David, those are very insightful to me. I am > > definitely not the first one coming up with these ideas, that's for sure. > > > > I think the fact that there are multiple third-party frontends for Solr > > shows how important the UI is to the users and it should push us even > more > > to do something about the current state. > > > > *If there is no objection about the proposed approach I would like to > > proceed and discuss the technology stack that could be used and fulfill > our > > current requirements.* > > > > As I already mentioned before, I've been working on a proof-of-concept > with > > Compose Multiplatform (Kotlin) that demonstrates what an integration > would > > look like. > > Since there are many pros and cons for all the available UI frameworks > out > > there, I broke down my point of view and reasons for Compose in a writeup > > < > https://docs.google.com/document/d/17B6TuUbbpvg823ixrsnVPT6hJ4vuVv9UHzIz4jITvHI/edit?usp=sharing > > > > again. > > > > But because this is a very opinionated topic, *your input is needed*. To > be > > more precise, here are a few questions: > > - What technology stack would you consider and why? > > - What was your experience so far with Solr's UI code? What would you > avoid > > doing again, what did you like before? > > - Would you be interested in contributing to the UI implementation? > > - Would you consider a web-based / javascript-based framework easier to > get > > started with, or a JVM-based / kotlin-based UI framework? > > > > Best, > > Christos > > > > On Fri, Jul 12, 2024 at 11:39 PM David Smiley <dsmi...@apache.org> > wrote: > > > >> An admin UI can definitely be plugged in. Here is one: > >> https://github.com/yasa-org/yasa > >> And you would not be the first to consider a desktop client. There is > >> one of those too: https://solr.search-navigator.org/ > >> > >> On Tue, Jul 9, 2024 at 9:37 PM Christos Malliaridis > >> <c.malliari...@gmail.com> wrote: > >>> > >>> Thanks for your input, votes and feedback so far, I appreciate it. > >>> > >>> The security concerns are justified and are something I am currently > >>> looking into. With a rewrite it will be easier to take that into > account > >>> and consider alternative options that could also enhance security, too. > >> For > >>> example, I am experimenting with a JVM-based and standalone desktop > >> client > >>> (that is probably a safer option and provides extended authentication > >>> support) that can also be run alongside the current Admin UI as a > >>> WebAssembly app if needed (see changes in > >>> https://github.com/malliaridis/solr/tree/composeui). Another option I > >> was > >>> considering was to write and provide the UI as a Solr plugin, but I am > >> not > >>> sure if this could work with the current way plugins are loaded. > >>> > >>> So in my opinion and alongside the current concerns like maintenance of > >> UI > >>> code, this might be solvable with the right technology selection and > API > >>> implementation (which would be follow-up topics). > >>> > >>> On Tue, Jul 9, 2024 at 10:57 PM Gus Heck <gus.h...@gmail.com> wrote: > >>> > >>>> Disabling certainly is helpful, but... there's the risk it gets > >> enabled, > >>>> it will still contribute to the footprint that vulnerability scanners > >> have > >>>> to cover. > >>>> > >>>> If it's something that can be enabled/disabled or removed from the > full > >>>> distro, and added to the slim distro if desired, that would be even > >> better. > >>>> The easier all of those things are, the better of course. > >>>> > >>>> Food for thought: https://github.com/jetty/jetty.project/issues/5007 > >>>> > >>>> If the UI is a self contained web-app containing only JS/HTML that can > >> be > >>>> undeployed that's pretty much a standards based solution to the > >> problem. > >>>> This sort of wheel was invented long long ago, and we have the basic > >> tools > >>>> at our disposal already (jetty)... There is no need for the UI to have > >> any > >>>> java code at all I suspect... > >>>> > >>>> -Gus > >>>> > >>>> On Tue, Jul 9, 2024 at 3:20 PM David Smiley <dsmi...@apache.org> > >> wrote: > >>>> > >>>>> RE security; disabling it would suffice and if I recall is already > >>>>> supported. > >>>>> > >>>>> On Tue, Jul 9, 2024 at 3:09 PM Gus Heck <gus.h...@gmail.com> wrote: > >>>>>> > >>>>>> Also +1 ... "in the same repo and alongside" is how the last > >> migration > >>>>> was > >>>>>> done IIRC. The big plus of this is as it's developed to a point of > >>>>> partial > >>>>>> utility you can put a link in the old UI to try out the new UI and > >> get > >>>>>> feedback and make testing much easier. > >>>>>> > >>>>>> One thing that might be nice if we can do it, is to make the UI > >> more > >>>>>> pluggable, and allow those who have no desire to test it to start > >> solr > >>>>> with > >>>>>> it fully uninstalled. (i.e because they don't want to account for > >> its > >>>>>> security in production) > >>>>>> > >>>>>> Also it would be very good if we carefully understood how we want > >> to > >>>>>> achieve security (including information exposure, and role based > >>>>>> access/display) before we put it in a release. > >>>>>> > >>>>>> On Tue, Jul 9, 2024 at 10:40 AM Houston Putman <hous...@apache.org > >>> > >>>>> wrote: > >>>>>> > >>>>>>> I agree with Jason on everything. > >>>>>>> > >>>>>>> Thank you so much for putting this much work into something with > >> so > >>>>> much > >>>>>>> baggage in the community! > >>>>>>> > >>>>>>> I'm a huge +1 here, and love the things I saw in your > >> screenshots on > >>>>> Slack. > >>>>>>> > >>>>>>> - Houston > >>>>>>> > >>>>>>> On Mon, Jul 8, 2024 at 2:23 PM Jason Gerlowski < > >>>> gerlowsk...@gmail.com> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Hey Christos, > >>>>>>>> > >>>>>>>> Sorry for the delay responding here - lots of context to read > >> up > >>>> on! > >>>>>>>> > >>>>>>>> Firstly, thanks for the huge effort you've put into writing > >> this > >>>> all > >>>>>>>> up! Quite the thorough job, and it's really helpful to enable > >> us > >>>>>>>> non-UI folks to follow along haha. > >>>>>>>> > >>>>>>>> If I understand things correctly, there's a few distinct > >> aspects to > >>>>>>>> your proposal: > >>>>>>>> > >>>>>>>> 1. New UI would live alongside the existing one (for a time) > >>>>>>>> 2. The code for the new UI would live in the main repository. > >>>>>>>> 3. Development would be piece-meal (i.e. not one big code-dump) > >>>>>>>> > >>>>>>>> Overall, this sounds like a reasonable approach to me. > >>>>>>>> > >>>>>>>> I think a big concern with putting code in the main repo is > >> that > >>>> it's > >>>>>>>> pretty far from the (current) PMC's/community's wheelhouse to > >>>>>>>> maintain. I definitely share that concern. But IMO we're > >> already > >>>>>>>> sortof at a "worst case" in that regard with our existing > >> Admin UI > >>>>>>>> code. Doing the "refresh" in the main repo gives us a forcing > >>>>>>>> function (i.e. the review process itself) to ensure that at > >> least a > >>>>>>>> few community members will understand the code to at least some > >>>>>>>> extent. That'll be a huge improvement over where we are today. > >>>>>>>> > >>>>>>>> Anyway, I'm a cautious '+1' based on these details at least. > >> To > >>>>> quote > >>>>>>>> a message from Jan in Slack: "I'd rather see some imperfect > >>>> movement > >>>>>>>> than a perfect plan never realized." > >>>>>>>> > >>>>>>>> (Here's hoping my reply will bump this to the top of folks' > >>>> Inboxes, > >>>>>>>> and get you some more feedback.) > >>>>>>>> > >>>>>>>> Best, > >>>>>>>> > >>>>>>>> Jason > >>>>>>>> > >>>>>>>> On Mon, Jul 1, 2024 at 12:25 PM Christos Malliaridis > >>>>>>>> <c.malliari...@gmail.com> wrote: > >>>>>>>>> > >>>>>>>>> Hello everyone, > >>>>>>>>> > >>>>>>>>> In regards to SIP-7 > >>>>>>>>> < > >>>>>>>> > >>>>>>> > >>>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/SOLR/SIP-7+Updated+Solr+Admin+UI > >>>>>>>>> > >>>>>>>>> and SIP-10 > >>>>>>>>> < > >>>>>>>> > >>>>>>> > >>>>> > >>>> > >> > https://cwiki.apache.org/confluence/display/SOLR/SIP-10+Improve+Getting+Started+experience > >>>>>>>>> > >>>>>>>>> I would like to add my perspective and address the current > >>>> concerns > >>>>>>> about > >>>>>>>>> implementing a new UI, so that we can take some actions and > >>>>> improve the > >>>>>>>>> overall quality and experience of Solr Admin UI. > >>>>>>>>> > >>>>>>>>> There are many discussions and opinions about the UI and how > >> to > >>>>> resolve > >>>>>>>> the > >>>>>>>>> current issues, but they all led to the topic becoming > >> stale. In > >>>> my > >>>>>>>>> opinion, developing and introducing a new UI into the main > >>>>> repository > >>>>>>>> piece > >>>>>>>>> by piece without replacing the current UI until > >> feature-complete > >>>>> could > >>>>>>>>> > >>>>>>>>> - address all the issues currently reported (and not), > >>>>>>>>> - add new features, > >>>>>>>>> - replace the EOL framework and > >>>>>>>>> - improve the overall user experience. > >>>>>>>>> > >>>>>>>>> And the maintenance, which is one of the most important > >> parts, > >>>>> could be > >>>>>>>>> addressed with the right choice of framework. > >>>>>>>>> > >>>>>>>>> I created a detailed writeup > >>>>>>>>> < > >>>>>>>> > >>>>>>> > >>>>> > >>>> > >> > https://docs.google.com/document/d/14F1QARdkIrmKXQ4zuWUuOXduH4v_XwZ_Zrd0d2jE468/edit?usp=sharing > >>>>>>>>> > >>>>>>>>> for those who are interested, where I also write about the > >>>>> alternative > >>>>>>>>> approaches proposed in the past and listing the pros and > >> cons of > >>>>> each > >>>>>>> one > >>>>>>>>> individually. > >>>>>>>>> > >>>>>>>>> I also started to improve this part by simply designing a > >> new UI > >>>>>>>>> < > >>>>>>>> > >>>>>>> > >>>>> > >>>> > >> > https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept > >>>>>>>>> > >>>>>>>>> and addressing multiple issues at once. I have already > >> received > >>>>> some > >>>>>>>> community > >>>>>>>>> feedback > >>>>>>>>> < > >>>>> https://apachesolr.slack.com/archives/C01GVPZSSK0/p1718289047297999 > >>> , > >>>>>>>> but > >>>>>>>>> it is far from production-ready and needs more input. I think > >>>> this > >>>>>>> could > >>>>>>>> be > >>>>>>>>> further refined and moved to development if there is > >> consensus on > >>>>> that > >>>>>>> as > >>>>>>>>> the initial approach. > >>>>>>>>> > >>>>>>>>> What's your opinion about this approach and do you have any > >>>>> concerns > >>>>>>> that > >>>>>>>>> have not been addressed? > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Christos > >>>>>>>> > >>>>>>>> > >>>> --------------------------------------------------------------------- > >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >>>>>>>> For additional commands, e-mail: dev-h...@solr.apache.org > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> http://www.needhamsoftware.com (work) > >>>>>> https://a.co/d/b2sZLD9 (my fantasy fiction book) > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >>>>> For additional commands, e-mail: dev-h...@solr.apache.org > >>>>> > >>>>> > >>>> > >>>> -- > >>>> http://www.needhamsoftware.com (work) > >>>> https://a.co/d/b2sZLD9 (my fantasy fiction book) > >>>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > >> For additional commands, e-mail: dev-h...@solr.apache.org > >> > >> >
