Posts

前言 現今網路世界主要都是用 HTTP request-response 的 model 來做為溝通的模型，client 發送 request 給 server，server 再回傳 response 給 client，但是隨著 Web 的需求改變與技術的演進，漸漸需要另一種溝通方式，來讓 server 無須被 client 請求時就能主動傳送資料給 client，最常見的例子就是股票網站的股價更新、新聞網站的文章更新…等等，或是需要前後端雙方即時溝通的需求，衍生出 WebSockets 的誕生。技術上區分為 Client Pull 和 Server Push 兩種，本篇文章就稍微總結這兩種方式的差異，以及各自有哪些方法 實時更新的幾種方式 主要分成以下幾種方式: Client Pull Short Polling Long Polling Server Push WebSockets SSE (Server Send Event) Short Polling vs Long Polling 早期更新方式是透過 JavaScript 的 Polling(輪詢)來獲得 server 最新的資料 Short polling Short polling 是一個 AJAX-based 的 timer，讓 client 每隔一段時間去向 server 獲取資源，但效能不好，因為有可能 client 每隔 N 秒去問 server 時這 N 秒內資料都沒改動，就會浪費網路資源...

前言 前陣子入手一台 MacBook Pro，CPU 處理器是 Apple 自家的 M2 晶片，開發上意外發現使用 docker build 的 image 會無法運行在 AWS EC2 上的 Ubuntu 作業系統上，明顯違反了 docker 的口號: Build once, run everywhere，深入研究後才理解，原來這是跟 CPU 處理器的架構有關，稍微紀錄一下來龍去脈和問題解法，以供未來的自己回來參考 以 Python FastAPI 簡例還原問題 建置本地端的 docker image 首先，為了還原遇到的問題，用 python:3.9-slim 的 image 來 host 一個 container，並在裡頭運行一個簡單的 FastAPI server Python 環境建置、套件安裝 python3 -m venv venv source ./venv/bin/activate pip3 install fastapi uvicorn pip3 freeze > requirements.txt 並準備 FastAPI 主程式 from fastapi import FastAPI import uvicorn app = FastAPI() @app....

前言 這篇文章主要是探討 PostgreSQL 的 Constraints 情境下的幾種 ACTION，以作為一個簡單的學習紀錄 何謂 Constraint？ 眾所皆知，Foreign key(FK) 是 Table 中一個或一組用來關聯另一張表的 Primary key(PK) 的欄位，其中： 關聯另張表的表叫做 referencing table 或 child table 被關聯的表則稱為 referenced table 或 parent table 當 parent table 的某欄位和 child table 的某欄位有關聯時，例如: PK(Primary Key)和 FK(Foreign Key)的關係時，此時對 parent table 這個欄位做出修改(update)或刪除(delete)的操作，勢必會連帶影響到 child table。此時，child table 就需要明確的告訴 parent table，該筆操作對 child table的欄位要有什麼影響(ACTION)? 所以如何決定這些跨表參照欄位的存亡關係，就取決於 Constraint 的設定．換言之，SQL 透過 Constraint 的限制來協助我們維持父子表之間的參照完整性(referential integrity) 而 Constraint 又分為被更新(ON_UPDATE)以及被刪除(ON_DELETE)時，分別有對應的影響(ACTION)可以設定，實務上有 PK 和 FK 關係的欄位，大多會用 ON_DELETE居多． 在 PostgreSQL 中的語法結構大致如下(參考該網站)： [CONSTRAINT fk_name] FOREIGN KEY(fk_columns) REFERENCES parent_table(parent_key_columns) [ON DELETE delete_action] [ON UPDATE update_action] ACTION 有哪些？ 可設置的 delete_action 和 update_action 都稱為 ACTION，分為以下幾種:...

前言 前陣子使用 AWS 的 EC2 來部署一個測試用的 backend api，以利 Netlify 上的前端網站作溝通，但因為近代瀏覽器(ex: Chrome…)遵守 CSP(Content-Security-Policy) 限制，避免 HTTPS 協定的網站前端 javascript 透過 fetch 方式去索取 HTTP 協定的任何資源，以避免 MIT(中間人攻擊)，所以勢必得將自身 backend 的網域加上憑證，起初想到用 Nginx 搭配 Let’s Encrypt 來定期每三個月更新憑證，但後來發現 Caddy 更好用更簡潔，就順手紀錄一下操作的歷程。 Caddy 介紹 Caddy 是一個功能強大、可擴充的平台，可以提供(serve)服務或網站，底層是用 Go 撰寫的，依照 Caddy 官網所說，它不僅僅能作為 Web server 或是 proxy，更能作為 server of servers． Caddy 預設以 HTTPS 為通訊協定(也支援 HTTP/2)，支援 gzip 壓縮，而且不再需要每三個月定期去 Let’s Encrypt 更新憑證，因為 caddy 會自動幫我們更新憑證。此外，運行時不仰賴其他套件或 runtime，可獨立 host 在 container 內。依照官網所說，caddy 已經是 production-ready，可以取代上一世代的 Nginx 或 Apache。 前置作業：創建 EC2 首先，我先在 AWS 上創建 EC2 的 instance:...

前言 前陣子因為某接案需求要研究 Medusa 這個開源的電商專案，發現底層設計的 Event Architecture 有參考到 Transactionally Staged Job Drain 這個事務處理機制，因此拜讀了一下這篇 2017 年的文章，當時作者也在 Hacker News 上與網友有不少討論，相信對於研究底層的設計可以讓自己功力提升，因而有了這篇文章的誕生． 問題描述：Event Queue + ACID 聲明：本篇取材自 Transactionally Staged Job Drain 的整理消化，圖片皆來自於此． 文章探討的情境是: 任務佇列(Job Queue)消化的速度太快，導致後台服務(background worker)在該事務 commit 前就嘗試取用，進而無法訪問到預期可用的資料，也就是如何搭配 ACID 與 Event Queue 解決上述事務的問題． 底下是一個顯而易見的例子： BEGIN TRANSACTION; /* db_op1 */ INSERT INTO USER(id, name, age, email) VALUES (1, 'Madi', 27, 'example@gamil.com'); /* queue_job */ -- Some enqueuer worker /* db_op2 */ INSERT INTO USER(id, name, age, email) VALUES (2, 'Kevin', 20, 'example2@gamil....