leancloud的優缺點？
目前移動應用面臨系統選型，研究了下leancloud後覺得優缺點如下，請大家指教
先說缺點：缺點：
1 系統穩定性，官方聲稱SLA達到99.9%，但實際未知
2 提供了靈活而強大的api，進行了封裝，但缺點是代碼嵌入過深，遷移難度變大
比如ios的查詢必須繼承其Avosobject，而後查詢的寫法如下：
let query = ZLLPhoto.query()
query.orderByDescending("superOrder")
query.addDescendingOrder("createdAt")
query.limit = 5
query.includeKey("owner")
return query
3 人員培訓成本變高
4 而且邏輯都在前端會導致其前端開發量變大，迭代速度可能降低，比如ios，andorid，web都要單獨的寫查詢類，而不同於rest api的統一介面
優點：
1 相當於界面-&>數據，隱去了中間層，後端架構基本不用考慮，可以說是一種革新，不需要考慮用戶量的增長負載均衡、惡意攻擊等因素2 對服務端開發衝擊尤其大
我一個小小實習生都看不下去了。。。怒答：
1.穩定性：核心功能基於 Clojure 開發，論起穩定性，比起你自己用 PHP 啊 Node 啊 Python 啊開發的，不知道強多少倍。
2.介面封裝：提供了標準的 REST API 和在其上封裝的各平台的 SDK 。你完全可以只用 REST API ，而不用他們提供的 SDK 的。
3.可遷移性：現在用它的 REST API ，以後遷移的時候，自己寫一套 REST API 即可。
4.學習成本：你用 REST API ，不就不用學 SDK 的使用了么，學習成本不就是零了么。
5.對後端衝擊：我們後端舉雙手歡迎好么？我是純 Node，還是我建議我們公司的一些產品使用 LeanCloud 的；不就是把標準化通用化的 REST API 讓 LeanCloud 代勞嘛，現在都講 微服務架構 了，要有"去後端"思維；數據的存儲處是心臟，REST API 是管道，各個微服務是器官 (包括 Node 端 、Java 端 、 PHP 端 、 iOS 端 、Android 端 、 Web 端等) 。所以，去掉傳統後端思維吧～這個問題，我覺得我很有必要獻身說法。使用leancloud快2個月了，
11月份進入一家公司做Android，面試沒告訴我沒後台。
開始做的時候才告訴我用leancloud，當時也是第一次聽。數據放在leancloud，整個項目開發就我1個人+1美工。目前項目需求leancloud也都可以實現，比如註冊，渲染，等等之類的，但是對於我來說，我他媽實在是太累了，剛來的時候忽悠我說什麼leancloud這東西用起來特別簡單（有多簡單，會比後台把內部邏輯做好給我個介面簡單嗎？）沒有後台開發就意味著成本降低，如果在成本降低的情況下客戶端還不會增加工作量，那你就想多了，你覺得會有這麼好的事情么？再說了，極個別項目才會使用leancloud，花大把時間看文檔學這個，你換家公司面試你說你會用leancloud這技能有和沒有是一個樣的。說白了，就是太累了，一個人開發所有，連個後台說話的哥們都沒有，再忍2個月到4月初我房子到期我就辭職了，真的憋壞我了，挺壓抑的。# 使用LeanCloud是一種怎樣的體驗
我在自己折騰的幾個練手的小應用中，使用了LeanCloud，在使用過程中還是有不少感觸，總結一下，相信也代表了不少的個人開發者。
相信大部分個人開發者選擇LeanCloud的第一原因，是要快速開發。表面也確實如此，lc提供了各種服務，正所謂專業的人做專業的事，開發者只需要集中精力在前端/客戶端的開發，快的話，可能一兩天就能利用lc搭建起了一個原型，對應用層的開發者（前端/客戶端）來說，似乎一個人就能完成一整個應用，確實很有吸引力。
但接觸下來，還是有一些痛點：
- 後端服務，不能代替後端知識。所以打鐵還需自身硬，雖然Leancloud對各種後端服務進行簡化和抽象，直接通過提供的SDK調用方法就行了，但開發者仍需要掌握後端中的一些通用知識，才能夠玩轉。比如說使用最多數據存儲服務，實際上對應的就是資料庫的概念，開發者首先需要掌握資料庫的基本概念（越深入越好），才能用好數據存儲服務。
- 學習成本。雖然LeanCloud的文檔寫的很好，但我感覺用起來還是很累的，一邊開發另一窗口開著文檔在查找相應的內容。
- 黑盒。Leancloud對開發者可見的，只有文檔了，開發者並不知道調用時發生了什麼，一切順利的情況下還好，如果報錯了，就只能到文檔中尋找答案，如果恰好這時候文檔沒找到答案，就比較悲催了，只能發工單（vip）或者到論壇提問，效率是比較低的。這也是前面說的，開發起來感覺累。這也是缺點之一，如果是自己寫後端服務，碰到問題，可以到搜索引擎中尋找答案。
- 技能的局限性。深入使用了LeanCloud之後，你可能對LeanCloud SDK中各種方法功能很了解，但如果有一天遷移了平台，或者自己寫伺服器，那這部分LeanCloud的知識就沒什麼用了。熟練掌握LeanCloud數據存儲服務的價值遠比不上深入熟練使用MySQL。
- 其他一些局限和不完善之處。用LeanCloud作後端，就得接受這些限制，當然這些限制可能有LeanCloud開發團隊的一些考慮在裡面，但失去了一定自由度。
我覺得LeanCloud的優勢，主要還是快速開發，節約開發成本，但開發體驗的話，就不一定了。
原文鏈接：LeanCloud使用體驗
之前看了一些評論 感覺還不錯 用來開發產品原型 也有一些準備 將來可能會踩坑。只是沒想到來的這麼快
不廢話 上代碼
```
var userQuery = new AV.Query(AV.User);
userQuery.equalTo("level", "10");
var query = new AV.Query("Diary");
query.addDescending("date");
query.matchesQuery("user", userQuery);
query.limit(10);
query.find().then(function(results){
response.success(results);
}, function(err){
response.error(err);
});
```
查找 level 為 10 的用戶最新的10條日記。 但是結果總是和數據對不上，開始以為索引的問題，後來仔細看文檔才發現
&> 如果你想獲取對象，這個對象的一個欄位指向的對象需要另一個查詢來指定，你可以使用 $inQuery 操作符。注意 limit 的默認值是 100 且最大值是 1000，這個限制同樣適用於內部的查詢，所以對於較大的數據集你可能需要細心地構建查詢來獲得期望的結果。
當時我們 level 10的用戶有接近3000. 所以查詢結果只是顯示了前100個用戶的最新10條日記。。。這樣導致很多邏輯變得很複雜，本來一個查詢搞定的東西我得分頁循環查詢再組合結果。。
這不能說是BUG 但是各位用之前自己仔細想想吧。。 我是趕緊老老實實自己搞API去了。。
我覺得沒必要討論優缺點，那些都是次要的。想樓上說的一個月掛了3次，一點都不誇張，指望其提供穩定可靠的服務？只能呵呵了。
另外，尤為討厭 Leancloud 的工作人員前來洗地，表達的意思總能透出一種，再怎麼不穩定，也比你自己搞穩定的意味來。
如果只是需要 IM，已經有很多靠譜的選擇了。如果全部服務都使用 Leancloud，那就等著後悔吧。
如果執意要選，等你哭的時候別怪我沒提醒你啊用過的來答一個，主要有以下一些缺點：
- 1000 的查詢限制，導致在數據多到一定程度之後簡單的查詢寫起來都很蛋疼。
- 索引，超過 10000 條的表不能建索引，這是什麼鬼，索引就是用來優化大數據量下的查詢速度的，你告訴我數據多了就不能用，這是什麼邏輯呢。
- 不能 GroupBy，再加上那個查詢限制，真是誰用誰知道。
- 雲端代碼在本地不方便調試，要布置到測試環境可以，這個周期太長，效率好低，也許是我水平太低。
建議，還不如提供傳統方式的 mysql 雲端引擎呢。
一個月掛了3次，我只能說呵呵噠，粉轉路人！
Android開發 ，只說Android端的事 。
LeanCloud Android SDK的混淆規則不知道從哪個地方抄過來的，見下面。
Android SDK 常見問題及解答看來LeanCloud的程序員對這個根本就不上心的樣子，這份混淆規則只能用垃圾來形容
這是個必死的項目，管你是清北畢業還是Google高工創業團隊。
facebook拋棄baas 不是因為技術和投入上不去，而是因為這玩意商業邏輯上玩不通。baas的本質只是將後端的活交給了前端干，其實並沒有節約成本反而增加了額外的伺服器成本。而且大公司是不可能把數據交給你保管的，人家偷稅漏稅的記錄保存在你這，你想不想讓人活？好，就算你有那麼強的實力，你能24小時上班保證服務不宕機？ok你能不宕機，你能保證前端人寫的後端的代碼架構合理 新人進來也能維護而不是直面一堆亂麻？圖樣。倒吧，就這樣。呃呃呃，原來大家都是用他們家的資料庫啊，我還以為都用的即時通訊呢，拿來做做通訊管道還是很不錯的，成本很低，比自己建websocket方便多了，丟數據也沒什麼，更何況不是經常丟
最近接觸過幾天。JAVA要在本地自己再實現一套非空判斷。煩。
我跟你說，是不得已才去用它，僅此用它的免費和做演示方便，API文檔寫得也不好，要去摸索...
我說下LeanCloud的IM吧，即時通訊服務，相比融雲，極光，環信，網易雲信等，更加簡便，而且自定義性最高，且完美兼容Material Design設計。我看了各家的文檔和Demo，最後選用了LeanCloud集成在線聊天服務。
LeanCloud的出發點很好的,但是產品設計做的不好.
1.api封裝的不合理,有的地方用著很彆扭,看著不像是基於開發者用戶角度搞出來的.2.安全問題,對於應用密鑰安全一直沒有好的方案.3.數據問題.數據查詢是最大的問題. 一個是查詢次數的限制,另一個是連表查詢的限制. 效率十分的低. 譬如連表最終轉化成為 1XN 的查詢, 還有事務也不支持.如果做簡單的應用很方便,可以使用.做複雜應用就不行了,用了幾個月leancloud的雲資料庫,最後還是切回mysql了關於BAAS
BaaS 服務的興起減少了後端的工作量，這意味著未來大批後台程序員要失業么？
另外如果操縱nodejs得法幾乎可以做任何事
後端技術 Node.js VS Python ？
甚至大數據用python做prototype nodejs再提升三成的性能（跑hadoop spark的nodejs性能快python操縱的3成 和java scala的不相上下）
凡鄙視javascript的都是沒入門的 不真懂javascript裝懂亂講的
知乎專欄
上面鏈接圖裡有4，5個地方需要改進 你找出來 js就入門一半了
如果teamleader對js認識深刻完全可以做到小白一周就可以參與大規模開發
且代碼可維護性高
具體公共BAAS用否leancloud 偶給倆標準
1.是否穩定
2.特殊情況需要徹底遷移成本的大小是否可接受
按目前的技術進步的程度 一個人利用開源和雲全javascript 寫出 負載均衡自動伸縮抗 各種攻擊的 支持http+socket 適用99%的業務場景（除了那些頂級web大站）的私有BAAS
毫無問題
這種技術型的產品應該分成三個部分來看：
1.產品本身
比起租一個阿里雲的VPS，費用要便宜很多。LeanCloud雲引擎最低配30元/月（無休眠運行），阿里雲入門級的主機也要93元/月。（開發期間用有休眠限制就足夠，完全免費。）
如果業務邏輯只涉及到數據讀寫，可以完全不用寫後台。
2.開發文檔
這個是槽點比較大的地方，很多人都說文檔寫得差。其實，如果拿其他的API文檔跟它比，它算是寫得不錯的，能看懂，出錯率也很低。
關鍵問題是新手需要用戶引導呀！
有很多概念不是先天就有的，直接丟API文檔過來看，自然是很艱難。
建議官方弄個上手的視頻教程，這樣就不會有人說你們文檔差勁了。
3.開發社區
官方對這個完全不重視，提問題都要發工單。這導致的開發中遇到的所有問題都得看文檔解決，幾乎不能從其他地方找到解決方案。
好的社區對產品是一項財富，技術傳播跟技術本身具有同等價值。
弄個論壇，維護幾個開發者的QQ群還是很有必要的。
——————
LeanCloud我踩過的一些坑：
1.一定要用CQL查詢，不要糾結效率問題，好寫才是最重要的
2.data-urlencode的數據一定要encode一下
——————
關於30元/天，還是30元/月的問題：
商用版的是30元/天，開發版+1個標準實例是30元/月。
參見：雲引擎運行方案 - LeanCloud 文檔
facebook放棄了bass模式，但google的firebase裡面重新定義了bass模式，伺服器端不可能被代替掉，但中小型的肯定會慢慢的被代替掉的，就跟當初PC時代一樣，手機不可能取代PC，但會削弱其份額的，leancloud模式很好，只是出身不好，如果換做BAT來做的話，我想應該不會有服務一個月3次掛了，我項目中也集成了leancloud，但只是用存儲功能！！！
哈哈，評論都是人才，為啥他們公司的人不上知乎看看呢
功能怎樣，我不知道，不過文檔寫的好不好是態度問題 ！！！ 雖然我也討厭寫文檔，這糊弄的有點過分了！！！
看完leancloud的開發文檔 ，再看百度地圖的開發文檔，感覺百度寫文檔這傢伙，應該拉出去槍斃五分鐘。噠噠噠~~推薦閱讀：