為什麼你該用 Parse 來打造 MVP

前言

小弟前些日子因為朋友介紹開始使用了 Parse 這個平台服務。最近正在進行的創業計劃 Score Master -- 專為國高中生設計的解題平台 也採用了它來進行 iOS App 以及網頁後台的建置。前前後後大概花了 六個工作天 就做出了第一版的服務,這種速度,是我過去任何開發經驗所不能比擬的。

從前,如果你問我說:『我要儘快做出一個 MVP(Minimum Viable Product),有什麼建議嗎?』我可能會推薦 Rails + Heroku。但是現在,如果你想要趕快將服務上線,得到回饋,我會推薦你使用 Parse。

一切都跟速度有關

對於一個新創團隊,每一分每一秒你都在跟時間賽跑,如果能更早釋出產品,用更短的時間開發新的功能,你就更有機會接近成功。

在 Score Master 計劃,第一階段我們需要一個 iOS App 讓使用者可以拍照上傳題目,然後透過一個網站後台讓解題老師上傳解答,並用推播方式來告知使用者解題狀況。

假設你今天用 Rails (or whatever server framework) 的話,一定是先定義 DB Schema 然後再實作登入等細節,因為我們還有 Mobile Client 所以可能還要實作 OAuth 之類的認證機制。等 server 這邊忙完了,iOS 這邊就需要根據事先定義好的 API Documents 來串接。

看起來很普通的過程,但如果萬一中間有一個環節(例如需要滿足一個新的使用情境)變化時,你需要修改 API Docs ,更改 DB Schema ,改寫 server code,最後我們的 mobile client 才有辦法實作這個功能。

更別提,可能還需要整合推播通知,電子郵件的寄送等等平台的整合,整堆東西忙下來,你會發現大部份的時間都花在處理服務的基礎建設。

說好的 MVP 呢?

『東西好了沒啊,一個月都過去了!』,老闆想要試用產品,在後頭使喚著。

你可能攤手說這就是現實,但是出乎意料的是 Parse 把這些繁瑣的細節全部免除掉了。一開始,你的後端是沒有邏輯的,只是一堆資料。登入,註冊以及認證的細節處理都被 Parse 處理掉了。不管是 web 還是 mobile client 都用類似的方式來索取資料。

重要的是 Parse 是沒有 schema 的,所有的資料也在後台一覽無遺,你可以動態而且隨意的新增你想要的東西。這完全顛覆了我過去的開發經驗。後台可以隨著應用程式的設計來即時的做出改變,而不是如傳統的資料庫架構限制了應用程式的彈性。

跨平台以及更多可能的整合

從 iOS/OS X, Android 到 Unity, .NET 你可以想到平台都被涵蓋了,除了語法不一樣,API 全部長得一模一樣,人手不夠的話,一個人負責多平台我都覺得不是噩夢。

過去我一直對這個平台半信半疑的原因是,萬一我要跑一些 cron jobs 或是有些事情一定要在 server 上做怎麼辦?不用擔心,他們提供了一個叫做 Cloud Code 的功能讓你可以設定 scheduled jobs 跟可以被 SDK 任意呼叫的 function。

要寄送 email ?他們也有支援多家的 mail services providers。要發送推播通知?彈指之間就弄好了(相信我,你不會想自己去接 APNS 的)。要做動態的網站嗎?他們也整合了 express 跟幫你 hosting website。

當 Parse 把你該煩的基礎建設的都接好時,你要做的事只有看一份文件而已。為什麼 Parse 適合打造 MVP, 因為新創公司應該要專注於打造服務的體驗,而不是費心於背後的伺服器架構。

結語

移動的不夠快的話,敵人早就把你射成蜂窩了,別讓技術跟速度成為你打造產品的絆腳石,let us Move Fast and Break Things!