Host a Parse or Go Firebase?
這篇獻給正在使用 Parse 但對於 Firebase 尚未熟悉的開發者，提供一些雙平台上的差異與比較，也提供一些可能轉移設計的發想，希望能幫助到開發者判斷該如何選擇後 Parse 時代的 BAAS 服務。(如果您已熟知 Firebase 或是資料庫高手，那就不用往下看了 XD)
Data Saving
Parse: 在使用 Parse 的服務時，雖然底層是的 MongoDB，但卻巧妙的實作了 Schema Management 的功能，因此有一種使用傳統 Rational DB 的快感(?)。使用上會有預先設計好的 Class, Column Name & Type, Permission…受限於提供的資料型別，設計上也會偏向水平化。
Firebase: 在 Firebase 上，整個 DB 資料是以一個 JSON Root Node 的方式統合起所有的資料，沒有預設的 Schema 也沒有 Column Definition，資料也可以大方的以更有視覺效果(?)的樹狀方式儲存，沒有太大的限制。(其實還是有合理性限制: A child node’s key cannot be longer than 768 bytes, nor deeper than 32 levels. 並且 guild line 中也不建議使用過度的 nest design)
Migration:
- 在 Firebase root node 的第一層 child 對應到 Parse class definition
- 在 Parse 中的每筆資料皆會擁有 objectId，可簡易把 Parse objectId 當作 Key 直接轉移至個 class(first level child) 底下
Data Type
- Boolean, String, Number, Array, Object: 與 JSON Data Type 符合，因此可直接互通使用
- Date: 建議轉成 unix timestamp 以 Number 型別存放於 Firebase，確保資料可被 Constraint 使用，如果有這個需求的話
- GeoPoint: 轉移成 GeoFire，請參閱 https://github.com/firebase/geofire/
- File: 這部分需轉移設計，由於缺少了 MongoDB 的 GridFS 服務，勢必需要將檔案放到 3rd-party 服務，聰明的 Google 早就幫你把這個坑挖好放在新版 Firebase 中了，左邊 Storage 按下去，開始跳進 Google Cloud Storage 吧，嗝 ~
- Pointer & Relation: 這部分整個 Parse 的優點就必須自己實作了。若是可容忍非一致性的資料，可以直接建立複本於該資料底下。若是必須要維持一致性，那就需存放對應資料的 key 並且自行處理 data modeling。(p.s. 此處所指的一致性指的是資料更新時的複本資料一致性，並不是 NoSQL 的 Consistency )(p.s. 可參考 Firebase 提供的轉移設計建議 https://firebase.google.com/support/guides/parse-ios#differences-with-parse-data)
Data Retrieving
Parse: 使用 Parse 時，可肆意的使用各式的 Constraint 來取得資料。當然也會有其限制(Slow Query, Query Limit, Count Limit…)，但是光他可以幫你自動 Manage 資料庫 Index 這件事，就可以先叫他一聲爸了。(p.s. Self-hosted 的 ParseServer 就沒這特異功能了，已經建議了但應該短時間內無法實現)
Firebase: 由於資料庫設計與特性的不同，Firebase 僅提供 Filter, Sort, Limit 的功能來作為資料讀取的一些選項，index 也需要自行設定。某程度上其實較不利需要多重使用、多樣性條件資料的存取。建議完整的了解之後才進行設計轉移。https://firebase.google.com/docs/database/rest/retrieve-data#section-rest-filtering
p.s. 更多轉移的設計方法，其實有點類似 RDBMS 轉移到 NoSQL 的一些挑戰，需要讓設計符合不同特性的 DB，這部分需要更多建議的話歡迎私底下交流討論。
Data Permission Control
Parse 提供了 User Revocable Session，並讓 Data 提供了 Row Level 的 ACL 設定(Self-Hosted Parse 提供到 Class Level)，就像是把每筆資料都貼上使用權限的標籤一樣，使用上相當直覺。
Firebase 中，則以 rule 的設計來規範節點的權限控制或是資料的驗證，比較像是在資料節點上駐紮衛兵的感覺，建議完整的閱讀此特性之後再進行轉移設計。https://firebase.google.com/docs/database/security/securing-data#structuring_your_rules
CloudCode & Job
Firebase 上目前並沒有特定的或建議的方式來做 CloudCode 的 Backend Logic，所以必須改變設計。Trigger 和 WebHook 也是需要另外設計。
Firebase 雖然並沒有提供原始的方法用來做 Cloud Function，但卻內建了 Transaction 的特異功能，可能可滿足部分開發者的 API 需求。https://firebase.google.com/docs/database/android/save-data#save_data_as_transactions
Cloud Job 的部分，可以透過 zapier, firebase-cron 等外部整合來實現。
p.s. 這部分轉移設計的方法眾多，需要較多原產品的特性，歡迎私下交流討論。
Auth, Hosting, Config, Notification, Analytics
這些部分雙方都提供了相當類似的功能（撒花轉圈），如果是轉移服務的話還是得花點功夫。
Firebase Database 的獨到之處
Realtime: Firebase 提供了 DB 的即時性需求，某種程度上可以理解成即時監聽遠端資料庫的更動，這提供了相當的可能性，Collaborate, Realtime Communication, Instant Interaction…潛力無窮，並且跨平台的提供支援(iOS, Android, Web)。(p.s. Parse 在近期(可能也是晚期)也提供了類似的功能，但還不是很完備。http://blog.parse.com/announcements/parse-server-goes-realtime-with-live-queries/)
Transaction: 能夠運行 Transaction 在 NoSQL 中相當不容易實踐，尤其在此即時性的資料庫中提供，更顯得珍貴，相當程度提供了 Atomical 命令的運行 環境。能讓資料庫更適用在像是金融交易、即時配對…等領域。https://firebase.google.com/docs/database/android/save-data#save_data_as_transaction
結語
- Parse 與 Firebase 有相當多類似的功能，也有其特殊的專長，並無法概括的論定選擇某一個較好，或是用一方取代另一方。以小弟公司正在開發的手機遊戲呆呆戰學校(即將上線請多支持)，還是維持了 Self-hosted Parse Server & Firebase 並用的方案。
- 小弟淺見：Parse 之所以被 Facebook 終結，可能很大一部份原因應該還是因為基底的資料庫，MongoDB 畢竟是一個需要 Commercial License 的資料庫，而以此為基底所提供的可能性商業服務，必然會衍生相當多的問題。至於 Firebase，很顯然的， 就是 Google 讓開發者慢慢一步步踏入後端 Google Cloud Service 的棒棒糖，就看你願不願意含了(我說的是棒棒糖)。
- 小弟近期剛好完成了公司的 Parse 與 Firebase 轉移的工程，如果有讀者需要 Parse 的自架教學，小弟可再抽空寫一篇簡易的心得，需要的話請敲碗。或是可以參考如雨後春筍般出現的 Parse Compatible Service(http://parse-hosting.oursky.com/)，或是轉移到其他不一樣的平台(https://github.com/relatedcode/ParseAlternatives)
簽名檔
Overwatch 攔路豬中路無敵，歡迎單挑。BattleNet: kmshiori@gmail.com
