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
