Modular Server Standard

This is a work in progress

Summary

Servers are powerful when they are able to run the same code and communicate with each other. I think that a new server technology that is designed to be modular, allowing for the addition of one or many endpoints at once through a module or package, would be amazing. The current model for servers is that you install a single piece of software, running any language or runtime, on its own isolated server. For example, Wordpress and Mastodon have to run on their own servers and have completely separate codebases in PHP and Ruby. I really want a server to be a canvas for larger building blocks, like legos. This article provides a glimpse into what a future with a "modular server standard" might look like and its benefits.

1. Is there a need for modular servers?
2. Are we satisfied with servers that run independently (e.g. Wordpress, Mastodon)?
3. Is it worth the effort to implement modular servers?
4. Is it impossible to standardize modular servers?
5. Is it feasible to build a framework around modular servers given the vast scope and varying preferences for frameworks, languages, and runtimes?

Details

This article introduces the concept of a the "Modular Server Standard" (MSS).

Goals of MSS

1. Develop a method for servers to implement the same set of endpoints at any nested route.
2. Create a decentralized system for servers to communicate with each other.
3. Develop a way for servers to implement interactive components.

Philosophy

1. You should be able to own your data.
2. You should be able to have a single server that can utilize open-source plugins / modules / packages, that provide new UI components & functionality to your server at any nested route.

Editable "Components" should have two "views"

On the right is the "edit" view, on the left is the "view". All of the component props are stored in the database.

mss-manifest.json endpoint

The mss-manifest is used to inform other instances of the root endpoint where a plugin is running. For example, if Alice and Bob both use the calendar plugin and one wants to schedule time with the other, Alice can provide her server URL within the UI of the plugin on Bob's instance. Bob's server will then retrieve Alice's mss-manifest.json from https://alice.reggi.com/mss-manifest.json, which might look something like this:

https://alice.reggi.com/mss-manifest.json

{
    "@reggi@calendar_scheduler": {
        "endpoint": "/calendar"
    }
}

https://bob.reggi.com/mss-manifest.json

{
    "@reggi@calendar_scheduler": {
        "endpoint": "/cal"
    }
}

Even though Alice and Bob are running @reggi@calendar_scheduler on their servers at different routes or endpoints, both of the plugins can talk to each other.

Sudo code example

import blog from 'https://https://deno.land/x/reggi@0.0.1/blog'
import shop from 'https://https://deno.land/x/reggi@0.0.1/shop'
import calendarScheduler from 'https://https://deno.land/x/reggi@0.0.1/calendarScheduler'
import mss from 'https://https://deno.land/x/reggi@0.0.1/modular-server-standard'
import database from 'https://https://deno.land/x/reggi@0.0.1/database'

mss.dataProvider(database({
  user: Deno.env.get('DB_USER'),
  database: Deno.env.get('DB_DATABASE'),
}))

const Blog = mss.use(blog({
  "route": "/blog",
  'title': "My Engineering Blog" 
}))

const Shop = mss.use(shop({
  "route": "/shop",
  'title': "Treasure Chest T-shirts"
}))

const Calendar = mss.use(calendarScheduler({
  "route": "/calendar",
  "availability": {
    "monday": "9am-5pm",
  }
}))

mss.route('/', () => {
  return (
    <div>
      <h1>Thomas Reggi's Website</h1><br/>
      <Blog.href>My Blog</Blog.href><br/>
      <Shop.href>My Shop</Shop.href><br/>
      <Calendar/>
    </div>
  )
})

await mss.serve()