https://github.com/o0101/servedata

File-system-based database (in the git repo), with a server attached with users and access control for serving this data. See an example in production:
https://github.com/o0101/servedata

Last synced: about 2 months ago
JSON representation

File-system-based database (in the git repo), with a server attached with users and access control for serving this data. See an example in production:

• Host: GitHub
• URL: https://github.com/o0101/servedata
• Owner: o0101
• License: agpl-3.0
• Created: 2020-02-14T11:18:42.000Z (over 4 years ago)
• Default Branch: master
• Last Pushed: 2023-01-07T04:40:42.000Z (over 1 year ago)
• Last Synced: 2024-07-27T11:21:57.205Z (about 2 months ago)
• Language: JavaScript
• Homepage: https://dosyago.com
• Size: 5.02 MB
• Stars: 63
• Watchers: 2
• Forks: 1
• Open Issues: 7
• Metadata Files:
  • Readme: README.md
  • Funding: .github/FUNDING.yml
  • License: LICENSE
  • Security: SECURITY.md

Awesome Lists containing this project

README

        
# :crystal_ball: [Dosyago](https://github.com/cris691/servedata) ![downloads](https://img.shields.io/npm/dt/servedata) ![version](https://img.shields.io/npm/v/servedata?label=version)

**Around 3000 source lines of code** (see stats folder)

## What is Dosyago / Capi.click?

A simple server based on [SirDB](https://github.com/cris691/stubdb) with a [schema-driven](https://buf.build/blog/api-design-is-stuck-in-the-past) API, for serving all types of data, while attempting to meet [ROCA](https://roca-style.org/) guidelines.

Already includes schemas, users, groups, authentication, authorization, permissions and payments. 

## Using this template

You need to populate the secrets directory, with a G Suite/GMail API key with sender permissions, and (if you want fun error pages), a Giphy API key.

Also right now there's some places in the templates where I used my email ([email protected]), so you probably want to replace that.

Also to use payments, you need Stripe keys. 

## Use cases

This uses the SirDB as a database. This would be acceptable for user account related use cases for a moderate number of users (up to 100k), or for user content and data related use cases for a smaller number of less frequent users (up to 5k). Mitigations such as vertical scaling, and using a ramdisk (with scheduled saves to hard disk) can increase performance.

For apps with a large number of users performing many operations on data and content, a separate database for content and data (separate to user account data) will be good.

## Features

- Automatic CRUD for tables

- Permissions for users and groups

- Custom actions for updating multiple tables or using 3rd party APIs

- Views for showing result of simple operations

- Custom selections to grab data from multiple tables or 3rd party APIs and display

Examples of all the above can be found in the code.

You can use whatever view framework you like. For convenience here I use bepis.