前言

在面向全球用戶的平台系統中，API 被濫用幾乎是必然會遇到的問題——無論是攻擊者暴力嘗試登入、
爬蟲高頻抓取資料，還是用戶無意間重複提交表單。

本文分享一個我們實際在生產環境中使用的 Redis-based API Rate Limiting 架構，
涵蓋兩種策略：滑動視窗（Sliding Window） 和 滑動視窗 + 封鎖鎖定（Sliding Window + Block Lock），
並支援以 Session ID、IP、Member Code 等多種身份維度進行限流。

Read More

前言

這是一個只在正式環境才暴露的問題。
我們使用 LazyCache + Redis 搭建了一個兩層快取架構：
MemoryCache 作為 L1 熱快取，Redis 作為 L2 資料來源。
在 Dev、QAT、UAT 環境一切正常，
但上了 Production 後發現 Redis 資料更新了，應用卻永遠拿到舊值。

原因？LazyCache 的 GetOrAdd 直接傳入 TimeSpan，預設行為是 SlidingExpiration。

Read More

前言

Mobile APP 與 Web 不同，使用者不一定會即時更新到最新版本。當後端上線新功能時，舊版 APP 可能尚未支援該功能的 UI 或邏輯。若後端直接回傳新功能相關的資料，可能導致：

• 舊版 APP 出現不預期的 UI 或行為
• 新功能的回應格式在舊版 APP 上解析失敗
• 部分功能僅限特定版本以上使用（例如安全性相關的新裝置驗證）

因此，我們設計了 Feature Version Control 機制，讓後端根據 APP 傳入的版本號，動態決定哪些功能要啟用、哪些要關閉。

Read More

前言

大多數 Vue 專案如果需要 Server Side Rendering，通常會選擇 Nuxt.js 作為全端框架。但我們的情境不一樣——後端是既有的 ASP.NET MVC 應用，負責身份驗證、Session 管理、多語系路由等，不可能整個換成 Node.js。

因此我們設計了一套特殊的整合架構：ASP.NET 只負責輸出 HTML Shell（_Layout.cshtml），Vue 3 SPA 由 Rsbuild 獨立建置，兩者透過一份 manifest.json 在 Debug 和 Release 模式下各自連到對應的前端資源。

這套架構讓前後端可以獨立演進——前端換打包工具（Webpack → Rsbuild）、改 chunk 策略、升級 Vue 版本，都不需要動後端程式碼。

Read More

前幾天同事介紹一個好用的工具,最主要是它可以錄製網頁的 Network ,Console 資訊

因為大家也知道 QA 很常反應問題 一般 IT 還需要重現這個問題. 如果 QA 能夠提供更多的資訊

我們就可以減少 Debugger 的時候.而且這個軟體還是免費而且也整合了 jira 等等的套件

JAM

我們以 myfunnow 這個旅遊網站當例子

Demo

可以看到 他在幾秒的時候 Console 有出現 401 的錯誤 並且在 Network 的 tab 當下有記錄每一個 request 的相關資訊

這些可以幫助 IT 跟 QA 更快反應問題

前言

本文記錄 CC1-2443 票號的 Responsible Gambling（RG）功能重構，核心目的是：

讓用戶可以自助解除 TimeOut 與 SelfExclusion，不再需要透過客服介入。

改版後系統在 RG 狀態到期時，主動在頁面讓用戶決定是否延長或移除限制；同時全面收緊了頁面可見性與帳號功能的權限控管，並在前後端各層都加入了守衛機制。

Read More

突然有感而發 想寫下部門之前用了很多年的 GitFlow 以及它們會遇到的問題，以及他們解決什麼問題

最主要觀念是

1. 正常功能開發以 main branch 為主體(所有的分支都由這裡出發) ，分別 Merge 到 QAT 避免同步大家開發多個功能，
   有互相的影響以及將不必要的程式碼帶到正式環境

2. 緊急修正的情況可以直接根據 main branch 拉出分支修正 避免其他影響 然後部屬到 Pre-prod 測試

首先我們先定義好 Git Branch 以及對應的環境

