Re: Proposal for a New Hyper-Modern JavaScript Solid Server

I will be keeping NSS on solidweb.org (maybe frozen, admitted) but open
and running.

Matthias

On Thu, 3 Apr 2025 07:05:16 +0200
Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> po 31. 3. 2025 v 10:01 odesílatel Sjoerd van Groning <sjoerd@muze.nl>
> napsal:
> 
> > Hello Melvin,
> >
> > This sounds interesting. We do have some sidenotes. When such a
> > project could find funding, I think there are plenty of developers
> > who would like to work on it.
> >
> >
> > *NSS Performance *It is correct that in terms of performance, NSS
> > is not the best in class. During Solid workshops at the local
> > University the solidcommunity.org was getting saturated (ca 75
> > students) and we had to ask the class to work in groups. During
> > benchmarks for a customer we have tested it in our servers and get
> > on estimated 20 requests/second. As that was not enough, we have
> > made NSS multithreaded and were able to get 400+ requests/second
> > for our IDP on one server which was enough. We have run a mvp
> > project with 8000+ active users on the largest mediasites in the
> > Netherlands. The intention is to scale the project further this
> > year.
> >
> > *Separation of frontend/backend*
> > We have found it quite satisfying to separate the frontend from the
> > backend. This allows users to create an frontend with their own
> > design much easier. And when you are building a servers (...) You
> > can slap an existing frontend on it. Then you can mix and match
> > between frontends and (api-backends). We are also building a PHP
> > Solid server at the moment and it will have the same api. That
> > allows users to switch backend and switch/modify frontends.
> >
> > *Do we need a new server?*
> > We think it would be a good idea to sketch an architecture design
> > and see how that matchers the current NSS. Maybe it would be better
> > to improve parts of the server and replace them for better code. As
> > the fundaments of NSS feel quite ok?
> >
> > *Separate IDP and storage*
> > When we design a new architecture, it would be good to separate
> > identity and storage even more. For example, for our project, we
> > have used NSS only for identity and it seems that with identity,
> > people will get multiple storage locations. An even better
> > separation could be good to be even more in line with the Solid
> > Specification.
> >
> > We are interested at PDS Interop and Muze, but resources are always
> > scarce. Integrating it with the proper testing and CI/CD would be
> > great we think and very curious about design thought for future
> > servers.
> >
> > Kind regards,
> > Sjoerd
> >
> > PS Two additional remarks:
> > - Please, please, split up the Javasacript versus Rust discussion
> > with a different subject. And feel free to build a Rust Solid Server
> > - In my opinion, servers are not the biggest issues, it are the
> > applications that are missing for the normal users. They create an
> > account, login in and then what... Oh and the onboarding. We really
> > need to design better frontend (see separation).
> >  
> 
> Spoke to Alain on the SolidOS call yesterday. NSS remains
> theoretically open, but in practice it's mostly Alain's solo
> effort—he's understandably stretched thin. We'll continue
> contributing short-term.
> 
> Medium-term, NSS is now over 10 years old, and LWS looks set for REC
> next year. Early experiments suggest that adopting modern tooling
> (Fastify, latest ES modules etc.) could deliver at least a 10x
> speedup. If there's wider interest, perhaps we could explore this
> further together.
> 
> Op 29/03/2025 om 16:47 schreef Melvin Carvalho:
> >
> > Dear CG,
> >
> > As we all know, Node Solid Server (NSS) was originally conceived
> > over 10 years ago and has been instrumental in pioneering the Solid
> > ecosystem. However, given its age and the evolving needs of today's
> > web, NSS is now becoming long in the tooth and is effectively
> > reaching its end-of-life in terms of scalability and enterprise
> > readiness.
> >
> > Currently, alternatives such as CSS and Pivot, while commendable,
> > also fall short when it comes to efficiently supporting thousands
> > or even millions of users.
> >
> > I am proposing a new, hyper-modern JavaScript Solid server that
> > leverages the latest JavaScript tooling, minimalist architecture,
> > and advanced performance optimization techniques. The goal is to
> > achieve enterprise-grade scalability while strictly adhering to the
> > Solid specification, passing all tests in the Solid test suite.
> >
> > Key design points:
> >
> >    -
> >
> >    *Minimalistic architecture*: A lean, modular core that focuses
> >    strictly on Solid specification compliance.
> >    -
> >
> >    *Modern JavaScript tooling*: Utilizing the latest frameworks and
> >    runtime environments (e.g., native async/await, modern V8
> > optimizations, optimized network I/O).
> >    -
> >
> >    *Performance-first approach*: Built from the ground up with
> >    scalability and speed in mind, suitable for enterprise-grade
> > applications and high user volumes.
> >    -
> >
> >    *Pure JavaScript*: Targeted specifically for the JavaScript
> > ecosystem and developers who prefer a JavaScript-only environment.
> >
> > I'm reaching out to gauge interest in this project. If this aligns
> > with your interests or you have ideas and feedback, please share
> > your thoughts. I'd also welcome collaborators interested in
> > defining requirements, contributing to design decisions, or helping
> > build an initial prototype.
> >
> > Looking forward to your feedback and discussion!
> > Best Wishes
> > Melvin
> >
> > --
> > Sjoerd van Groning
> > Muze, werkdagen ma/wo/vr
> >
> > T. 053 - 4308177 | 06 - 41265099
> > I. www.muze.nl | www.simplyedit.io | www.pdsinterop.org
> > E. sjoerd@muze.nl
> >
> >  



-- 
Matthias
https://meisdata.io

Received on Thursday, 3 April 2025 05:23:02 UTC