Work with a base Restspace setup

The Restspace base setup has functionality to manage authentication and users, plus ability to read and write JSON data. It also has a service to manage the admin ui. If you click on the Site Header (at the top of the navigation) you'll see the services.json for the site, it looks like this:

{
    "services": [
        {
            "name": "adminSite",
            "serviceName": "staticSite",
            "adapterName": "localFileSystemAdapter",
            "adapterConfig": {
                "filePathRoot": "/admin"
            },
            "basePath": "/admin",
            "readRoles": "all",
            "writeRoles": "A",
            "defaultResource": "index.html",
            "divertMissingToDefault": true
        },
        {
            "name": "authentication",
            "serviceName": "authentication",
            "basePath": "/auth",
            "readRoles": "all",
            "writeRoles": "all",
            "userUrlPattern": "/json/user/${email}"
        },
        {
            "name": "users",
            "serviceName": "userService",
            "adapterName": "localFileDataAdapter",
            "adapterConfig": {
                "filePathRoot": "/json/user"
            },
            "basePath": "/json/user",
            "readRoles": "{email} E",
            "writeRoles": "{email} E",
            "createRoles": "all"
        },
        {
            "name": "json",
            "serviceName": "jsonService",
            "adapterName": "localFileDataAdapter",
            "adapterConfig": {
                "filePathRoot": "/json"
            },
            "basePath": "/json",
            "readRoles": "all",
            "writeRoles": "E A"
        }
    ],
    "domainsServing": [
        "base.restspace.io"
    ]
}

Explanation of the services is as below:

1. This staticSite service hosts the React SPA which implements the Restspace admin interface. The base path /admin is where you go to access this interface. The adapter is localFileSystemAdapter, as the React files are stored on the file system local to the server. You could for instance change this to s3FileAdapter (still to be developed) to have the files stored in AWS S3 (which might be needed to enable the Restspace server to run as a severless function). The readRoles are 'all' so that anyone can download the admin interface - this is necessary so you can log in initially. The writeRoles are 'A' as only the Admin should be able to make changes to this setup. defaultResource says that going to the /admin path should load the index.html file. divertMissingToDefault tells the server to serve the index.html file also for any path under /admin where there is no other static file.
2. The authentication service manages login and getting user details. The authentication endpoints live under /auth. Anyone must be able to log in so readRoles (and writeRoles) are 'all'. The userUrlPattern tells the system where to find the user data for a login. This uses a url pattern (see the documentation) which appends the email property of the data posted to the /login endpoint to /json/user to get the url of the logging in user's record.
3. The userService service manages accessing user records so that passwords are hashed and obfuscated on reading, and to ensure a user has the right permissions for any change made to the user record. Since this is listed before the jsonService, it intercepts requests it would normally handle, and it is an overlay on its path space, adding filters to the access to the /json/user subpath. The readRoles and writeRoles include the {email} user path matching component. This means for a user to have access to the user record, their email property must be one of the path segments on the url of the record. Anyone can create a user: this is registration.
   
   An editor can access the schema for users as for any jsonService by clicking on the Users service heading. You can add any properties to a user record you like by adding property definitions to the schema.
4. The jsonService service handles storing JSON on urls. The localFileSystemAdapter stores this data on the local filesystem. Anonymous read access is the default (the userService above overrides this for resources on the /json/user subpath). An Editor or Admin can edit the data. jsonService needs a JSON schema configured for any directory to which you add a JSON file. These are accessed by clicking the folder or service header. The documentation for jsonService also describes how to do OData style queries to fetch sets of JSON files.