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 <jan....@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 <marcusea...@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 <gerlowsk...@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 <marcusea...@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-unsubscr...@solr.apache.org > >> For additional commands, e-mail: dev-h...@solr.apache.org > >> > >> > > > > -- > > Marcus Eagan > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
