Modular Server Standard
Published: 2022-11-25 02:42:47

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

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2as0d80uxkj3o0busqfe.png)

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

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

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

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

```tsx
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()
```