在前面的實作中我們將前端跟後端分別獨立進行開發，這是很常見的一種方式。然而在 Rails 7 的生態系裡面，透過 jsbundling-rails 可以很輕鬆的整合在一起，接下來我們會使用類似基礎的 ViteRuby 把前端的 Cucumber 測試搬移到 Rails 上重現一次性整合完畢的實作。

我們現在處理好保存狀態的機制，目前還剩下 POST /api/checkout 的實作還沒加入到裡面，除此之外每次開啟前端時也無法看到最新的購物車狀態，我們要來將這些情境處理到可用的情形。

使用 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）是否有關聯，如果仔細思考，似乎在抽象層面上是類似的。