使用 ActiveModel 將資料轉換成模型物件後，我們可以繼續利用 ActiveRecord 來跟資料庫整合，達到持久化資料的效果。接下來我們會修改現有的實作，讓資料可以持久化的被保存起來。

ActiveRecord 是基於 ActiveModel 所以製作的，因此我們只需要少量的重構就可以實現持久化保存的效果。

我們已經初步的完成可以給前端使用的 API 實作，然而在這個狀態下後端並沒有實際保存資料的能力，也有一些不好的實作方式（如：@@items 的 Class Variable）因此接下來我們要整合 SQLite 來作為持久化儲存的機制。

我們目前已經將商品資料的基礎 API 實現，接下來讓購物車新增、移除商品的行為也從前端轉移到後端，這段我們會需要加入相對多的調整來實現。

之前因為使用 Playwright 的方式造假後端 API 造成前端的實際畫面是無法使用，接下來在後端的部分我們要將商品 API 完成一個雛形讓前端可以恢復正常。

在實際的開發流程中，前後端確認完畢 API 的資料結構後會同步進行，我們切分成兩個段落因此看起來是依序處理。

前端的實作目前告一段落，我們將關注放到後端的部分。這次會直接使用 Grape 這個 Gem 來直接搭建 API 伺服器而不使用 Rails，並且刻意使用 Cucumber 來撰寫測試，在正常的狀況下只需要使用跟前端同一份即可，這次主要是展示針對後端可以怎樣實現。

在開始實作後端之前，我們先將原本都集中在 src/App.vue 的程式碼整理一下。這個處理也可以在開發的過程中逐步重構，可以根據現況調整。

透過 Playwright 的 Mock API 機制，我們已經有了非常簡單的後端整合機制，接下來我們要繼續加上結帳的按鈕並且模擬成功跟失敗的兩種情境，讓我們在不依賴後端的狀況下完成一個非常基礎的購物車前端實現。

最近完成公司的 AI 培訓後，開始思考我們說的模型（Model）跟軟體開發中的領域模型（Domain Model）是否有關聯，如果仔細思考，似乎在抽象層面上是類似的。

現階段我們已經具備了新增跟移除商品的機制，然而要跟後端搭配的話就無法避免跟真實的 API 來進行串接，在測試環境中就不會那麼好處理。我們可以利用 Playwright 的 Mock API 機制來模擬我們想要的 API 回應。

延續現有的「加入購物車」功能，我們要繼續加入「移出購物車」的機制，因為原本的設計只是單純的滿足計數，這次還需要實現實際存在的商品列表來反應現實狀況。