# 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
技術成熟度曲線
## 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
Sign in with Wallet
Connect another wallet