I’m going to pull out your questions and inline my answers:
- What technology stack would you consider and why?
- I think this is an almost impossible thing to answer as it tends to
be based on people’s individual preferences. For example, if I was to build an
Admin tool from scratch that wasn’t JS for Solr, I’d do it in Ruby on Rails,
because Rails is the most awesome productive environment for building web apps!
However, that is totally my personal preference.
- What was your experience so far with Solr's UI code? What would you avoid
doing again, what did you like before?
- I hate that we have no tests.
- I hate that doing user authentication has been so difficult and
homegrown.
- I want to leverage our code generated V2 apis. So that as
methods/properties get added we also have them in the admin tool side (whatever
that means).
- Would you be interested in contributing to the UI implementation?
- I don’t think I have the energy for the “big rewrite”, but if we get
some traction, I’d like to expose more features of Solr in the Admin tool.
- Would you consider a web-based / javascript-based framework easier to get
started with, or a JVM-based / kotlin-based UI framework?
- I think they all of their challenges ;-).
I’d love to see some working code that demonstrates how to log into the new
Solr Admin tool, how the code works with our V2 apis, how it would live
alongside the existing Admin UI, what the testing infrastructure looks like,
and of course the build integration.
One thought that I have is do we need to have a “singular Solr Admin”….
Maybe the path forward is that we accept that the existing admin tool is going
to be around a LONG time, but that it’s easy to have a new Admin that can
slowly incrementally grow? Maybe the new Admin tool that you are proposing
should focus on implementing something missing in Solr, like a really great
handling for the V2 Query syntax? Still address the authentication
questions, build questions, etc, but not try to compete directly with the
already existing Admin tool, but instead aim to fill in new gaps. Then, if
you get traction there, as we migrate to V2 apis for example, maybe that code
gets moved into the new tool?
> On Jul 15, 2024, at 3:49 PM, Christos Malliaridis <c.malliari...@gmail.com>
> wrote:
>
> 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
>>
>>
_______________________
Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 |
http://www.opensourceconnections.com <http://www.opensourceconnections.com/> |
My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
<https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
This e-mail and all contents, including attachments, is considered to be
Company Confidential unless explicitly stated otherwise, regardless of whether
attachments are marked as such.
