> 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
