Product Requirements Document

Project name: Localbase

Tag: Open-source, self-hosted BaaS, Private Blockchain

1. Executive Summary 📝

Localbase is a Self-hosted Backend-as-a-Service (BaaS) that is similar to other BaaS like Firebase, Supabase, Coolify, etc. The main focus is Self-host, developer can use this app to minimize work in creating and maintaining a database, storage bucket, AI, hosting, monitoring and private blockchain while keeping everything private in their own server, no third-party needed. There is also a private blockchain implemented to log every change in the app.

Target user: Developer, student, company owner

2. Core Problem 🚨

• High cloud price: Cloud provider usually have a generous free tier, but have a high price when there is a lot of traffic.
• Data security: using cloud provider means that user / company data is being held by a third-party.
• Data manipulation: SQL / NoSQL data can be manipulated by internal admin, dangerous for personal data.
• Long development cycle: Creating a database, storage, etc takes time.

3. Solution to Problem 💡

• Self-host: Deploy from private machine, no need to pay third-party cloud provider, and data is only held in the user/company internal.
• Hybrid database:
  • High Performance: PostgresSQL for fast processes
  • Tight Security: A private blockchain for audit log to minimize data manipulation
• GUI development: In a click of a button, all technology for an app is created to cut time in development

4. Functional Requirenment (MVP V1) 🎯

Authentication:

• Admin login: Login for admin and user with access via email (Note: first account will be considered admin)
• Logout: Admin and user can logout out of their account
• User management: Admin can choose who can enter

Project Management:

• Create Project: Admin can create project that user can work on and auto-generate Project API key
• Project Access: Admin can control which project user can access
• View Project: User can only see project that they are given access to
• Project API Key regeneration/revoke: API key to identify and authenticate project can be changed
• Project Role: Admin can assign role for user in a project, either be a project admin or project staff

Project User Management:

• Invite user: Admin and Project admin can invite other user to join the project, invite from project admin will only be project staff, or change by an admin. Admin invite can be either Project admin or project staff.
• Permission/authorization:
  • project admin has full access to the project (creating database, bucket, etc.)
  • project staff can only insert data.

Project dashboard:

• Some graph to show the project
• Sidebar for every module (for now, just add the database module)

Database Module:

• Table management: admin & project admin can create and delete table
• Column management: When creating a table, sebuah type data harus ditentukan: Text, Number, Boolean, Date
• Table view (dashboard): A view showing the current table setup and a button to add, edit, delete row
• API Access: everyone can do CRUD process via API (Note: API ENDPOINT template will be added)
  • Project admin: CRUD at table, column and row level
  • Project staff / user: CRUD in row level only
• Input validation: To avoid sql injection

Main blockchain audit module:

• Block structure: Template for every block
• Hashing system: To encrypt every block to verify between the current hash with the previous block hash
• Trigger to create block: use API to create a new block
• Storing block data: change will be write in both postgres and the blockchain, the blockchain will be in a separate database
• Hash Verifying system: To verify that the blockchain hasn't been changed

5. Additional information 📌

• Main Role distinction:
  • Admin (Manager/executive): Can access dashboard of all project and control which user (staff) can access certain project
  • User (staff): can access all project that is allowed and work on them
• Project Role distinction (branch from user):
  • Project admin: Control most of the feature in the project, like creating table, bucket, etc. (Note: Admin (main) will automatically be Project admin)
  • Project staff: Cannot create table, bucket, etc. But can input data into them.
• Project will be contained in one single docker container, new project will be added to that postgres single container (shared-tenant)
• Database creating will use both gorm (for system static table) and normal sql (for project tables)
• Hosting frontend will use static, not SSR
• every table will have 3 default col: id, created_at, and updated_at