owned this note   changed 3 years ago  
Linked with GitHub

DevOps 潮流下的 API First 開發策略 - Andrew Wu

各家講者出來分享自己的經驗多少都有些公司內規和公關要求的限制，有些不方便分享的地方（例如：不要張貼簡報截圖）還請大家多多包涵喔（不然就更多人不敢出來分享了）
DevOpsDays Taipei 2022

講師公告區

  • 簡報: 等我明天上台就會開讀取權限了, 敬請期待
  • 關於我:想了解我的背景的朋友們可以看這邊, 我就把時間省下來講主題內容了

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

歡迎來到 DevOpsDay Taipei 2022 共筆

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

共筆入口：https://hackmd.io/@DevOpsDay/2022
手機版請點選上方 按鈕展開議程列表。

Session 共筆

從這開始

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Role of Architect in Agile Development

  1. 從產品的角度來看
  • 先做好 API，再來做好 Product
  • 產品或功能要模組化，API是首要考量到的事情，才能像堆積木一樣快速組合出想要的東西（案例：台積電
  1. 從公司
  2. 從團隊

如果先做好產品再回頭做好
這樣很容易產生很多技術債

工程團隊: 走向這一步，需要克服的難關

  1. 大規模的 API / 服務 治理 能力
  2. 大量開放 API 你會需要的 API 管理 (尤其是資安相關) 能力
  3. 內部團隊需要具備用 API 溝通協作的能力
  • 參考: AWS 2002 年發布的 API 授權 備忘錄
  • 評估: 內部團隊是否有能力 "設計" 良好的 API ?
  • 評估: 內部團隊是否有能力 "維運" 好 API ?
  • 評估: 內部團隊是否有能力 "運用" API 解決問題 ? (黑暗面: 你不能再靠共用 DB / 檔案來協作)
  • 思考: 如果團隊之間完全沒辦法用 API 溝通，有沒有可能分工的方式就已經不對了? (微服務: 服務邊界)

當目標是在定義 Contract 時，將能簡化的東西簡化，透過降級開發，避免殺雞用牛刀，類似於以最小可行性產品，將關注點放在解決方案上

給 Andrew 的 feedback

在這邊留下你對這 session 的想法

車票和識別證的比喻真的很好
Mark_Mew

很棒的分享，列出準則之外也搭配很有即視感的範例去解說，很感謝！

內容很充實，有範例輔助更容去了解內容，感謝您的分享～～

安德魯的分享從沒讓人失望

感謝各位的回饋，感覺今天在台上站了一小時是值得的 :D
Andrew Wu

想問 Andrew 的問題

在這邊 Q & A, 請留下你的問題, 會後一周內我都會抽空上來回覆

投影片中 API 評量指標中有一項是「創意」是甚麼意思？
Mark_Mew

主要是衡量使用你 API 的場景，有沒有出乎你意料之外的應用? 這代表了多元性的指標。我瞎掰幾種可能的情況，比如 google map 推出了一系列 API, 結果寶可夢拿去做成遊戲，這可能是 google map 當時意料之外的應用, 就可以歸類為 "創意" 的指標。

簡報時講者有提到曾經誤用 API Gateway
導致 API Key 量大到不好管理
方便詢問後來這部分的調整方式是甚麼嗎？
目前我們公司也是使用 AWS API Gateway 做串接
現在是一個系統兩個 API Key，一個測試用，一個正式用
擔心未來會不會不好管理
Mark_Mew

APIKEY 並不是量少就好管理，第一件事應該先看你有沒有發出不必要的 KEY … 造成不必要的 KEY 管理任務。

我後面會舉例 "車票" 跟 "識別證" 的差別，就是如果你用錯管理模式，你可能會發出好幾倍的 KEY …, 解決方式當然是正確的使用他 XDD

我們會需要著重 KEY 管理的另一個原因，是因為我們是 SaaS, 一套系統, 一組 API, 可能有多個客戶 IT 需要用來存取他們自家資料。沒有妥善管理的話，可能導致客戶拿錯資料，那問題就大了。你們沒特別這些考量的話，分測試跟正式用這樣沒問題的。
Andrew Wu

