在後端使用graphql進行了6個月的專案開發後，我權衡了該技術是否適合開發工作流程
首要的graphql是用於api的查詢語言，也是用於使用現有資料來完成這些查詢的執行時。 graphql為您的api中的資料提供了完整且易於理解的描述，並且使客戶有權要求他們確切需要什麼，僅此而已。
它是由facebook開發的，作為其移動應用程式的內部解決方案，後來被開源給社群。
好的務實的資料交換
使用graphql，可以為客戶需要的字段定義查詢，僅此而已。 真的就是這麼簡單。 如果前端需要乙個人的名字和年齡，則只能要求。 該人的姓氏和位址不會在回覆中傳送。
使用資料載入器減少網路呼叫
儘管資料載入器本身不是graphql庫的一部分，但它是乙個實用程式庫，可用於解耦應用程式中不相關的部分，而不會影響批處理資料載入的效能。 引導程式提供了乙個載入單個值的api時，所有併發請求將被合併並呈現給您的批量載入功能。 這使您的應用程式可以安全地在整個應用程式中分發資料提取。
公開資料與資料庫模型之間的解耦
graphql的一大優點是可以將資料庫建模資料與如何將資料公開給使用者分離。 這樣，在設計持久層時，我們可以專注於該層的需求，然後分別考慮將資料公開給外部世界的最佳方法。 這與資料載入器的使用緊密結合，因為您可以在將資料傳送給使用者之前將它們組合在一起，從而為暴露資料設計模型變得非常容易。
忘記api的版本控制
api的版本控制是乙個常見問題，通常，通過在其前面新增v2來新增相同api的新版本來解決它相當簡單。 有了graphql
，情況就不同了，您可以在此處擁有相同的解決方案，但是這與graphql的精神並不合適。 該文件明確指出您應該改進api，這意味著向現有端點新增更多字段不會破壞您的api。 前端仍然可以使用相同的api進行查詢，並且可以根據需要詢問新字段。 很簡單
與前端團隊合作時，此特定功能非常有用。 他們可以請求新增由於設計更改而需要的新字段，並且後端可以輕鬆新增該字段而不會弄亂現有的api。
獨立團隊
使用graphql，前端團隊和後端團隊可以獨立工作。 使用graphql具有的嚴格型別化架構，團隊可以並行工作。 首先，前端團隊可以輕鬆地從後端生成模式，而無需檢視**。 生成的架構可以直接用於建立查詢。 其次，前端團隊可以繼續使用該api的模擬版本。 他們還可以使用它來測試**。 這為開發人員提供了愉快的體驗，而不會停止他們的開發工作。
不好並非所有的api都能進化
有時，會因業務或設計而產生一些變化，這需要對api的實現進行徹底更改。 在這種情況下，您將不得不依靠舊的方式進行版本控制。
無法讀取的**
由於經歷了多次，所以有時在使用dataloader讀取資料時，**有時會分散到多個位置，這可能很難維護。
響應時間更長
由於查詢會不斷發展並變得龐大，因此有時可能會浪費響應時間。 為避免這種情況，請確保簡明扼要的響應資源。 有關指導原則，請檢視github graphql api。
快取快取api響應的目的主要是為了更快地從將來的請求中獲取響應。 與graphql不同，restful api可以利用http規範中內建的快取。 正如前面提到的，graphql查詢可以請求資源的任何字段，因此快取本質上是困難的。
結論我強烈建議使用graphql替代rest api。 graphql所提供的靈活性絕對可以取代它的痛點。 這裡提到的優缺點可能並不總是適用，但是在檢視graphql以檢視它們是否可以幫助您的專案時，有必要將它們考慮在內。
如果您有任何意見，請在下面發布。
九個月後的回歸
一直在逃避，只是因為不敢面對前面的困難。懷揣著現有的所謂的小小成就，以為自己是走在前面的，以為自己稍微努力一下就可以比別人厲害，實際上自己一直活在一口小小的井裡，什麼都看不到。當外界的各種資訊砸過來時，總覺得無所適從。丟失了從前的堅定與執著，就容易受到周圍人的影響，不由自主的覺得自己是老人，不再願意...
對帳引擎2個月後的監控資料
對帳引擎已經跑了近2個月，雖然期間瞎改定義跑出了幾個out of memory和其他幾個違反語法的異常，也abort掉了幾個對帳任務，但各項指標看起來還行，總體維持在這個水平，基本沒怎麼上公升，除了定義的快取和定 析結果的快取有點太佔記憶體了以外，基本沒啥大問題 分類 計數名 值.net clr e...
我們想研發乙個機器學習框架，6 個月後失敗了
如何從先期的失敗中找到一條成功之路，本文試圖作了一番 caleb kaiser寫於 2020 年 4 月 24 日。20 年初，我們幾個人嘗試構建乙個端到端的機器學習 ml machine learning 框架。我們從這次嘗試中得到的基本體會是，構建機器學習管道是乙個令人沮喪的 毫無邏輯的體驗，而...