はじめまして。株式会社 PRUM 的工程師人見。
我每天都會整理並分享在程式學習與實務中容易卡關的重點，
以及工作中常發生的「落差」。
若能對某些人有所幫助，我會很高興。
9 成工程師新手會卡關的「第一道牆」 即使如此也想做出 App - 按鈕背後正在發生的事
前言
前一次，我們用 Google Apps Script（GAS）做了一個出缺勤確認 App。
輸入姓名 → 按下「參加」或「不參加」→ 結果被保存 → 顯示列表這裡請稍微想一下。我們輸入資料並按下按鈕後，
看起來結果就被保存了。但其實，和 App 的互動
在按下按鈕之前就已經開始了。
這次就以前一次做的 App 為題材，
App 背後到底發生了什麼
讓我們稍微窺探一下。這不是要寫很多程式碼的一回。
我們會看看在「按下按鈕就會保存」的背後，畫面和 App 之間到底是怎麼互動的。
其實，從打開 URL 的瞬間就已經在對話了
前一次做的 App，你最先做了什麼？
按下參加按鈕？
其實不是。在那之前，你先打開了 App 的 URL。
這件事太理所當然，所以常常不會特別意識到，但第一個互動就在這裡發生了。
使用者對 App 說：
請顯示畫面接著 GAS 會回應：
好的，請看大致上就是這樣的感覺。
想像起來像這樣：
我們平常只是隨手打開 URL，但其實在這個時點，
和 App 的對話就已經開始了。
Web App 是由「請求」與「回應」構成的
在 Web 的世界裡，這個「請求」與「回應」都有名稱。
請求 → Request
回應 → Response
這些詞聽起來好像很難，但本質上就是對話。
例如在餐廳裡，
我要漢堡排
↓
好的
↓
讓您久等了對吧。App 也是一樣。
當你打開 URL 時，就是在進行：
請給我畫面
↓
回傳畫面這樣的對話。而當你按下按鈕時，
又會發出另一個請求。
按下參加按鈕時也在對話
在前一次的出缺勤確認 App 裡，按下參加按鈕的瞬間，
又會發生一次互動。這次的請求，
不再是「請顯示畫面」這種要求。
「人見」先生點了「參加」。
請用這個內容保存。像這樣的請求。對應地，GAS 會回應：
已保存。
更新列表。但實際上在背後，運作方式如下圖所示。
這就是 Web App 的基本動作。
按鈕本身並不是在保存
這裡換個角度看。到底是參加按鈕在保存嗎？
當然不是。按鈕只是一個觸發點。
按鈕做的事情是：
請用這個內容保存真正執行保存的是 GAS 端的程式。
畫面
↓
Request
↓
GAS
↓
保存處理
↓
Response
↓
畫面也就是說，與其說：
因為按下按鈕所以保存了
不如說：
因為按下按鈕，才把保存的請求送到 GAS
這樣更接近事實。
理解這一點後，對 App 的看法會有點不同。
畫面是使用者操作的地方。GAS 是在背後處理的地方。
試算表是保存資料的地方。各自都有自己的角色。
請求中包含著資料
那麼，按下參加按鈕時，GAS 收到了什麼呢？
例如，畫面上輸入了以下內容：
姓名：人見
回答：參加在這種狀態下按下參加按鈕時，GAS 大致會收到
下面這樣的內容。
姓名是「人見」。
回答是「參加」。
請保存這些內容。也就是說，請求不只是單純的訊號。
它帶著必要的資料，把內容傳給背後的處理程序。
接收到這些資料的 GAS，會把它寫入試算表。
所以之後才可以在列表中確認。
這次是保存到試算表
前一次的出缺勤確認 App，是把試算表當作保存目的地。
瀏覽器
↓
GAS
↓
試算表使用者從畫面輸入。GAS 接收內容。
保存到試算表。再把保存結果回傳到畫面。
只看流程的話，非常簡單。但其實，
這已經非常像 Web App 的運作方式了。
正式的 Web App 會保存到資料庫
一般的 Web App，保存位置多半不是試算表，
而是資料庫。
例如：
- LINE 訊息
- Amazon 訂單紀錄
- Instagram 貼文
這些資料都會保存到資料庫裡。
結構上大致像這樣：
把它們並排來看，角色其實很相似。
角色正式的 Web App這次的 GAS App顯示畫面的瀏覽器瀏覽器處理的 App 端程式GAS保存的資料庫試算表當然，正式的 Web App 會更複雜。
安全性、權限、資料設計、伺服器架構等等，需要考慮的事情很多。
不過，最先想理解的大方向是一樣的。
輸入
↓
送出請求
↓
在背後處理
↓
保存
↓
回傳回應
↓
顯示到畫面上這次的 App 是用試算表來代替原本應該由資料庫負責的保存處。
因此不需要建置環境，也能體驗 Web App 的基本流程。
那麼，直接編輯試算表不就好了？
這時候，可能有人會這樣想。
那一開始就讓大家一起直接編輯試算表，不就好了？
確實，有些情況這樣就夠了。但實際運作起來，
往往會出現一些意想不到的小麻煩。
- 不知道該在哪裡輸入
- 每個人的輸入格式都不一樣
- 不小心刪掉別人的列
- 用手機時不太好操作
- 想找的資訊一眼看不到
試算表很方便。但若要讓所有使用者直接編輯，
有時還是會有些不順手。
所以，對輸入的人只顯示必要的畫面。
輸入姓名
[參加]
[不參加]使用者只要看這些就好。背後則由 GAS 幫忙整理並保存到試算表。
管理者則可以直接從列表確認。
光是這樣就方便很多了。
即使很小，也確實是一個 App
這次做的出缺勤確認 App，並不是大型服務。
但它有以下這樣的流程。
打開 URL
↓
顯示畫面
↓
輸入
↓
按下按鈕
↓
在背後處理
↓
保存
↓
回傳結果這就是 Web App 的基本概念。
當然，如果要做出成熟的服務，還需要更仔細的設計。
但如果一開始就想把全部都理解完，往往會很難真的動手。
先建立這樣的感覺就好：
畫面和背後正在對話
輸入的資料會傳到背後
背後的處理負責保存
只要有了這種感受，App 開發就會變得親近許多。
結語
一開始，我以為是：
按下按鈕就會保存
但其實，在那之前對話就已經開始了。
打開 URL。顯示畫面。按下按鈕。送出資料。
GAS 處理。保存到試算表。回傳結果。
平常只是看不見而已，但在 App 的背後，
這些互動一直不斷重複著。
這次的出缺勤確認 App 非常小。
但它能接收別人的輸入、在背後處理、保存，
再把結果回傳。
光是這樣，就已經是一個能「讓別人的工作變輕鬆」的機制了。
不需要一開始就做大型 App。
先從讓身邊的人某個小困擾，
稍微變得輕鬆一點開始就夠了。免費、建置環境也少，
能體驗到這些，我覺得這就是 GAS 的好處。
下一次，為了把這個出缺勤確認 App 做得更實用一些，
我會思考要怎麼讓它更接近「能用的 App」。
PRUM 的工程師中，95% 以上是從無經驗錄用的。
如果你對我們公司有興趣，歡迎來看看。
原文出處：https://qiita.com/hitomin_poke/items/621a19d6a1a6500eaca6
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
