Dropserver is an application platform for your personal web services.

See Dropserver.org for details on the project.

The Code

Dropserver is written mainly in Go, but uses Deno as the the sandbox for app code. Deno is not packaged with the DS executables, instead it must be installed separately.

This repository builds two executables:

• ds-host is the complete server that can run apps in appspaces and responds to requests directed at those appspaces. It should run on a cloud VM or on a home server. Linux/x86_64 only.
• ds-dev is intended to run locally and is used to run Dropserver applications while they are being developed. Builds for Linux and Mac are available.

High level directories of Dropserver repo:

• /cmd/ds-host is where most of the Go code lives
• /cmd/ds-dev contains the ds-dev Go code. It pulls in a lot of packages from the ds-host sibling directory
• /denosandboxcode is Deno Typescript code that runs in each sandbox
• /frontend-ds-host and frontend-ds-dev are the frontend code (Vue 3)
• /internal additional Go code that is not specific to Dropserver
• /scripts local build scripts for ds-host and ds-dev

Notes on Go Code Organization

Although it goes against Go's recommendations I favor lots of small packages.

The organization of the Go code is inspired by Ben Johnson's Standard Package Layout. I took the ideas and evolved them to fit the needs of this project.

Specifically, Dropserver is currently made up of two executables that share a lot of functionality, and I foresee more as the project develops. For this reason it's important to maximize the reusability of packages. This is accomplished as follows:

• If exporting a function works well enough, then do that
• For more demanding situations packages export structs. Any dependency is a field of type interface such that the package never imports the packages that it needs, they are injected at compile time.
• Types that are passed between different packages (as function parameters or return types) are defined in a global domain.go. Each package only needs to import domain to speak the same "language" as the rest of the code.
• The main command packages import and initialize each struct, setting fields to other initialized structs such that the interfaces are satisfied.
• The testmocks package generates mocks for all packages that need to be used in testing.
• To prevent nil pointers at interfaces a checkinject utility can verify that each required dependency is indeed non-nil. It can also map out the dependency tree (wip).

The result of this scheme is that ds-dev (which is a cut-down and tweaked version of ds-host) exists with a minimal codebase strictly focused on the parts that are not common with ds-host.

Building

If you want to know how to build locally, please have a look at the Gith