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

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.
>

Thanks for the stats. We’ve seen between 1–30 requests/second in our
benchmarks, which is quite slow by modern standards.



> *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.
>


+1 on separating front and back end. I think NSS is already 90% of the way
there since it uses Solid OS. There are still some built-in templates for
registration and login—curious if you think those should remain, or be
extracted further?


*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?
>
+1 to exploring a new architecture design.

The fundamentals of NSS are reasonable. However, it’s unclear how quickly a
comprehensive refactor could happen. Even small fixes can take months or
years to prioritize, and there are currently over 300 open issues, some
dating back a decade. In contrast, a new server would likely move faster,
as getting it functional would be the primary focus.

My thoughts:

- Minimalist design based on NSS

- Remove experimental/unused features / bloat

- Fast server runtime (e.g. Fastify)

- Simple, HTTP/1.1-friendly.

- Clean separation: identity, auth, storage, onboarding
- Low bug surface

- Small, lean codebase (OOM smaller than CSS)

- Frontend agnostic

*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.
>

+1. Identity and storage were always intended to be separate, though they
often become coupled due to developer convenience or technical debt. We've
seen similar issues arise in nostr, so it’s not unique to Solid.

One way to mitigate this is by baking the separation directly into the
server’s architecture document. That would provide clearer boundaries and
reduce accidental coupling.

I would also say single sign-on is important here.


> 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
>
+1


> - 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).
>

+1 I am redesigning this on my own NSS instance


> 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
>
>