我們這裡以 main 當作我們的主要分支 所有 branch 都是以 main 為主

我們環境實際上重要的有三種環境

那我們可以依照幾種情境講述會遇到的問題

1. 開發功能 照順序進到 Prod

2. 緊急修正問題 直接推到 Prod

3. 開發功能 時程需要拖很長(歷時一兩個月)

以下是大致上的 Gitflow 流程圖

我們會一個一個介紹

1. 開發功能 照順序進到 Prod

首先我們先介紹我們有幾個 branch 以及大概的功能敘述

1. feature/Profile : 他有會員功能的部分 (新增 UI 以及會修改到 Routing 的檔案)
2. feature/ForgotAccount: 忘記帳號密碼的流程 (新增 UI 以及會修改到 Routing 的檔案)
3. feature/Product: 新的產品頁面 (新增 UI 以及會修改到 Routing 的檔案)
4. main: 我們的正式環境的 branch
5. fix/Week1: 因為我們是每一週會上 Code 所以 branch 以 fix prefix 開頭 然後會把完成的功能 merge 進來

branch 流程順序如下:

1. feature/Profile ,feature/ForgotAccount 都從 main 拉 branch 出來
2. feature/Profile ,feature/ForgotAccount 各自開發 直到完成
3. feature/Profile ,feature/ForgotAccount Merge qat

如圖片黑框的部分 這樣有可能會發生衝突

Issue 1. 因為根據剛剛上面的敘述 A 跟 B 在沒有協調的狀況下 它們有檔案衝突了

所以這是第一個衝突點，Routing 檔案衝突

Solution:

1. 找 A 跟 B 一起選擇 confilt 檔案
2. 並且要討論之後進到正式環境的順序是否是 A 先 B 後 或是 B 後 A 先 ，到時候要討論怎麼 Merge

接著測試到一個段落 QA 也認為 1 跟 2. 的 branch 差不多可以進 Prod 了,我們會透過剛剛提到的 5.
fix/Week1 將大家要進的程式碼統一 Merge 到此 branch 然後 merge to main ,部屬到 Pre-Prod 環境給 QA 做最後檢查

branch 流程順序如下:

1. fix/Week1 都從 main 拉 branch 出來
2. feature/Profile ,feature/ForgotAccount Merge fix/week1
3. fix/week1 Merge main (需要有人 approve 或是檢查程式碼)

這樣好處是 Merge prod 只會有一個點 到時候要退版也會好退

Issue 2. 跟 Issue 1 一樣 有可能會有 Routing 檔案衝突或是其他檔案衝突

如圖片黑框的部分 fix/week1 是從上方這個 main branch 開的 然後 merge 進去這樣有可能會發生衝突

Solution:

1. 定時 Sync main branch 到自己的 branch ex: feature/Profile 如果有衝突可以當下就定時解掉 避免上線前的困擾
2. 找 A 跟 B 一起選擇 confilt 檔案
3. 部屬時候如果有衝突的部分要再檢查一次功能

這樣就完成照順序進到 Prod 的功能了

2. 緊急修正問題 直接推到 Prod

想當然 我們在開發的過程中 有可能緊急有發生 Prod 有問題 需要緊急修正的問題

branch:
hotfix/RegisterIssue : 註冊問題修正的 branch

branch 流程順序如下:

1. hotfix/RegisterIssue 都從 main 拉 branch 出來
2. hotfix/RegisterIssue Merge main (緊急修正 要直接丟到 Pre-prod 做快速驗證後上線)
3. hotfix/RegisterIssue Merge qat

為什麼要做 3 是因為要避免 qat 以及 main branch 有一些落差，理論上 qat 會比較新 但是功能應該要跟 main 相同

Issue 3. 有可能遇到的問題也是類似 ，有可能在 Merge qat 的時候 ,QAT 有新的功能在開發也修改到相同檔案

Solution:

1. 找到衝突的檔案 並且找到功能的作者討論如何修改衝突
2. 並且請功能的作者 他的 branch 先行 sync main 到自己的 branch 維持最新的版本 避免之後 Merge main 又會有衝突