在設計 API 的時候
如果是要串接 SAP 的資料
要怎麼設計比較好
SAP 的資料量比較龐大
在 SAP 串接時常使用 Web Service 串接
容易遇到網路超時就 timeout
Mark_Mew

如果你是呼叫端，碰到 timeout 能做的有限，就是調整 http client 想辦法撐過去而已。如果你是自己的 API 背後會呼叫 SAP 的 API, 那你得參考一下非同步的 API 設計方式..

簡單的說就是先回應 "收到了", 留下 job id.. 背後再去打 c。等到 SAP 那端都回應了你也處理好了，再用 webhook 回呼元呼叫端…

會麻煩一些沒錯，不過這才是合理的做法。HTTP connection 是很佔資源的, 盡可能降低連線持續時間才是上策。避免不了的長時間等待，就要考慮 async / webhook 的設計了。我投影片介紹的那本 "API Design Patterns" 就有一個段落在介紹這個，可以參考看看。
Andrew Wu

可以分享一下從資料庫交易的方式，改成 API 的過程嗎，
面臨什麼困難，要如何解決，可以舉個實例嗎，感謝。
這個問題我也想問，後續我的專案中，也有評估資料庫交易要改成API，再麻煩老師分享一下實例，感謝～

在場外聊天時也有人問到。如果單純的是 CRUD，那就找現成的 code gen 就好了，例如用 EF core + ODATA 就好，別自己刻。
如果有包含商業邏輯，建議用我 slide 說明的方式分析一下到底該開那些 API 出來再來開發。
Andrew Wu

請問可以分享 API 的定義策略嗎？PM 招集前端和後端團隊打一架，誰贏誰說得算，這樣可以嗎 🤭

我常用建築師來比喻這類設計問題。用一堆規範可以做出不會犯錯的設計，但是你也不會覺得驚豔。如果 API 對她的要求是能正常運作就好，的確打完架看誰贏就夠了 (咦?) XDD, 如果你把她當產品看待，那就要講究設計風格跟背後的架構了。我個人頃向讓有經驗的人統一操刀，當你 API 涵蓋範圍越廣的時候這些 API 的設計才會有一致性。
Andrew Wu

API 仰賴規格的穩定性（-x4+5x3-7x2+3x+1），胃口養壞的商業情境後來變更了一個"關鍵資訊"（-x3+5x3-7x2+3x+1）又該如何應對…

API 相容問題沒有好選擇，就是強制執行而已。碰到 breaking change, 你能做的是同時維持兩種版本都要能正常運作。我六年前有寫過一篇相關的文章，可以參考看看:

API & SDK Design #3, API 的向前相容機制
Andrew Wu

會後提問

Q：會議中提供API First中, 以poc mock API Contract除了提供給fornt與backend平行實作外，也透過QA、開發、測試等其他人一同審視是否有遺漏，
請問在審視階段之前，所有或核心的QA、開發、測試都會參與有關服務流程、邏輯的workshop嗎？若沒有是否會有盲點
A：在具有長期利益、主要利潤來源或核心服務會套用此方式
Q：在API治理上，因API已開放且已有協力廠商提出破壞性變更，如何應對？
A：以商業協商為主，因API規範還是面向大多數，單一廠商提出並不會納入考量，除非多數廠商反應則會進行分析
Q：提出大量列舉會造成效能問題，另外也提供API對外開放為單一資料執行，但協力廠商應會有大量寫入的要求，請問在內部依然維持單一執行還是會透過記憶體資料庫來儲存，再一次執行
A：內部透過Queue儲存批次寫入要求，並回應使用者已收到資料，當收集完畢後並異步批次執行完再發送通知使用者已完成
Q：在長服務鏈中如何克服一致性問題、交易失敗、資料rollback
1：重設思考流程正確性？是否存在更短的路徑？
2：配合會議中提供的狀態機，重新思考交易是否可切割為數個強一致性交易，透過異步更新對應狀態？

感謝好心的朋友，幫我把在場外聊了 90 min 的內容 po 上來 :D
Andrew Wu

tags: DevOpsDays Taipei 2022
Select a repo