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

Based on the current feedback (keep it coming!) I have sketched this vision
and architecture. If there's more interest, we can turn it into a skeleton
implementation:

# Vision

The goal of this project is to create a hyper-modern, performant, and
minimalist JavaScript Solid server. While drawing inspiration from Node
Solid Server (NSS), this new implementation will address its shortcomings
and prioritize scalability, modularity, and developer usability.

## Key Objectives

- **Performance First:** Capable of handling enterprise-scale loads,
targeting thousands to millions of users.
- **Minimalist Design:** Remove unused and experimental features; focus on
what matters most.
- **Modularity:** Clear separation of identity, authentication, storage,
and onboarding.
- **Developer Friendly:** Clean, well-documented, and extensible codebase
that adheres to the Solid specification.
- **Modern Tooling:** Leverage async/await, native modules, fast HTTP
servers like Fastify, and cutting-edge JavaScript runtimes.
- **HTTP Simplicity:** Prioritize simple HTTP/1.1 compatibility for maximum
interoperability.
- **Frontend Agnostic:** Work with any frontend or application layer via
standardized APIs.
- **Testable and CI Ready:** Fully integrated with Solid test suites and
modern CI/CD pipelines.

---

# ARCHITECTURE

## Overview
The architecture is inspired by NSS but modernized and streamlined. Each
subsystem is designed to operate independently and follow the
single-responsibility principle.

### Components

- **HTTP Layer**
  - Fastify server
  - Routing and middleware based on HTTP verbs and Solid operations
  - Blazingly fast, with benchmarks from the start

- **Identity Provider (IDP)**
  - Handles Pod based WebIDs
  - Handles external WebIDs
  - Minimal by default, extendable via plugins

- **Authenticaion Module (AUthn)**
  - Handles WebID-based authentication, including WebID-TLS
  - OIDC-compliant with modular Authentication
  - Single sign-on including WebID-TLS

- **Authorization Module (Authz)**
  - Supports Web Access Control (WAC)
  - Token-based permissions model
  - Modular Authorization system

- **Storage Engine**
  - Modular backend adapters (e.g. file system, S3, memory)
  - POD-level quota management (optional)
  - Interoperable with existing Cloud

- **Account and Onboarding**
  - API-first registration
  - Public, private, invite modes
  - Extensible account templates

### Deployment Model
- Works as a single binary or serverless function
- Container-friendly (Docker, Deno, etc.)
- CLI for local dev setup and testing

### Separation of Concerns
- Each subsystem lives in its own module/package
- Clear boundaries between IDP and storage
- Frontend-independent API endpoints

### Compatibility
- Solid-compliant, LWS Compliant
- API parity with NSS where applicable
- API parity with CSS where applicable



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