3. 開發功能 時程需要拖很長(歷時一兩個月)

因為要先知道 如果一個 feature branch 存活的週期大於一個月以上一定要定時做一件事情

**定時 sync main to feature branch **

其餘流程要照著正常 feature 推動 這樣才不會有到時候要 Merge main 一堆衝突的困擾

心得

不管使用什麼 gitflow 都是要避免衝突，盡量要跟衝突的檔案的作者溝通 看上線時程，以及 sync main branch.
如果真有遇到 Merge 到錯誤的 branch (最好是先 force reset 到錯誤的地方開始解決 千萬不要再修改檔案避免造成更多錯誤)

先說明這個問題主要是 通常在滾動頁面的時候 會有兩個需求

1. 往下滑動就要隱藏 Header

2. 開始上滑就要顯示 Header

但是問題來了，iOS 有一個橡皮筋的功能叫做 Elastic Scroll ，他會造成你滑動到最上方以後 會再反彈

如果沒有寫好的話，明明就滑動到最上方還是隱藏 Header (明明 Chrome 跟其他瀏覽器不會)….

為了兼容這個問題 我們以 Vue Use 為例子做一個範例

裡面其實只有 directions 跟 y 最重要

因為我們判斷它是否為回彈事件為 判斷他 nextY ===0 代表他就在最上方

不用管他是什麼事件，這樣就可以解決了

這裡說明一下 為什麼使用這方法而不用 touchmove preventDefault 是因為 有可能舊版本的 safari 沒有這個 event…
也不想要考慮太多相容性 就先保留這個行為 但是讓結果相同

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

import { useScroll } from '@vueuse/core';
import { ref, computed, toRefs, watch } from 'vue';

export default function useHeader() {
  const showHeader = ref(true);
  const winComputedRef = computed(() => window);
  const { arrivedState, y, directions } = useScroll(winComputedRef);
  const { top: toTop, bottom: toBottom } = toRefs(directions);
  const { top: topArrived } = toRefs(arrivedState);
  watch([toBottom, y], ([toBottomNewValue, nextY]) => {
    //nextY to prevent iOS safari elastic scrolling
    if (toBottomNewValue && nextY !== 0) {
      showHeader.value = false;
    } else if (nextY === 0) {
      showHeader.value = true;
    }
  });

  watch(
    () => toTop.value,
    (newValue) => {
      if (newValue) {
        showHeader.value = true;
      }
    }
  );
  return {
    showHeader,
    topArrived,
    toBottom,
    toTop,
    y,
  };
}

這個問題主要要考慮的是 iOS 以及 safari 版本不同 有可能有不同的事件 所以最好是找一個比較符合的解決方法

其他解法(要確認使用者大部分 Device 在什麼版本)

1. touchmove prevent

2. 使用 debounce 限制 scroll top 抓取事件 delay 50 ms 之類 然後判斷高度 可以使用 lodash.throttle 套件

Reference

Vue Use

此篇文章是介紹 SEO Prerender，可能很多人會大概會想說聽過 Server Side Render 以及 Client Side Render ，
Prerender 簡單來說就是預先將網頁 snap shot 起來，等到搜尋引擎來的時候 就不需要當場在渲染頁面

以下是這三種方法的介紹以及優缺點

我這裡總結一下
就是 Prerender 以及 Server Side Render 都是後端產生的 html 差異在

Prerender 是預先拿取 snapshot 的檔案回來，效能比較好但是比較不即時
Server Side Render 是當下的 Request 才開始渲染網頁，比較消耗效能 但是比較即時

所以就看大家怎麼選擇

Asp.net 實作 Prerender

我們這裡會稍微介紹一下 怎麼使用 Asp.net 實作一個 Prerender 檢查的 Dll ,

首先我們要先知道在 Request 的什麼階段比較適合將 Snap Shot 的檔案回傳給搜尋引擎

那以下是我們的介紹

Request Flow

我們先來介紹當一個 Request 進到 IIS Server 中的生命週期

