---
# System prepended metadata

title: Low Code web app dvlp
tags: [gui, backend]

---

# Low Code web app dvlp

* [Release Management in the Low Code World](https://dashjoin.medium.com/release-management-in-the-low-code-world-ae1683eba431)
    * 就算app 超小不用測試，解決 version control 還是必須的。version control 常是 LC 的硬傷。
        * backend, DB 可以不用，但 frontend 如果要 reliable deploy/ reuse 是必要的。

## scenario

技術成熟度曲線

![](https://upload.wikimedia.org/wikipedia/commons/thumb/9/94/Gartner_Hype_Cycle.svg/1920px-Gartner_Hype_Cycle.svg.png =70%x)

## overview

```mermaid
flowchart LR
Front
Back
DBMS
DB

Front-->Back-->DB
DBMS-->DB
```

根據情況，可以聚合，甚至變成超大 framework

DB + DBMS 本就該外包。

再來 Backend 一般相對固定，code 中等。

fronend code 最多，但 frontend 如何 綁資料難度也最大，或是效果不如直接接寫UI code。所以造成 firebase app 很多，但 UI 還是要source code。

sample

* LC Frontend/Backend/DBMS/DB
    * budibase, baserow, nocobase...
* LC Frontend + LC Backend/DBMS/DB
    * ToolJet + baserow
    * **ToolJet + supabase**
* Frontend + LC Backend/DBMS/DB
    * **flutter + supabase**
* Frontend + backend middleware + LC Backend/DBMS/DB
    * 

這還另外牽涉到大前端（前端的擴張）之爭。

一般來說，當後端越是 low code，也表示後端功能越少，所以更容易有大前端，更容易採用 graphql...。

當然如果不需要後端，deployee 會簡單很多。

## low code Backend/DBMS/DB

一般是一定會有 DB+DBMS，不少會再整 Back。
有的甚至整 front-end。

gsheet 就像是 DB+DBMS。

DB+DBMS 基本等於 CMS管理系統

* [Top 12 Best Low Code No Code Database Management Platforms](https://www.nected.ai/blog/best-low-code-no-code-database-management-platforms)

1. FOSS
2. spreadsheet like
3. real DB

| Name               | license | spreadsheet-like | real DB |   free-cloud-quota    | star        |
|:------------------ |:------- |:----------------:|:-------:|:---------------------:|:----------- |
| gsheet             | x       |        o         |    x    |                       |             |
| firebase           | x       |        x         |    o    |                       |             |
| NocoDB             | AGPL    |        o         |    o    |         1000          | 57.7k       |
| Baserow            | MIT     |        o         |    o    |         3000          | 2.2k gitlab |
| airtable           | x       |        o         |    x    |                       |             |
| apitable (aitable) | AGPL    |        o         |         | 100 Records per space | 14.9k       |
| Grist              | apache  |        o         |         |         5000          | 9.7k        |
| SeaTable           | x       |        o         |         |         50000         |             |
| NocoBase           | AGPL    |        o         |         |     install only      | 16.7k       |
| directus           | BSL     |                  |         |                       |             |
| supabase           | apache  |        o         |    o    |                       | 89.1k       |
|                    |         |                  |         |                       |             |
|                    |         |                  |         |                       |             |
|                    |         |                  |         |                       |             |

* nocodb
    * 無 frontend
* **Baserow**
    * 有 frontend
        * 但是 application-builder 的 bug 真的很多。table component 基本用不了，資料取得 也有不少問題。
        * 只能算半成品。這也是為什麼把它放在偏 backend 端。
    * [ templates - Lightweight CRM ](baserow.io/templates/lightweight-crm)
    * [ Application Builder 101: How to create applications with Baserow [Webinar] ](https://www.youtube.com/watch?v=WgMn97AoVqI)
    * 我很難說他的UI功能可用。分 資料 和 UI
        * data
            * 很認真找了話可能能夠知道它怎麼連 foreign key，拿資料。
            * 我無法從他的一個 table 的 value 去find 其它table 的某row
            * 好像傳function parameter 只能透過頁面跳轉 get。不知道怎麼用 post。
        * UI
            * 也很難參透它的 widget 意圖
* **nocobase**
    * 有 frontend
        * 更偏向整合成 online app, 而非單純 DB
    * 能對接 Postgres
    * default [docker compose install](https://www.nocobase.com/cn/tutorials/task-tutorial-beginners-guide#132-%E8%AF%A6%E7%BB%86%E5%AE%89%E8%A3%85%E6%8C%87%E5%8D%97%E4%BB%A5-docker-%E4%B8%BE%E4%BE%8B) 含 postgres 
* [ I tried 5 Firebase alternatives ](https://www.youtube.com/watch?v=SXmYUalHyYk)
* [ Best Free Open Source Backend as a Service Solutions ](https://www.youtube.com/watch?v=EgxG3XTZ5uM)
* [**supabase**](https://github.com/supabase/supabase)
    * TS
    * firebase clone based on postgres, BaaS
    * API 是 restful & graphQL。我比較想要 gRPC。
        * 但現在似乎沒有 service 這樣做。
    * <-- choose most of time
* [**pocketbase**](https://github.com/pocketbase/pocketbase)
    * GO, TS for backend programming
    * similar to supabase, but with go + sqlite
    * 已經有 S3
    * can't horizontal scale (2025)
* [**appwrite**](https://github.com/appwrite/appwrite)
    * TS, server side 可以用多種語言，包括靜態的 C#, kotlin, Dart
    * NoSQL by undeline mariaDB
    * >  Appwrite is an all-in-one development platform for Web, Mobile, and Flutter applications. Use built-in backend infrastructure and web hosting, all from a single place. Built with the open source community and optimized for developer experience in the coding languages you love. 
* [**Parse Server**](https://github.com/parse-community/parse-server)
    * JS
    * Back4app default 選擇。
* [~~**directus**~~](https://github.com/directus/directus)
    * TS
    * License Trap
* [nhost](https://github.com/nhost/nhost)
    * TS+Go
    * >  The Open Source Firebase Alternative with GraphQL. 
    * based on hasura --> turn RMDBS to NoSQL
* [SurrealDB](https://surrealdb.com/docs/surrealdb/introduction/start)
    * rust
    * > In addition to giving you complete flexibility over your data model, SurrealDB can also be integrated in a variety of ways. You can use SurrealDB as a traditional backend database, connect to it directly as a BaaS (Backend-as-a-Service), embed it directly into your applications, and much more!
* [kuzzle](https://github.com/kuzzleio/kuzzle)
    * JS
    * > Open-source Back-end, self-hostable & ready to use - Real-time, storage, advanced search - Web, Apps, Mobile, IoT - 

選擇基本在 Supabase, Pocketbase, Appwrite 三者。
BaaS 已經有 stack lock in 的感覺，其實大的 framework 也都有。所以好的，平穩過渡的架構才那麼重要/難。`supabase dbdev` 除非真的納入 postgres 的一部分，不然也覺得很 eval 了。

### different between backend framework

一個巨型的 backend/fullstack framework 和 BaaS 有多少差異？

* **serverpod**(dart)
    * fullstack framework。
    * 其實無限接近 BaaS，會自動啟動 postgres 和 redis。
        * 不是 BaaS 只是因為它注重 fullstack 單一 codebase 的體驗。在 fullstack下，沒有需要先 切成獨立的service，然後再縫合。
    * 一樣有 user auth。
* ABP framework(C#)
* Next.js(TS)
* django(python)

或是輕量 backend framework + 一堆 extension

* fastAPI(python) +
    * FastAPI Users
    * PostgREST
    * ...

這個就差的比較遠。

總體來說，其實只有上手難易度的差別。
應該要可以分拆。或是說，**好的架構就要可以在專案的任何階段都有相應的平穩選擇**。
困難度：BaaS < large backend framework < light backend framework。所以 end user 初期先用 BaaS，快速 on production。隨著需求增加，專案擴大，轉到 framework 用法，定制功能。
如果到了最後，需要重構，修改部件...，就會把 framework 拆成 lib，隨意的替換，組合。基本就是從 登峰造極 到 返璞歸真。

fullstack framework 和 BaaS 在根本目的上有一小部份不同，所以後續採取完全不同的方案。
老實說，我覺得支援斷開的能力是必要的，因為 frontend/backend 就是可能不同 repo，依賴 contract based 才是硬道理。
fullstack framework 一般只用 backend 部份應該都是可以的，opneAPI 可以autogen，realtime API 只要有 lib(usually websocket) + autogen 理論上也 ok。

## low code frontend

先定義 low code frontend 的目標客群就是非RD，e.g. 行政部門。並願意為此付出某種程度的簡化代價。

frontend 因為天生的特性，從功能的角度不算適合 low code。

如果 low code frontend 和 前面的 db/dbms/backend 有整合了話，對 end user 是有大優勢的，因為不懂coding 的 user 本來就很難會用token 串接各個服務。
此時整體整合好的平台是更簡單的。

大部份的 LC frontend 都會自帶 

* [不會寫程式的你也能架站！](https://www.lohaslife.cc/post/article-no-code)
* [The Best Open-Source Alternatives to AppSheet in 2025](https://medium.com/@nocobase/the-best-open-source-alternatives-to-appsheet-in-2025-0269cb248dc4)

| name            | license      | free-cloud-quota | star  |
|:--------------- |:------------ |:---------------- |:----- |
| google appsheet | x            | x                |       |
| Glide           | x            | 1 app            |       |
| Softr           | x            |                  |       |
| Noloco          | x            |                  |       |
| MS Power Apps   | x            | 3 app test env   |       |
| retool          | x            |                  |       |
| UI Bakery       | x            |                  |       |
| Baserow         | 見上         |                  |       |
| Budibase        | x (Fake GPL) |                  | 27k   |
| Appsmith        | apache       |                  | 38k   |
| ToolJet         | AGPL         |                  | 36.6k |
|                 |              |                  |       |
|                 |              |                  |       |
|                 |              |                  |       |

* **appsheet**
    * appsheet 就是做的最完整的了
        * 如果你覺得複雜，那表示 其他 low code 只會更複雜。
    * [ 誰說做 App 一定要會寫程式？Google AppSheet 零程式碼開發術，連文組生也能快速打造客製化 App！ ](https://www.youtube.com/watch?v=b_Cyw2qbIQM)
    * [ AppSheet製作成績查詢App：(2) 資料更新，細部設定以及app分享 ](https://www.youtube.com/watch?v=pLUiC8nzAl4)
    * 權限管理的查詢其實是進階功能的。
    * [ 【AppSheet教學】如何讓每個使用只能看到自己輸入的資料 ](https://www.youtube.com/watch?v=Wj4SgsSu3YE)
    * 
* **appsmith**
    * [Datasources](https://docs.appsmith.com/connect-data/reference)
    * [How to build a Baserow CRUD app in Appsmith](https://www.appsmith.com/blog/how-to-build-a-baserow-crud-app-in-appsmith)
        * 直接用 baserow 的 restful API 拿資料。
        * 沒教UI。
    * 比起 no code platform 更接近 Developer Tool
        * 老實說，是low code 沒錯，但界面很複雜，更像是 win form IDE。
        * 把它當成 RD 學習 best UI APP 架構 e.g. MVVM 會更好
    * 或是說，把 appsmith 放在這裡是不對的，算不上真的 low code。還是可能要花更多時間去學。
* budibase 
    * 可用，UI 體感操作起來比 baserow 好很多。
    * 內建資料。基本上也是 fontend/backend/DBMS/DB。
    * 一樣能[外接DB](https://docs.budibase.com/docs/sql-datasource)，或 [restful API](https://docs.budibase.com/docs/rest)。
    * fake GPL: up to 20 internal users and unlimited public users
* **ToolJet**
    * 一樣連接到[外部data](https://docs.tooljet.ai/docs/data-sources/sample-data-sources/)
    * 能接 supabase, firestore...
    * workspace
        * data sources (database)
        * app1
        * app2...
    * 很好的平衡使用的難度，和維持 data source from DB。有機會打破 沒有 data normalization 的問題。 
        * <-- 是目前我認為的**最佳解**。
    * [gitsync version control](https://docs.tooljet.ai/docs/development-lifecycle/gitsync/overview)
* [figma sites](https://blog.user.today/figma-sites-website-builder-test/)

### 目前結論

* 目前測起來了話，我認為 很難說 No code UI 可用。 data binding 層層藏起，更難看出。
* 還是說是我想要對 data table 做 normalization 導致的？如果直接單一table 重複資料，可能會簡單很多。
    * baserow 也是。
        * baserow 很多 table 用文字當 primary key 也是一個點。
    * appsheet 的 demo 裡也沒有 normalization
* 所以應該說，對工程等級，要維持資料品質，多場景重用資料了話。UI low code 是沒用的。
    * 但是如果是要做一次性的, 一組資料 只對應一個場景，最好只有單一大table。那 UI low code 就有用。
* 目前使用 LC frontend 的前提就是，**放棄normalization**，**放棄客制UI**。

### 推論

* 首先對於 internal app，放棄客制UI 是永遠必要的。
    * 複雜UI的複雜度是源自其本身，low code 無法降低難度，甚至變得更複雜。
    * appsmith 如果要給 internel app，就要 放棄 用 js 對畫面做漂亮的客制化。
* "放棄 data normalization" 應該被 fix
    * 首先讓 SSOT data denormalize 是最不可以的，會造成資料混亂。原始資料必須 normalized
    * 首先 internel APP UI 本身不可能多複雜，且是可以被放棄的，很多 app 也是一次性的。
        * 但 internel app 收集到的資料是非常重要的。希望能被存起來。
        * 另外，如果 app 建構時所用的資料是直接從中央原始資料取得就能保證精確無誤。試算表copy 會有延遲。
    * data 用一點 sql ，甚至是建立 sql view table 就會簡單很多。UI 只需要直接 link 該 view table 而不用做額外的操作。
        * RD 來做 下 SQL 的部份也OK。
        * view table 是顯示部份，但反向拆解收到的資料就有難度。也是寫sql?
    * 總之，理論上可以被 fix。**ToolJet** 是目前測起來最好的選擇。

## result

recommend for RD, sorted by order

1. LC front + LC backend
    * tooljet + supbase
3. frontend + LC Backend/DBMS/DB
    * flutter + supabase
        * **<-- 目前推薦**
        * [flutter-user-management](https://github.com/supabase/supabase/tree/master/examples/user-management/flutter-user-management)
        * [Mastering Supabase with Flutter](https://medium.com/@arpan.dev2016/mastering-supabase-with-flutter-part-1-9e98ef04ec1e)
        * default 沒有 type safe，可以用一些工具
            * [Supadart ](https://github.com/mmvergara/supadart)
                * 不support web platform
            * `sup_gen_runner`
            * [`supabase_codegen`](https://pub.dev/packages/supabase_codegen)
                * 沒有成功 run 起
            * openapi(swagger)
                * 直接避免掉 supabase only。
                * > https://{project_ref}.supabase.co/rest/v1/?apikey={key}
                * `swagger-codegen`
                * `swagger_dart_code_generator`
                * 看起來 supabase 的還是更簡潔，但差異不大，因為正常情況都是 service 去 query data。app 不可直接接觸 API。
                * 差別比較大的可能是 supabase realtime API 沒有對應的
            * 或是再加入 serverpod。
4. frontend + backend + LC Backend/DBMS/DB
    * flutter + serverpod + supabase
        * [supapod ](https://pub.dev/packages/supapod)

---

for non-RD

1. LC frontend/backend/DBMS/DB
    1. baserow, tooljet
    2. 很看能接受多難的東西，簡單的東西功能一定少。
2. LC fronted + LC backend/DBMS/DB
    1. 更多是受限真正的資料來源，一定要拆前後端。

## resource

### free online postgresql database

* [Top PostgreSQL Database Free Tiers in 2025](https://www.koyeb.com/blog/top-postgresql-database-free-tiers-in-2025)
* prisma
    * free: 500G
