dropserver

Github

Using ds-dev to Develop Dropserver Applications

ds-dev is a command line tool that runs Dropserver applications locally for the purpose of developing apps.

Some features and capabilities:

Installing ds-dev

Get the ds-dev executable from the Dropserver releases page. The packaged executable is available for MacOS or Linux. Windows users should use the Linux version under WSL2.

Note:

Dropserver uses Deno as its sandbox, therefore ds-dev requires Deno to be installed and available on the path.

Running ds-dev

To run ds-dev you point it to the directory of the app that you are developing:

$ ds-dev -app=/path/to/app/dir/

Refer to the tutorial to learn what goes in the “app” directory.

Note:

Once ds-dev has started, you can leave it running while you work on your app code. It will reload the app when you save.

To provide an existing appspace as working data:

$ ds-dev -app=/path/to/app/dir/ -appspace=/path/to/appspace/files/

If you downloaded appspace data from ds-host you must unzip it before pointing ds-dev to it.

Note:

The appspace data is never modified. ds-dev copies all the files from the provided directory into a temporary directory, and uses that as the working data.

ds-dev UI Basics

Once running ds-dev should indicate that its UI is available at http://localhost:3003/dropserver-dev/. Make sure this port is available prior to running ds-dev.

Open http://localhost:3003/dropserver-dev/ in a browser window. The UI should show you basic data about your app, and appspace if there is any.

If the app was loaded without errors and no migration is needed for the appspace data, then you should be able to visit http://localhost:3003/ to access your app’s ”/” page.

App Tab

The “App” tab shows you data that ds-dev collected about your app. In particular the name, version, schema and migrations available, along with a table of app routes.

ds-dev app tab user interface

If ds-dev encountered an error while trying to read this data it will report it at the top of this panel. Clicking “Expand” reveals the app log, which will help you figure out where the problem is.

Appspace Tab

The “Appspace” tab is mostly concerned with the data of this appspace (remember that an “app” is just code and an “appspace” is essentially a data directory for an instance of the app. See application model page.)

ds-dev appspace tab

The buttons at the top of this panel include:

At the bottom of this tab, as well as the “Users” and “Route Hits” tabs lives the appspace log. All console log statements as well as some internal messages related to the appspace are reported there.

Users Tab

Displays users and lets you select a user to emulate.

ds-dev users tab

If you loaded an existing appspace, the users in that appspace will show up there.

Note:

Users are considered appspace data. Therefore when you “Reload Appspace” in the “Appspace” tab, you reset the list of users.

Click on the radio button to select a user to emulate. Click “Log Out” to emulate no user (your requests are unauthenticated).

Route Hits Tab

Requests made towards your appspace show up under “Route Hits”.

ds-dev route hits tab

Each “hit” tells you what was requested (authentication if any, method, path) and the response code on the first line.

On the second line information about the matched route is shown: the authentication requirements, the route path, and the resulting action (serve static files or run function handler in sandbox).

Sandbox Control Widget

In addition to the four tabs we just outlined, an important feature is the sandbox control widget at the top of the ds-dev interface.

ds-dev sandbox control widget

You will see the status of the sandbox change as the system reloads app metadata, runs migrations, and executes route handlers.

Click the “Inspect” button to inspect running code. The process is as follows:

What Next?