簡單來說 IIS 上面有一些預先檢查 EX: URL Rerewrite . 當這些檢查如果都不符合的時候
就會開始進到 Asp.net 生命週期，所以在做 Prerender 的檢查應該使用 Application Module
在 Request 還沒有進到 Asp.net 驗證以及 Routing 之前判斷，如果根據某一些 User Agent 就應該將預設好的 html
回給 search engine

sequenceDiagram
    User->> IIS: Request
    alt Rewrite not Match
        IIS->> Application Module: Request
    else Rewrite Match
        IIS->> User: Return the destination
    end
    alt Check User Agent
        Application Module->> Route: Enter into Routing
    else User Agent Match with Bot And Static File Exist
        Application Module->> User: Return the static file To User
    end

Application Flow

這是 ASP.NET 應用程式生命週期流程圖 這裡不多加詳述
剛剛說的檢查是否為 Search Engine 應該在 BeginRequest 就檢查，避免做太多不必要的檢查之類
因為看到 MapRequestHandler 代表就是已經進到 Route Config 裡面了

graph LR
    A(BeginRequest) --> B(AuthenticateRequest)
    B --> C(AuthorizeRequest)
    C --> D(ResolveRequestCache)
    D --> E(MapRequestHandler)
    E --> F(.....)

使用 BeginRequest 實作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

using System;
using System.Web;

public class Global : HttpApplication
{
    protected void Application_BeginRequest(object sender, EventArgs e)
    {

        bool isRouteRequest = RouteTable.Routes.GetRouteData(new HttpContextWrapper(Context)) != null;
        // 判斷條件
        if (isSearchAgent(Request.UserAgent.ToLower()) && isNotStaticFileOrAjaxRequest() && isRouteRequest)
        {
            //回傳SnapShot檔案
        }
    }

    public bool isSearchAgent(string userAgent)
    {
        string[] searchEngineUserAgents = { "googlebot", "bingbot", "yahoo", "baiduspider", "yandex" };

        bool isSearchEngine = false;
        foreach (var searchEngineUserAgent in searchEngineUserAgents)
        {
            if (userAgent.Contains(searchEngineUserAgent))
            {
                isSearchEngine = true;
                break;
            }
        }
        return true;
    }

    public bool isNotStaticFileOrAjaxRequest()
    {
        // 檢查是否為AJAX請求
        bool isAjaxRequest = string.Equals(Request.Headers["X-Requested-With"], "XMLHttpRequest", StringComparison.OrdinalIgnoreCase);

        // 檢查是否為靜態檔案存取
        string fileExtension = System.IO.Path.GetExtension(Request.Url.AbsolutePath).ToLower();
        bool isStaticFileRequest = fileExtension == ".css" || fileExtension == ".js" || fileExtension == ".jpg" || fileExtension == ".png" || fileExtension == ".gif";
        return !isAjaxRequest && !isStaticFileRequest;
    }
}

上述的例子是直接在 global.asax 裡面直接判斷，也可以使用 modules 來達到這件事情。

下面是常見的搜尋引擎的 UserAgent

結論

使用 Prerender 好處在於說可以自己決定要回傳什麼時候的 SnapShot 檔案給搜尋引擎使用，

但是反之也要注意更新檔案的頻率。

在 Composition Api 使用 Pinia 做狀態管理的時候,官方網站上面有寫說

寫一陣子後才想到有遇過幾個問題

怎麼樣算是沒有 refs or reactive , 並且怎樣寫才是正確的呢?

先看一下我們定義的 State

以 number , array ,object 為例子來講解一下我們使用的方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

import { defineStore } from 'pinia';
export const useCounter = defineStore({
  id: 'counter',

  state: () => ({
    n: 2,
    decrementedTimes: 0,
    numbers: [],
    data: {
      user: 'joseph',
      age: 13,
      profile: {
        role: 'aaa',
      },
    },
  }),

  getters: {
    double: (state) => state.n * 2,
  },

  actions: {
    increment(amount = 1) {
      this.n += amount;
    },
    setupUser(userName, profile) {
      this.data.user = userName;
      this.data.profile.role = profile;
    },
    pushNumber(number) {
      this.numbers.push(number);
    },
  },
});

