You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Marcus Eagan <ma...@gmail.com> on 2023/05/02 22:08:19 UTC
Shifting Execution Strategy to a New UI Plugin
HI all,
I have done a lot of research and there is not really a path forward with a
modern UI that does not require a NodeJS server process. Given the push
back from the last Committer meeting,* I'd like to propose that I move
forward with work on the new Solr UI as a plugin that works with the new
package manager that Noble and co stewarded.* In that case, I think things
can evolve somewhat independently and I can make changes to Solr as they
come up. It will also make it easier for me to onboard others. I will
likely host a Solr Admin UI dev so that people who want to work on or
specialize in front end don't have to deal with the challenges of getting
started with Solr. That has gotten more difficult over the past few years
and it is something that should be addressed, but it is out of scope for
this work.
I move fast, but please keep in mind I also have a host of other
commitments and many of them are in the sister project Lucene. However, you
can still expect progress and innovation. If you all find this path to be
amenable, we'll coordinate on this mailing list with Jason Gerlowski for V2
API questions, Ishan and Noble for the package manager which I am somewhat
familiar with, Eric Pugh for lots of stuff, and Jan Hoydahl for auth and
security.
Please let me know what you think.
best,
--
Marcus Eagan
Apache Solr Committer / Open Source Hacker
Re: Shifting Execution Strategy to a New UI Plugin
Posted by Gus Heck <gu...@gmail.com>.
For what it's worth, some time ago, I worked out a configuration with
Angular 2 that did just fine with the usual angular tools, standard angular
serving with hot reloading (as long as the java process was running
separately to answer requests) etc. The "admin" section of my java web-app
starter kit (not a framework and not recently maintained) is here
https://github.com/nsoft/ns-login/tree/master/admin and it builds a war
that deploys into a separate context in a j2ee servlet container... Since
Solr is just a Jetty the same thing should apply. The key bit was
configuring the proxy.conf.json
https://github.com/nsoft/ns-login/blob/master/admin/proxy.conf.json so that
requests to /rest/api went to port 8080 instead of back to the
hotreloading. Likely something similar could be done with any other system
(react, whatever), as long as there's an analog to the angular2 proxy
config to enable hot reloading to send requests back to a different port.
-Gus
On Thu, May 4, 2023 at 3:20 AM Jan Høydahl <ja...@cominvent.com> wrote:
> Hi
>
> Thanks for the clarification. It matches exactly my expectations - during
> development you
> use whatever fancy dev tools includinga nodejs backend to serve the app,
> but at the end
> it is bundled into static artifacts like today's UI.
>
> I can understand how your initial statement was interpreted that we need
> NodeJS in
> PRODUCTION:
>
> > "there is not really a path forward with a modern UI that does not
> require a NodeJS server process"
>
> The whole decision process for new Admin UI has so many parts to it
> - framework choice (react, nextjs..)
> - deployment choice (standalone app, shippped with solr-core,
> plugin-package..)
> - separate git repo or part of mono-repo
> - transition period (two independent apps or unification of e.g. login)
>
> For those reasons I'd prefer an updated SIP-7 document with all the new
> proposals put in, so we can see the full picture including "rejected
> alternatives". I'm not saying this to kill the momentum of a POC or to
> nit-pick on minor details, but I honestly believe it is a necessity. That
> does not prevent some POC / spikingin parallel, to demonstrate things.
>
> I have a question on my own regarding deployment using package manager:
> Package manager requires Solr-cloud. Having no Admin UI in standalone is a
> a non-starter.
> Since the Admin UI is nothing less than serving static assets, I think
> shipping (pre-bundled) UI with Solr tarball is still the best way forward.
>
> Jan
>
> > 4. mai 2023 kl. 08:22 skrev Marcus Eagan <ma...@gmail.com>:
> >
> >> Can you summarize for us non-UI folks why a NodeJS server process
> > would be required? (I had to drop early from the last Virtual Meetup,
> > so I think I missed this. And most folks on this list weren't there
> > at all.). I'll be the first to admit to a lack of standing when it
> > comes to UI stuff, but it still seems surprising to me. Do all web
> > UIs these days require a dedicated process that does additional
> > processing beyond "just" serving HTML/JS pages?
> >
> > Hi Jason,
> >
> > Thanks for your question. To be clear, as I have known front end
> experts, I
> > know I am not a front end expert. I do consider myself more than
> > competent, but I have to clarify for the record. As a principle, I do
> > whatever needs to get done across the stack, which is a habit I honed
> when
> > I was building a startup that had an embedded component, a server
> > component, a web component, a mobile component, and a GPU programming
> > (totally different from everything else aforementioned) component. Here
> is
> > my best attempt at answering the question. There may be more to it.
> >
> > NodeJS is the front end development runtime of choice for many reasons
> and
> > it is used by virtually all modern frameworks in development. For a
> > production deployment, there will not be any need for a node process. The
> > Java process will manage the deployment of generated files for now.
> >
> > Here are a few of the reasons:
> >
> > 1. Access to a build system - access to a build system enables us to have
> > more reproducible code and unit tests.
> > 2. More flexibility on tool choice - for example if we want to use
> > TypeScript, which I do, the NodeJS process handles the transpilation
> > process to JavaScript.
> > 3. Generate source map - With a NodeJS server process we can generate a
> > source map so that even though there was a transformation in the code, we
> > can still debug using browser developer tools.
> > 4. Hot reloading - Of course, this is a feature that is only needed for
> > development.
> > 5. Familiarity to experienced front end devs. The people who we will want
> > to bring to the project are familiar.
> > 6. There is a future where we have some advanced features from NodeJS,
> but
> > that day is obviously not today
> >
> > We can use build artifacts from NPM output to deploy the static,
> > browser-compatible files only in production but I don't recommend that
> for
> > development.
> >
> > I hope that this sheds some light.
> >
> > Best,
> > Marcus Eagan
> > apache Solr Committer / Open Source Hacker
> >
> >
> >
> > On Wed, May 3, 2023 at 10:57 AM Jason Gerlowski <ge...@gmail.com>
> > wrote:
> >
> >> Hi Marcus,
> >>
> >> Can you summarize for us non-UI folks why a NodeJS server process
> >> would be required? (I had to drop early from the last Virtual Meetup,
> >> so I think I missed this. And most folks on this list weren't there
> >> at all.). I'll be the first to admit to a lack of standing when it
> >> comes to UI stuff, but it still seems surprising to me. Do all web
> >> UIs these days require a dedicated process that does additional
> >> processing beyond "just" serving HTML/JS pages?
> >>
> >> To your specific question: developing as a plugin/package seems ok to
> >> me. Though I think I'm missing some context on how that relates to
> >> the NodeJS server requirement. Can you elaborate on that a bit? Is
> >> the benefit of the package/plugin approach that it'd allow you to make
> >> progress without stepping on the toes of folks who aren't keen on
> >> adding a NodeJS server process to solr-core? Or something else?
> >>
> >> Best,
> >>
> >> Jason
> >>
> >> On Tue, May 2, 2023 at 6:09 PM Marcus Eagan <ma...@gmail.com>
> wrote:
> >>>
> >>> HI all,
> >>>
> >>> I have done a lot of research and there is not really a path forward
> >> with a
> >>> modern UI that does not require a NodeJS server process. Given the push
> >>> back from the last Committer meeting,* I'd like to propose that I move
> >>> forward with work on the new Solr UI as a plugin that works with the
> new
> >>> package manager that Noble and co stewarded.* In that case, I think
> >> things
> >>> can evolve somewhat independently and I can make changes to Solr as
> they
> >>> come up. It will also make it easier for me to onboard others. I will
> >>> likely host a Solr Admin UI dev so that people who want to work on or
> >>> specialize in front end don't have to deal with the challenges of
> getting
> >>> started with Solr. That has gotten more difficult over the past few
> years
> >>> and it is something that should be addressed, but it is out of scope
> for
> >>> this work.
> >>>
> >>> I move fast, but please keep in mind I also have a host of other
> >>> commitments and many of them are in the sister project Lucene. However,
> >> you
> >>> can still expect progress and innovation. If you all find this path to
> be
> >>> amenable, we'll coordinate on this mailing list with Jason Gerlowski
> for
> >> V2
> >>> API questions, Ishan and Noble for the package manager which I am
> >> somewhat
> >>> familiar with, Eric Pugh for lots of stuff, and Jan Hoydahl for auth
> and
> >>> security.
> >>>
> >>> Please let me know what you think.
> >>>
> >>> best,
> >>>
> >>> --
> >>> Marcus Eagan
> >>> Apache Solr Committer / Open Source Hacker
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> For additional commands, e-mail: dev-help@solr.apache.org
> >>
> >>
> >
> > --
> > Marcus Eagan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
Re: Shifting Execution Strategy to a New UI Plugin
Posted by David Smiley <ds...@apache.org>.
FWIW I wouldn't veto Node being required to do the front-end build,
although I wouldn't love it either. Primary requirement is that it not be
a component of the production delivery -- glad to see it would not be. And
that anyone could do a build (by adding CLI flags to the build) to not
build the UI, yet still get an otherwise complete build artifact.
Agreed with Jan on Solr needing this UI to be easily available for both
standalone users and SolrCloud users alike.
Yes, let's get an updated SIP-7.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Thu, May 4, 2023 at 3:20 AM Jan Høydahl <ja...@cominvent.com> wrote:
> Hi
>
> Thanks for the clarification. It matches exactly my expectations - during
> development you
> use whatever fancy dev tools includinga nodejs backend to serve the app,
> but at the end
> it is bundled into static artifacts like today's UI.
>
> I can understand how your initial statement was interpreted that we need
> NodeJS in
> PRODUCTION:
>
> > "there is not really a path forward with a modern UI that does not
> require a NodeJS server process"
>
> The whole decision process for new Admin UI has so many parts to it
> - framework choice (react, nextjs..)
> - deployment choice (standalone app, shippped with solr-core,
> plugin-package..)
> - separate git repo or part of mono-repo
> - transition period (two independent apps or unification of e.g. login)
>
> For those reasons I'd prefer an updated SIP-7 document with all the new
> proposals put in, so we can see the full picture including "rejected
> alternatives". I'm not saying this to kill the momentum of a POC or to
> nit-pick on minor details, but I honestly believe it is a necessity. That
> does not prevent some POC / spikingin parallel, to demonstrate things.
>
> I have a question on my own regarding deployment using package manager:
> Package manager requires Solr-cloud. Having no Admin UI in standalone is a
> a non-starter.
> Since the Admin UI is nothing less than serving static assets, I think
> shipping (pre-bundled) UI with Solr tarball is still the best way forward.
>
> Jan
>
> > 4. mai 2023 kl. 08:22 skrev Marcus Eagan <ma...@gmail.com>:
> >
> >> Can you summarize for us non-UI folks why a NodeJS server process
> > would be required? (I had to drop early from the last Virtual Meetup,
> > so I think I missed this. And most folks on this list weren't there
> > at all.). I'll be the first to admit to a lack of standing when it
> > comes to UI stuff, but it still seems surprising to me. Do all web
> > UIs these days require a dedicated process that does additional
> > processing beyond "just" serving HTML/JS pages?
> >
> > Hi Jason,
> >
> > Thanks for your question. To be clear, as I have known front end
> experts, I
> > know I am not a front end expert. I do consider myself more than
> > competent, but I have to clarify for the record. As a principle, I do
> > whatever needs to get done across the stack, which is a habit I honed
> when
> > I was building a startup that had an embedded component, a server
> > component, a web component, a mobile component, and a GPU programming
> > (totally different from everything else aforementioned) component. Here
> is
> > my best attempt at answering the question. There may be more to it.
> >
> > NodeJS is the front end development runtime of choice for many reasons
> and
> > it is used by virtually all modern frameworks in development. For a
> > production deployment, there will not be any need for a node process. The
> > Java process will manage the deployment of generated files for now.
> >
> > Here are a few of the reasons:
> >
> > 1. Access to a build system - access to a build system enables us to have
> > more reproducible code and unit tests.
> > 2. More flexibility on tool choice - for example if we want to use
> > TypeScript, which I do, the NodeJS process handles the transpilation
> > process to JavaScript.
> > 3. Generate source map - With a NodeJS server process we can generate a
> > source map so that even though there was a transformation in the code, we
> > can still debug using browser developer tools.
> > 4. Hot reloading - Of course, this is a feature that is only needed for
> > development.
> > 5. Familiarity to experienced front end devs. The people who we will want
> > to bring to the project are familiar.
> > 6. There is a future where we have some advanced features from NodeJS,
> but
> > that day is obviously not today
> >
> > We can use build artifacts from NPM output to deploy the static,
> > browser-compatible files only in production but I don't recommend that
> for
> > development.
> >
> > I hope that this sheds some light.
> >
> > Best,
> > Marcus Eagan
> > apache Solr Committer / Open Source Hacker
> >
> >
> >
> > On Wed, May 3, 2023 at 10:57 AM Jason Gerlowski <ge...@gmail.com>
> > wrote:
> >
> >> Hi Marcus,
> >>
> >> Can you summarize for us non-UI folks why a NodeJS server process
> >> would be required? (I had to drop early from the last Virtual Meetup,
> >> so I think I missed this. And most folks on this list weren't there
> >> at all.). I'll be the first to admit to a lack of standing when it
> >> comes to UI stuff, but it still seems surprising to me. Do all web
> >> UIs these days require a dedicated process that does additional
> >> processing beyond "just" serving HTML/JS pages?
> >>
> >> To your specific question: developing as a plugin/package seems ok to
> >> me. Though I think I'm missing some context on how that relates to
> >> the NodeJS server requirement. Can you elaborate on that a bit? Is
> >> the benefit of the package/plugin approach that it'd allow you to make
> >> progress without stepping on the toes of folks who aren't keen on
> >> adding a NodeJS server process to solr-core? Or something else?
> >>
> >> Best,
> >>
> >> Jason
> >>
> >> On Tue, May 2, 2023 at 6:09 PM Marcus Eagan <ma...@gmail.com>
> wrote:
> >>>
> >>> HI all,
> >>>
> >>> I have done a lot of research and there is not really a path forward
> >> with a
> >>> modern UI that does not require a NodeJS server process. Given the push
> >>> back from the last Committer meeting,* I'd like to propose that I move
> >>> forward with work on the new Solr UI as a plugin that works with the
> new
> >>> package manager that Noble and co stewarded.* In that case, I think
> >> things
> >>> can evolve somewhat independently and I can make changes to Solr as
> they
> >>> come up. It will also make it easier for me to onboard others. I will
> >>> likely host a Solr Admin UI dev so that people who want to work on or
> >>> specialize in front end don't have to deal with the challenges of
> getting
> >>> started with Solr. That has gotten more difficult over the past few
> years
> >>> and it is something that should be addressed, but it is out of scope
> for
> >>> this work.
> >>>
> >>> I move fast, but please keep in mind I also have a host of other
> >>> commitments and many of them are in the sister project Lucene. However,
> >> you
> >>> can still expect progress and innovation. If you all find this path to
> be
> >>> amenable, we'll coordinate on this mailing list with Jason Gerlowski
> for
> >> V2
> >>> API questions, Ishan and Noble for the package manager which I am
> >> somewhat
> >>> familiar with, Eric Pugh for lots of stuff, and Jan Hoydahl for auth
> and
> >>> security.
> >>>
> >>> Please let me know what you think.
> >>>
> >>> best,
> >>>
> >>> --
> >>> Marcus Eagan
> >>> Apache Solr Committer / Open Source Hacker
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> For additional commands, e-mail: dev-help@solr.apache.org
> >>
> >>
> >
> > --
> > Marcus Eagan
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Shifting Execution Strategy to a New UI Plugin
Posted by Jan Høydahl <ja...@cominvent.com>.
Hi
Thanks for the clarification. It matches exactly my expectations - during development you
use whatever fancy dev tools includinga nodejs backend to serve the app, but at the end
it is bundled into static artifacts like today's UI.
I can understand how your initial statement was interpreted that we need NodeJS in
PRODUCTION:
> "there is not really a path forward with a modern UI that does not require a NodeJS server process"
The whole decision process for new Admin UI has so many parts to it
- framework choice (react, nextjs..)
- deployment choice (standalone app, shippped with solr-core, plugin-package..)
- separate git repo or part of mono-repo
- transition period (two independent apps or unification of e.g. login)
For those reasons I'd prefer an updated SIP-7 document with all the new proposals put in, so we can see the full picture including "rejected alternatives". I'm not saying this to kill the momentum of a POC or to nit-pick on minor details, but I honestly believe it is a necessity. That does not prevent some POC / spikingin parallel, to demonstrate things.
I have a question on my own regarding deployment using package manager:
Package manager requires Solr-cloud. Having no Admin UI in standalone is a a non-starter.
Since the Admin UI is nothing less than serving static assets, I think shipping (pre-bundled) UI with Solr tarball is still the best way forward.
Jan
> 4. mai 2023 kl. 08:22 skrev Marcus Eagan <ma...@gmail.com>:
>
>> Can you summarize for us non-UI folks why a NodeJS server process
> would be required? (I had to drop early from the last Virtual Meetup,
> so I think I missed this. And most folks on this list weren't there
> at all.). I'll be the first to admit to a lack of standing when it
> comes to UI stuff, but it still seems surprising to me. Do all web
> UIs these days require a dedicated process that does additional
> processing beyond "just" serving HTML/JS pages?
>
> Hi Jason,
>
> Thanks for your question. To be clear, as I have known front end experts, I
> know I am not a front end expert. I do consider myself more than
> competent, but I have to clarify for the record. As a principle, I do
> whatever needs to get done across the stack, which is a habit I honed when
> I was building a startup that had an embedded component, a server
> component, a web component, a mobile component, and a GPU programming
> (totally different from everything else aforementioned) component. Here is
> my best attempt at answering the question. There may be more to it.
>
> NodeJS is the front end development runtime of choice for many reasons and
> it is used by virtually all modern frameworks in development. For a
> production deployment, there will not be any need for a node process. The
> Java process will manage the deployment of generated files for now.
>
> Here are a few of the reasons:
>
> 1. Access to a build system - access to a build system enables us to have
> more reproducible code and unit tests.
> 2. More flexibility on tool choice - for example if we want to use
> TypeScript, which I do, the NodeJS process handles the transpilation
> process to JavaScript.
> 3. Generate source map - With a NodeJS server process we can generate a
> source map so that even though there was a transformation in the code, we
> can still debug using browser developer tools.
> 4. Hot reloading - Of course, this is a feature that is only needed for
> development.
> 5. Familiarity to experienced front end devs. The people who we will want
> to bring to the project are familiar.
> 6. There is a future where we have some advanced features from NodeJS, but
> that day is obviously not today
>
> We can use build artifacts from NPM output to deploy the static,
> browser-compatible files only in production but I don't recommend that for
> development.
>
> I hope that this sheds some light.
>
> Best,
> Marcus Eagan
> apache Solr Committer / Open Source Hacker
>
>
>
> On Wed, May 3, 2023 at 10:57 AM Jason Gerlowski <ge...@gmail.com>
> wrote:
>
>> Hi Marcus,
>>
>> Can you summarize for us non-UI folks why a NodeJS server process
>> would be required? (I had to drop early from the last Virtual Meetup,
>> so I think I missed this. And most folks on this list weren't there
>> at all.). I'll be the first to admit to a lack of standing when it
>> comes to UI stuff, but it still seems surprising to me. Do all web
>> UIs these days require a dedicated process that does additional
>> processing beyond "just" serving HTML/JS pages?
>>
>> To your specific question: developing as a plugin/package seems ok to
>> me. Though I think I'm missing some context on how that relates to
>> the NodeJS server requirement. Can you elaborate on that a bit? Is
>> the benefit of the package/plugin approach that it'd allow you to make
>> progress without stepping on the toes of folks who aren't keen on
>> adding a NodeJS server process to solr-core? Or something else?
>>
>> Best,
>>
>> Jason
>>
>> On Tue, May 2, 2023 at 6:09 PM Marcus Eagan <ma...@gmail.com> wrote:
>>>
>>> HI all,
>>>
>>> I have done a lot of research and there is not really a path forward
>> with a
>>> modern UI that does not require a NodeJS server process. Given the push
>>> back from the last Committer meeting,* I'd like to propose that I move
>>> forward with work on the new Solr UI as a plugin that works with the new
>>> package manager that Noble and co stewarded.* In that case, I think
>> things
>>> can evolve somewhat independently and I can make changes to Solr as they
>>> come up. It will also make it easier for me to onboard others. I will
>>> likely host a Solr Admin UI dev so that people who want to work on or
>>> specialize in front end don't have to deal with the challenges of getting
>>> started with Solr. That has gotten more difficult over the past few years
>>> and it is something that should be addressed, but it is out of scope for
>>> this work.
>>>
>>> I move fast, but please keep in mind I also have a host of other
>>> commitments and many of them are in the sister project Lucene. However,
>> you
>>> can still expect progress and innovation. If you all find this path to be
>>> amenable, we'll coordinate on this mailing list with Jason Gerlowski for
>> V2
>>> API questions, Ishan and Noble for the package manager which I am
>> somewhat
>>> familiar with, Eric Pugh for lots of stuff, and Jan Hoydahl for auth and
>>> security.
>>>
>>> Please let me know what you think.
>>>
>>> best,
>>>
>>> --
>>> Marcus Eagan
>>> Apache Solr Committer / Open Source Hacker
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
>>
>
> --
> Marcus Eagan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Shifting Execution Strategy to a New UI Plugin
Posted by Marcus Eagan <ma...@gmail.com>.
> Can you summarize for us non-UI folks why a NodeJS server process
would be required? (I had to drop early from the last Virtual Meetup,
so I think I missed this. And most folks on this list weren't there
at all.). I'll be the first to admit to a lack of standing when it
comes to UI stuff, but it still seems surprising to me. Do all web
UIs these days require a dedicated process that does additional
processing beyond "just" serving HTML/JS pages?
Hi Jason,
Thanks for your question. To be clear, as I have known front end experts, I
know I am not a front end expert. I do consider myself more than
competent, but I have to clarify for the record. As a principle, I do
whatever needs to get done across the stack, which is a habit I honed when
I was building a startup that had an embedded component, a server
component, a web component, a mobile component, and a GPU programming
(totally different from everything else aforementioned) component. Here is
my best attempt at answering the question. There may be more to it.
NodeJS is the front end development runtime of choice for many reasons and
it is used by virtually all modern frameworks in development. For a
production deployment, there will not be any need for a node process. The
Java process will manage the deployment of generated files for now.
Here are a few of the reasons:
1. Access to a build system - access to a build system enables us to have
more reproducible code and unit tests.
2. More flexibility on tool choice - for example if we want to use
TypeScript, which I do, the NodeJS process handles the transpilation
process to JavaScript.
3. Generate source map - With a NodeJS server process we can generate a
source map so that even though there was a transformation in the code, we
can still debug using browser developer tools.
4. Hot reloading - Of course, this is a feature that is only needed for
development.
5. Familiarity to experienced front end devs. The people who we will want
to bring to the project are familiar.
6. There is a future where we have some advanced features from NodeJS, but
that day is obviously not today
We can use build artifacts from NPM output to deploy the static,
browser-compatible files only in production but I don't recommend that for
development.
I hope that this sheds some light.
Best,
Marcus Eagan
apache Solr Committer / Open Source Hacker
On Wed, May 3, 2023 at 10:57 AM Jason Gerlowski <ge...@gmail.com>
wrote:
> Hi Marcus,
>
> Can you summarize for us non-UI folks why a NodeJS server process
> would be required? (I had to drop early from the last Virtual Meetup,
> so I think I missed this. And most folks on this list weren't there
> at all.). I'll be the first to admit to a lack of standing when it
> comes to UI stuff, but it still seems surprising to me. Do all web
> UIs these days require a dedicated process that does additional
> processing beyond "just" serving HTML/JS pages?
>
> To your specific question: developing as a plugin/package seems ok to
> me. Though I think I'm missing some context on how that relates to
> the NodeJS server requirement. Can you elaborate on that a bit? Is
> the benefit of the package/plugin approach that it'd allow you to make
> progress without stepping on the toes of folks who aren't keen on
> adding a NodeJS server process to solr-core? Or something else?
>
> Best,
>
> Jason
>
> On Tue, May 2, 2023 at 6:09 PM Marcus Eagan <ma...@gmail.com> wrote:
> >
> > HI all,
> >
> > I have done a lot of research and there is not really a path forward
> with a
> > modern UI that does not require a NodeJS server process. Given the push
> > back from the last Committer meeting,* I'd like to propose that I move
> > forward with work on the new Solr UI as a plugin that works with the new
> > package manager that Noble and co stewarded.* In that case, I think
> things
> > can evolve somewhat independently and I can make changes to Solr as they
> > come up. It will also make it easier for me to onboard others. I will
> > likely host a Solr Admin UI dev so that people who want to work on or
> > specialize in front end don't have to deal with the challenges of getting
> > started with Solr. That has gotten more difficult over the past few years
> > and it is something that should be addressed, but it is out of scope for
> > this work.
> >
> > I move fast, but please keep in mind I also have a host of other
> > commitments and many of them are in the sister project Lucene. However,
> you
> > can still expect progress and innovation. If you all find this path to be
> > amenable, we'll coordinate on this mailing list with Jason Gerlowski for
> V2
> > API questions, Ishan and Noble for the package manager which I am
> somewhat
> > familiar with, Eric Pugh for lots of stuff, and Jan Hoydahl for auth and
> > security.
> >
> > Please let me know what you think.
> >
> > best,
> >
> > --
> > Marcus Eagan
> > Apache Solr Committer / Open Source Hacker
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
--
Marcus Eagan
Re: Shifting Execution Strategy to a New UI Plugin
Posted by Jason Gerlowski <ge...@gmail.com>.
Hi Marcus,
Can you summarize for us non-UI folks why a NodeJS server process
would be required? (I had to drop early from the last Virtual Meetup,
so I think I missed this. And most folks on this list weren't there
at all.). I'll be the first to admit to a lack of standing when it
comes to UI stuff, but it still seems surprising to me. Do all web
UIs these days require a dedicated process that does additional
processing beyond "just" serving HTML/JS pages?
To your specific question: developing as a plugin/package seems ok to
me. Though I think I'm missing some context on how that relates to
the NodeJS server requirement. Can you elaborate on that a bit? Is
the benefit of the package/plugin approach that it'd allow you to make
progress without stepping on the toes of folks who aren't keen on
adding a NodeJS server process to solr-core? Or something else?
Best,
Jason
On Tue, May 2, 2023 at 6:09 PM Marcus Eagan <ma...@gmail.com> wrote:
>
> HI all,
>
> I have done a lot of research and there is not really a path forward with a
> modern UI that does not require a NodeJS server process. Given the push
> back from the last Committer meeting,* I'd like to propose that I move
> forward with work on the new Solr UI as a plugin that works with the new
> package manager that Noble and co stewarded.* In that case, I think things
> can evolve somewhat independently and I can make changes to Solr as they
> come up. It will also make it easier for me to onboard others. I will
> likely host a Solr Admin UI dev so that people who want to work on or
> specialize in front end don't have to deal with the challenges of getting
> started with Solr. That has gotten more difficult over the past few years
> and it is something that should be addressed, but it is out of scope for
> this work.
>
> I move fast, but please keep in mind I also have a host of other
> commitments and many of them are in the sister project Lucene. However, you
> can still expect progress and innovation. If you all find this path to be
> amenable, we'll coordinate on this mailing list with Jason Gerlowski for V2
> API questions, Ishan and Noble for the package manager which I am somewhat
> familiar with, Eric Pugh for lots of stuff, and Jan Hoydahl for auth and
> security.
>
> Please let me know what you think.
>
> best,
>
> --
> Marcus Eagan
> Apache Solr Committer / Open Source Hacker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org