Sample
我們用三個層面來探討

1. Counter Store 建立實體

1
2

import { useCounter } from './stores/counter';
const counter = useCounter();

2. Counter Store 解構方式取出 (錯誤方法)

1
2
3
4
5
6

const {
  n: unRefCounts,
  numbers: unRefNumbers,
  data: unRefData,
  double: unRefDouble,
} = useCounter();

3. Counter Store 解構方式取出 (StoreToRefs)

1

const { n, numbers, data, double } = storeToRefs(counter);

Counter Store 建立實體

這個最不需要討論 因為建立實體後 可以調用所有的 method 屬性跟 Getter 都會是雙向綁定的
只是缺點是 每次使用都要 counter.xxx counter.xxx 有點麻煩

1
2

import { useCounter } from './stores/counter';
const counter = useCounter();

Counter Store 解構方式取出 (錯誤方法)

因為在 ES6 上面建立的解構的方法 所以一開始大家都會想要用這種方法片段的取出值

1
2
3
4
5
6

const {
  n: unRefCounts,
  numbers: unRefNumbers,
  data: unRefData,
  double: unRefDouble,
} = useCounter();

大家可以看到 標黑色的部分 因為單純的 number or string 這些都是 call by value 所以透過解構的方法並不會雙向綁定
但是物件跟陣列是會的

為了避免混用 我們還是少用這種方法

Counter Store 解構方式取出 (StoreToRefs)

這是官方推薦的方法

1

const { n, numbers, data, double } = storeToRefs(counter);

這樣就可以把 n 直接做雙向綁定 只要操作的時候使用 n.value ++就可以

但是要注意一件事情. storeToRefs 出來的值 如果再將其中的子屬性 assign 出去也不會有 two way binding 的效果

1

const userName = data.value.user;

那如果我們還是希望可以有子屬性有 two way binding 的效果可以參考以下範例

ex: 使用者的資料

1
2
3
4
5
6

data: {
        UpdateTime: 0,
        Name: "",
        Status: "Active",
        Profile: { Email: "", Phone: 0 }
    }

因為有可能不是每次都要把所有使用者資料撈出來，會遇到一些寫法問題 請參考範例

Code Sample

Pinia 存取的結構:

這裡有發現有幾種寫法就算 Pinia 狀態有改變，畫面上面的值沒有跟著連動

Not Working Sample

1. rootStore.data.Status
   直接把 rootStore 的屬性取出是無法做 reactive

2. data.value.Profile.Phone
   透過 storeToRefs 拉出的屬性值注意只有屬性值不會 reactive

3. rootStore.phoneNumber
   直接把 rootStore 的 Getter 取出是無法做 reactive

為什麼會這樣呢?

後面有回頭去看 Vue 3 reactive 用法

其實 reactive 是使用 proxy 做的

其實他文件上面有提到兩點很重要的

• When you assign or destructure a reactive object’s property to a local variable, the reactivity is “disconnected” because access to the local variable no longer triggers the get / set proxy traps.
  意思是當你把 reactiv object 的屬性值單獨取出他就會 disconnected 因為 value update 不會被 proxy 的 get set 觸發到
  這就是對應到剛剛的問題 1 2 3
• The returned proxy from reactive(), although behaving just like the original, has a different identity if we compare it to the original using the === operator.
  當你重新把 reactive object 在 assign 出去 他會視為是不同的物件

reactive work in vue

How to Fix It?

1. 使用 getter method 透過 storeToRefs 取出單一的屬性值
   Getters are exactly the equivalent of computed values for the state of a Store.
   Reference
2. 單獨把屬性值透過 computed 包裝起來
3. 使用 watchEffect

以下是 working 的 sample

1
2
3
4

const { data, phoneNumber } = storeToRefs(rootStore);
const computedTime = computed(() => {
  return data.value.UpdateTime;
});

為什麼要特地說明這個呢? 因為在 vue 3 中 會很常使用 composition api, 並且把一些共用的邏輯抽成 composeble 的 code
相對 Pinia 也是 可能會需要單獨取某一些值出來，所以特地記錄這塊