Couchbase Mobile MiniHack 20150407
•Download as PPTX, PDF•
2 likes•616 views
Couchbase Mobileは簡単にNoSQLを使ってあなたのデータを保存・同期できます。こちらはそのCouchbase Mobileの入門プレゼンテーションになります。
Recommended
More Related Content
Similar to Couchbase Mobile MiniHack 20150407
Similar to Couchbase Mobile MiniHack 20150407 (20)
More from Couchbase Japan KK
More from Couchbase Japan KK (11)
Couchbase Mobile MiniHack 20150407
- 2. ©2015 Couchbase Inc. 自己紹介 James Borden • アメリカ→NY出身 • 2009年来日 • 2011年〜2014年株式会社想通でモバイルアプ リ開発（iOS / WinRT / Android) • 2015年１月Couchbase Japan入社 • Couchbase Lite .NETリード開発者 • 厚切りジェーソンに似ている？
- 3. ©2015 Couchbase Inc. 予定 ▸ビズネス向け口上 ▸製品概要 ▸Q & A ▸次の一歩
- 5. ©2015 Couchbase Inc. 現在のモバイルアプリ 5 Try again later. No Internet please wait…
- 11. ©2015 Couchbase Inc. Couchbase Mobileとは?
- 12. ©2015 Couchbase Inc. Couchbase Lite Sync Gateway
- 13. ©2015 Couchbase Inc. Couchbase Lite NoSQLモバイルデータベース アプリ内で動く 小さいフットプリント
- 16. ©2015 Couchbase Inc. { "session": { "Id": "session-1011", "Location": "TBA", "SpeakerIds": [ "speaker-zack-gramana" ], "Time": "2014-10-06T15:20:00", "Title": "Building the Mobile Apps with Couchbase Mobile", "Track": "Mobile" }, "type": "session" } ドキュメントの例
- 17. ©2015 Couchbase Inc. oネイティブ言語でインデックス作成 oクエリを速めるために結果保存 oデバッグにはブレークポイントを設定す るだけ！ MapReduceインデックス function(doc, meta) { emit(doc.name, [doc.city, doc.salary]); }
- 20. ©2015 Couchbase Inc. doc.Change += (sender, e) => { if (e.Change.IsConflict) { // 決着を付けろ〜 } }; 変更通知登録の例
- 24. ©2015 Couchbase Inc. Sync Gateway
- 25. ©2015 Couchbase Inc. 25
- 26. ©2015 Couchbase Inc. orequireUser (username) orequireRole (rolename) orequireAccess (channels) Sync Function Sync Function: 権限確認関数
- 27. ©2015 Couchbase Inc. ochannel (name) oaccess (username, channelname) orole (username, rolename) Sync Function Sync Function: ルーティング関数
- 28. ©2015 Couchbase Inc. Sync Functionの例
- 34. ©2015 Couchbase Inc. Upcoming Events in Japan 国内最大のCouchbaseイベント！ 日程：2015年8月下旬 (予定) 場所：東京 定員：200名 URL：Coming Soon! Couchbase Conference Tokyo 2015
- 35. ©2015 Couchbase Inc. Couchbase Connect in USA 35 世界最大のCouchbaseイベント：開発者のセッションや多数のユーザ事例 日程：2015年6月2日(火)〜4日(水) 場所：米国サンフランシスコ Levi’s Stadium 金額：Coming Soon! URL：http://www.cvent.com/events/couchbase-connect-2015/event-summary-b7744ca960364b75aba41de42cbef19e.aspx
- 36. ©2015 Couchbase Inc. Couchbase Lite Unity 36 Unity 3Dゲームエンジンβ版リリース！ https://github.com/couchbase/couchbase-lite- net/wiki/Unity3D-Usage ↑ビルド手順 https://github.com/couchbase/couchbase-lite- net/releases/tag/unity_v1.0-beta1 ↑ビルドされたリリース
Editor's Notes
- このたびお集まりいただき誠にありがとうございます。
- まず最初に、なぜCouchbase Mobileを開発しているか、そしてどの様なビジネスの問題を当社のモバイルソリューションで解決することができるか説明させていただきたいと思います。 Before we begin, I want to take some time to share with you why we created Couchbase mobile, and the business problem that we hoped to solve.
- 今のモバイルアプリはリモートデータを使う時に、つまりサーバーからのダウンロードやローカルデータのアップロードを行う時にネットワークが繋がっていないとだめですね。 速度が足りるネットワークが接続されていればアプリは通常に動き、それはそれで問題ないですが、ネットワークが混乱している場合、電波が悪くなったり、WiFiにたくさんの人が接続していたりするとアプリの反応が悪くなってしまいます。その時点で、接続中を表すぐるぐる回るアイコンが出て待つ場合が多くなります。 さらに悪化すると「接続できませんでした。また後でやり直してください」というメッセージが表示されます。作業中だった内容が失われ、ユーザーを困らせてしまうだけではなく会社にとって経済的な損失にもなる可能性があります。 Note: Subway, driving in the mountains, theme park, underground conference room, shopping mall, warehouse (construction interfering with signal), etc Most of today’s mobile apps are designed so that any remote data, whether downloading records from a server or uploading your local data, requires the network to be available and online. As long as that’s the case, and the Internet connection is fast enough, and there aren’t any problems, then the app performs exactly as expected—and that’s great. But as soon as the network begins to degrade, say we’re down to just a couple of tower bars, or the Wi-F is having a bunch of latency—that sort of thing—then we start to see the app’s user experience break down. That’s when we see the progress notification UI hints show up, the spinners, the waiting. If things get bad enough, we will see an error message saying that, “I’m sorry you can’t do what you were trying to do right now, you’ll have to try later.” Whatever work you were doing is lost, and the end result is a user who is unhappy and dissatisfied and can use your app.
- そして、こういった問題があるとアップストアのレビューに反映されています。こういう件は見たことありますよね？１・２星のレイティングと、よく動作しないし、しても遅ぇーというコメント。 how do you know if you’ve got these kind of problems? Well, it’s reflected in your app store rating. We’ve all seen apps in the one and two star category, with user reviews saying that the app doesn’t work or it’s slow.
- ひとまずそれは置いておいて、実は他に気にしなければならない問題があります。それはユーザーは動作の悪いアプリをすぐ消します。 アプリのアンインストール率を見てみましょう。ユーザーがアプリを消す理由はなぜでしょうか？ 主な理由のトップスリーは「フリーズ」、「落ちる」と「反応が遅い」になっております。 フリーズと反応が遅い場合は、アプリの作り方に直接的な影響があります。多くはネットワークの動作が原因です。普段はユーザーの環境をコントロールすることができませんが、うまいことをやれば悪い環境の影響を弱めることができます。 Besides the bad brand PR, why should you care? Because people delete poorly performing apps. Let’s look at application uninstall rates. Why do people delete an app from their device? The top three reasons are: freezing, crashing, and slow responsiveness. And in the case of freezing and slow responsiveness, those are directly tied to how we build our application. More often than not, our networking code is the culprit. In a lot of cases we can’t control the environment where people are using our app, but if we’re using proper coding strategies, we can mitigate those issues.
- 要するに、主な問題はデータの保存先です。 データがデバイス上に保存されていないと、必ずアプリがデータの取得をできなくなる場合があります。 それに伴って、動作が悪くなり、ユーザーはアプリをきちんと使えません。 At the end of the day, the core problem we face is the location of our data. When the data is not located on our device, it’s always going to be subject to those scenarios where it is unavailable to the application. And when the data is unavailable for the application, its functionality degrades, and people cannot use your app the way you intended.
- さて、問題解決は一体何でしょうか？ データをデバイス上に保存することです。 と言っても、常に変わっているデータの処理もしなければなりませんのでデバイス上のデータが最新だとか、保存された内容がちゃんとリモートまで反映されていると保証する同期プロセスが必要になってきます。 So what’s the solution? Putting the data on the device. Now that’s all well and good, but most of us all have to deal with changing data. So we need some kind of sync process to ensure that the copy we have on the device is reasonably up to date, and to make sure that our information, and any changes that we made locally, are pushed up to the remote system of record.
- アプリにどんな影響があるでしょうか？オンラインでもオフラインでも動作できるようになります。随分と憧れられている機能でしょう。 そして、アプリは常に素早いです。１０MBの画像をシェアしているユーザーでもあっという間に終わり待たずに次にやることに続けることができます。ネットワークの代わりにローカルデータベースに読み書きをすると速度はハードディスクにしか制限されていません。多くの場合は業界標準のフラッシュメモリーになっています。速度が速いので、ユーザーは好むでしょう。そして裏で画像ができるだけ速くネットワーク上に送信されています。 ネットワークのエラー処理や、再送信とそのタイミングなどソースの量を減らすことができます。 開発者はユーザーがアプリを好きになるためにアプリの開発を努力しています。ただし、 素晴らしいUIのデザインがあるとしても、あいにくそれだけでは足りません。ネットワークのトラブルがあったらユーザーを待たせ、その素晴らしいUIは使えなくなってしまいます。 Couchbase Mobileを使いその問題を任せていただきたいと思っております。 What are the benefits for our apps? It means that we can always work both online and offline, which is a coveted feature. It also means that you application will always be super fast. If I’m a user sharing a 10 megabyte image, I feel like it took only a handful of milliseconds and now I’m moving on to my next task. By making your database reads and writes locally, and not over a network connection, your primary bottleneck is the speed of your disk. For many of us, this is just basic commodity flash. That’s going to be fast and users love that. And in the background, that image is being transferred for me as fast as the network can handle. We can eliminate a lot of the cruft code that we’ve been writing that’s centered around network error handling, retry logic, backoffs, all those kind of things. We put a lot of thought and care into our applications because we want our users to love our application. We could have a brilliant user interface design for our application, and while it’s necessary for a good user experience, it’s just not sufficient. If we have problems with the network, we force the user to wait and the entire experience breaks down. With Couchbase Mobile, we wanted to address that final gap in the user experience story.
- Couchbase Mobileはその問題の解決になり、皆さんも好きになると思います。 では一体、何をするか、どうやってやるか説明させていただきます。 Couchbase Mobile is our answer to that problem, and we think you’ll love it as much as we do. So, what it does it do, and how does it work?
- まずCouchbase Mobileには２つの主な製品があります。 デバイス上で動作するCouchbase Liteと デバイスとクラウドの間に入るSync Gatewayです。 We have two core products in Couchbase mobile. We have Couchbase Lite, which runs on the device And we have Sync Gateway, which stands on the border between your private cloud and the public cloud.
- Couchbase LiteはNoSQLモバイルデータベースです。つまり、別プロセスではなくアプリに組み込まれてフットプリントが小さいです。 機能は主に４つ分かれています。 ドキュメント指向データベース MapReduceクエリのエンジン 様々な変更通知 マルチマスター同期 Couchbase Lite is a NoSQL mobile database which means it runs in process with your application, and it has a very small footprint. We have four major feature areas: 1. It is a document oriented database 2. It provides a Map Reduce query engine 3. It provides a suite of event notifications 4. It provides sync (multi master replication)
- ドキュメント指向データベースについてお伝え致しましょう。 リレーショナル・データベースの世界ではテーブルとそのテーブル内の関係を定義します。アプリのオブジェクト・モデルのためにデータを取得する際にO/Rマッペィングを行う必要があります（そして面倒なソースが増えてしまいます）。 対照的に、ドキュメント指向データベースはアプリと同じデータ構成を使います。具体的にいうとキー・バリューのコレクションです。つまりiOSだとNSDictionary、JavaだとMapで.NETだとDictionaryです。 キー・バリューコレクションである上にキー・バリュー・ペアの変更をモニタリングするためにバージョン履歴をドキュメント毎に書き込みます。 O/Rマッペィングなど関係なくなります。キー・バリュー・ペアの使い方さえ分かれば問題ありません。再帰的にオブジェクトを突っ込みますのでJOINなどの心配はする必要がなくなります。メモリに必要な情報を直接入れます。そのおかげでスキーマの整理や正規化と非正規化がなく、アプリのロジックがより簡単になります。 それによって開発も動作も早くなります。内部的にJSONでオブジェクトモデルを保存しています。開発者はJSONに使い慣れているので、自然に始められるでしょう。そして、データベースはJSON対応してますのではるかに早いです。 Let’s talk about Document Oriented Database. If we are coming from a relational model, we are familiar with modeling our data in third model form, where we have a number of tables and we define all of these relationships between the tables. When we need to retrieve the data from these normalized database schemas into our object model in-memory, we go through some object relational mapping (it’s a lot of cruft to keep up with). In contrast, the document oriented database, uses the data structure we are already using in our applications. More specifically, it is a collection of key-value pairs. In iOS, you’re looking at an NSDictionary, in Java you are looking at a Map, and in .NET you’re looking at a Dictionary. In addition to being a key-value pair collection, we also add in to documents a version history, so we can track the changes in that key-value pair all the time. We don’t have to deal with normalizing data anymore. We only need to know how to use a key-value pair. Because we insert nested object graphs within that key-value pair, we don’t need to worry about joins and things like that. What ever object graphs we need to have in-memory, we just store in the key-value pair collection. This vastly simplifies how we build our applications because we no longer have to deal with the book keeping aspects of schemas and the problems of going between normalized data and de-nomalized data. That lets us code fast and run fast. Internally on disk, we use JSON serialization to represent the object model. We are using whatever basic skills you are already familiar with in dealing with JSON data, but we’ve taught our database how to deal with JSON data so it’s fast.
- こちらはCouchbase Liteでデータベース取得とドキュメント作成のサンプルコードです。 上のソースはObjective-Cで下はJavaです。両方ともマネージャークラスを使ってデータベースを取得します。また両方とも「demo」というデータベースを求めています。そして両方とも「作成セマンティック」を使いますのでnullを防ぎます。作成セマンティックだというと最初にこのソースを実行する時にはdemoというデータベースが作成されます。２回目からは既存のデータベースを開きます。 データベースを取得したら新規ドキュメントを作ります。下の行のPutPropertiesを呼び出すまで保存されませんのでご注意ください。ドキュメントを作成した後にキー・バリューコレクションを入れます。 上のソースも下のソースも「 foo」というキーに対して「bar」というバリューを入れます。そして、いわゆる保存関数のPutPropertiesを呼び出します。内容としてキーバリューコレクションを書き込んで新しいリビジョンとして保存します。 Here are code snippets that show what it takes to get a handle to a database object in Couchbase Lite and how to create a brand new document. The top code block is in Objective-C, the bottom is in Java. In both cases we have a manager class which we use to provide us with instances of database objects. In both cases, I’m asking for a database named demo. In both cases I’m using a get or create semantic, so I know that my database variable will never be nil in these cases. If this is the first time I’ve run this code block, then it will create the demo database for me. If I’ve run it before, it will just reopen the existing database on disk. Once we have the database handle, all we need to do is create a new document. Which until we call the putProperties method down below, It will not actually be saved yet. We create the new, unsaved document, then we need to have a key value pair collection to pass in to it. On the top block, I have the properties NSDictionary, which just have a simple “foo” key with a “bar” value. Same thing with my hash map down in Java. And then I call the putProperties method, which is effectively is the save method for a document. That will insert the properties as the content for that document and create a new revision.
- こちらは２０１４年のアメリカのCouchbase Connectコンファレンスのアプリが作成したレコードです。直接Sync GatewayのバックエンドになるCouchbase Serverから取りました。直截簡明な構成なので、データの扱いはアプリですでに使っているキー・バリューコレクションの扱いと同様になります。 This is a record taken from our conference app this year using Couchbase mobile. This is a session record pulled directly out of Couchbase Server, which is the back end that we use for Sync Gateway. In this case, it’s very straight forward JSON with a nested object graph, so if I need to work with this data it’s just as simple as using normal key-value pair collections that I’m already using in my applications.
- 次の機能になるMapReduceインデックスによってドキュメントの素早いクエリを行うことができます。ネイティブ言語で開発することが可能です。別の組み込みSQL言語を頼りにすると、遅くなったり違う結果が出てしまっても直接なデバッグ方法がありません。成功するのに試行錯誤するしかないのです。 MapReduceクエリエンジンによって同じツールと同じデバッガーを使うことができます。 結果は保存されますのでクエリは超高速です。 そしてどこでおかしくなっているか知りたい場合はブレークポイントを設定するだけでデバッグを行えます。 MapReduce Indexes: provide us the mechanisms for doing very fast queries against our documents. This lets us build our indexes in our native language. When we’re dealing with two languages, we have to resort to an embedded string-based language for SQL that works completely different, and we have no direct way of being able to debug why an index is slow or why it’s not returning the correct results. We have to do a lot of trial and error to get it right. By providing a MapReduce query engine, we’re able to use the same debugger, the same tools we are already using. The results are persisted, so your queries are lightening fast. If we’re trying to figure out where things are going on, all we have to do is set up breakpoint.
- 続きましてインデックスの役割に入るViewと呼ばれる例をJavaでお見せします。このビューを「viewItemsByDate」と名付けます。前回とおなじく作成セマンティックを使います。JavaのMapとコーロバックを引数として使うマップ関数を定義します。 基本的な処理を行います。処理されるドキュメントはcreated_atというキーがあることを確認し、ない場合はインデックスに入れません。ある場合はコールバックを呼び出し、キー・バリュー・ペアをDIctionaryに入れます。こちらの例の場合はキーしか定義していません（実際のタイムスタンプ）。バユーは得にいりませんのでnullを入れます。 タイムスタンプによってソートだけにしぼりたいので、nullを入れることで少しディスクスペースを節約します。 それらによってビューの作成ができましたので、createQuery関数によってクエリを作成します。クエリの設定でフィルターしたり、ソートしたりなど様々なことができます。そして呼んだLiveQueryという関数を後々通知をご紹介するついでに説明しますが、継続的なクエリを作ります。データが後で変わった場合、自動的に同じマップ関数が実行されます。 とても精鋭的な開発のしかたで、面倒なソースが減量されます。 So here’s in example in Java in this case, continuing where we left off, we are going to create a view, which is our name for an index in Couchbase lite. In this case, I am creating a view, called “viewItemsByDate” and again, I’m following that same get or create semantics here. I’m providing a map function here, and the map function receives a Java map object and it also is given a callback object, as a delegate. So I can do some basic things, where I can verify that the incoming document has a key called “create_at” which I would have created in my application code elsewhere, and that if it’s not there, then we’re not actually going to index this document. But if it is there, I’m going to call the emit function back, to insert a key-value pair into the dictionary. In this case, I’m only setting a value for the key, which is the actual time stamp itself as a string, and I don’t actually need to provide a value, so I pass null. In my case, I just want to do a simple ordering based on creation time stamp, and passing null lets me save a little space on disk. Finally, once I’ve got my view created, all I need to do to get a query object is call “createquery”. The query let’s us set some things, like we can filter by ranges, we can also set the sort order, and you’ll notice here I’m doing something called a “livequery” which we will talk about in a second when we talk about event notifications. But a live query lets us effectively create a never ending query, so that whenever results are return, whether it’s going through results already on disk, or later on as new records are inserted into the database, the same logic will get called back so I can handle any future changes to the data, the same way I would handle the initial query. It is a very powerful change in how we build applications, and it reduces the amount of cruft code that we write.
- 変更通知。Couchbase Liteのオブジェクトにはそれぞれの開発言語の標準のイベントシステムによって変更通知の登録ができます。 いろいろなオブジェクトに登録ができます。データベース、クエリ、セッション、ドキュメントさえも。 これも面倒なソースが圧倒的になくなります。ライブクエリを作成して、ロジックを設定さえすればよいのです。 Change Notifications: Objects in Couchbase lite, let you listen for changes/ observe for changes, using the standard or native change/ event notification system of your language of choice. Multiple scopes for change notifications – we can listen for them at the database level, individual query level, replication/ sync session level, even down to specific documents. It cuts down significantly on the amount of cruft code we have to write. All we do is create our live query and then provide the functional call back using the language specific notification system to drive UI updates. Once we’ve taught our application how to deal with changes in data, we can set it and walk away.
- 続きましてサンプルコードです。 上のソースはObjective-Cを使ったドキュメントの変更通知の登録で、下はC#で同じく。 両方にドキュメントが変わる際に呼ばれるロジックを定義します。 .NETの方にはドキュメント以外の情報も入ってきます。現在のリビジョンは競合かどうかもわかります。 競合は何かというと、自分のデバイス以外でもドキュメントが変更された場合があります。自分も他の人もお互い同期しないで変更すると競合状態になります。実はこのロジックで解決するチャンスがあります。 また、リモートからの同期によってのドキュメント変更かどうかとそのURLも伝えられます。どの場合でも適切な処理ができます。Here are some code samples. The top case is an Objective-C change notification at the document level, and at the bottom is the same document level change notification in C# for .NET. In each case, we are providing a specific function that is to be called whenever the document changes. In both cases, we take care of marshaling those callback back to the UI thread (in most cases) so that you don’t have to re-marshal your calls back to the UI thread, which is mostly what you’re going to be doing in these change functions anyways. In the bottom example with .NET, you can see that when we provide a change notification, we also provide information beyond the documents coming in. We tell you whether or not the current revision of that document represents a conflict. In some cases, I may have a single version of that document on my device, and everything is going great. I save a change, and unbeknownst to me, someone else has also made a change, and it’s only when those changes sync back, that I now have a conflict state. So this gives me an opportunity to detect it and resolve it. In addition, we also let you know if it was a result of a sync session, what they URL of the sync session was. If you’re doing something like peer to peer replication, you can respond to that in an appropriate way.
- 同期の説明をさせていただきます。マルチマスター同期が機能として入っています。マルチマスターというのはマスター・マスターと違って複数のエンドポイントに同期ができます。 同期は継続的（つまり、データができるだけ早く変更されてから同期されます）かアドホック（つまり、同期が終わった後にもう一回同期したい場合は手動的に行う必要があります）という２つの種類があります。同期はリモートからかリモートへどちらの方向もできます。 継続的かアッドホックという選択があるメリットは電池の省エネができることです。モバイルデバイスの電池を一番消費するのは電波接続です。電波接続を少なく使うのがベストです。実は継続的に同期する必要がないアプリが多いです。たくさんのアプリは起動時に製品カタログを更新したり、終了時にログやアナリティクスを送信したりするような処理だけします。ユーザーか購入やリクエストをする際にアドホックの同期を行うのは可能です。そういったデータに関しましては継続的な同期の必要はなさそうです。自分のアプリのデータとその処理を考慮した上に決める方がよいでしょう。 Sync: a very simple mechanism in Couchbase Lite. Full multi-master replication (not master-master because you are not limited to only one end point, you can sync with N number of end points) Sessions can be run either continuously (minimum latency in data changes between two systems) or ad-hoc, as soon as the sync session is done, then that’s it. Any further updates, you will have to run another sync session. Sync sessions can be done in either direction. The nice thing about being able to had the choice between continuous and ad-hoc, we can be good about our end users battery life. The biggest drain on our mobile devices, our batteries, is the radio. You want to minimize the amount of radio usage our app requires. You want to make sure we are using the minimum for the use case that we have. Many applications don’t have a lot or any data that needs to be synced in real times. Many apps can pull at app start up to refresh a product catalogue (retail) or just do a one off push when they are closing, to push off logging or analytical data. As a user completes a purchase or individual request, there can be a one-off push sync. We don’t need to be in continuous push or pull mode for those types of data. You have to look at your application and the kind of data (speed and flows) you have and we can handle it responsibly with Couchbase lite. We get our change in notifications, and we also get the ability through that mechanism to do conflict detection. Each document will provide a list of conflicting revisions, if there are any. Couchbase lite implements the same MVCC algorithm that Git uses and Mercurial, and most other distributed versioning systems use. If you’re familiar with how to use those tools, then you will be very comfortable with Couchbase lite. In Git for example, if you’ve got a branch, we call that a document, if you have a commit, we call that a revision. If you have two commits in conflict, many times they can be auto-merged, and in the cases you can’t, you simply make a merge-commit, just like you would in Git, except we would have a merge revision in that case. It’s very simple and easy to use.
- こちらは継続的なプッシュとプル同期を開始する包括的なサンプルコードです。通知変更もベーシックHTTP認証も入っています。 なので、同期を開始する９９％の場合はこれ以上要りません。最小で一番上の３行と一番下の２行だけ必要です。 とてもパワフルです。ローカルでできたら、後少しで同期してリモートでも保存することができます。 Here’s a complete comprehensive example of what it takes to start up a continuous, bi-direction sync session, in iOS in this case, where I’m even throwing in subscribing to change notifications, and I’m also adding in authentication. In this case, basic http authentication. So this is, in 99% of use cases, the most code you would ever have to write in your application to sync enable it, this is very powerful. At the minimum, only the first three lines and the last two lines, would be required. It’s a very powerful way to program. If you’re building locally, you’re also effectively building remotely as well.
- こちらはCouchbaseがサポートしている言語とプラットフォームです。iOS (Swift / Objective-C両方)、Android、.NETとJavaの上にPhoneGapやXamarinやTitaniumの様なマルチプラットフォーム環境もサポートしております。 入手するにはCocoapods, Maven Central, Nuget, 並びにGitHubからソースもダウンロードすることが出来ます。開発者のプロジェクトに追加することを簡単にいたします。 These are the platforms and languages and environments we support. Any modern and popular operating system we provide support for, for Couchbase lite. We provide native implementations for iOS and also, we support Swift, Java, and .NET as well. We also support multi-platform programming environments like Phonegap, Xamarin, and Appcellerator’s Titanium. You can get your hands on Couchbase Lite by Cocoapods, Maven Central, Nuget if you’re a .NET developer, or you can get the source from Github. We make it super easy to add to your project and to get started with.
- Sync Gatewayについて話します。Sync Gatewayはアプリとパブリッククラウドをつなげます。普通のウェブアプリケーションのように認証と権限付与を行う上に独自的にデータの扱いも行います。 様々なデバイスから浮かんできたデータがはいってくる場合もありますが、許可をもらっているユーザーだけに書き込み権利を与えたり、見る権利もない人のデバイスの同期しないことも必要です。 それに、うんうんTBもデバイスに入りきれないので関係するデータだけ同期する方法も必要です。Sync Gatewayにはその関係を定義する方法があります。Let’s talk about Sync Gateway. Sync Gateway handles the boundary between your private data center and your public cloud. When I say private data center, that can still be in a public cloud like EC2 or Azure where you’ve got a number of VMs running. It handles the same cross cutting concerns from your application that you would have in any web-based application: things like Authentication, Authorization, and unique to Sync Gateway: it provides a method of data orchestration. We often have all these streams of documents coming up from different devices, and we want to do things like ensure that writes are only allowed to documents where users have appropriate authorization and make sure that, if someone shouldn’t be able to see a document, that it doesn’t get replicated down to their device. We also need to define relevancy, because we can’t possibly fit the entire application database of however many terabytes onto an individual phone. We need to only sync the information that user cares about, and we need a way to programmatically define what that user cares about. And that’s another thing that Sync Gateway does for you.
- その上に、Sync GatewayはアプリのデータをプライベートデータセンタにあるCouchbase Serverクラスターへの保存も行います。デバイスがSync Gatewayに同期していると同時にSync GatewayがCouchbase Serverに書き込んでいます。 さて、権限付与を少し見てみましょう。 Sync gateway also handles the permanent persistence of your applications data in your Couchbase Server cluster that lives in your private data center. So as your device is syncing with sync gateway and pushing your data up, sync gateway is also writing that data into the permanent data store, backed by our highly scalable Couchbase Server technology. Now, let’s look at security layer concerns: in this particular case, authorization.
- 同期で入るドキュメントはSync Functionという関数で処理され、アクセス制限や認証に使えるいろいろなJavascript関数があります。 ドキュメントの書き込み権利をもらうために、適切なユーザーかロールを要求することができます。 または、チャンネルに属することも要求できます。チャンネルというのはユーザーに関係するドキュメントのみ同期できるための名前がついているドキュメントの部分集合です。チャンネルを使えば無駄なデータは受信されません。The incoming documents go into the Sync Function, where we have a number of functions that you can use within that Java sync function to handle authorization and access control. In order to have write access to a document, we can require a user has a specific role in order to have access to that document. We can also assign write-access requirements to specific channels. Channels are what we call a named subset of documents, or a named collection of documents, that allow us to build context or contextually relevant sync down to the end-users, so we aren’t sending them data they don’t need.
- もう少しチャンネルについて話しましょう。ドキュメントがSync Functionで処理されるたびに割り当てることができます。 channel関数で現在処理しているドキュメントを指定の名前のチャンネルに入れます。そして、access関数であるユーザーをあるチャンネルにアクセスを与えます。さらに、role関数であるユーザーをあるロールにします。様々なルーティング関数があります。 チャンネルを使った例としては「public」というチャンネルにアプリケーションのメタデータを入れ、全てのユーザーに読み込む権利を与えます。もしくはユーザーのためのチャンネルを作ってそのユーザーだけに書き込みアクセスを与えます。チームにアクセスがあるチャンネルや、売り買いの場合は各店舗のアクセスや国内全店のアクセスがあるチャンネルも可能です。 効果的なデータの割り当てとポリシーに使えるツールになっています。無駄なデータなく必要なデータだけ同期されます。Let’s talk about how channels work. As incoming documents come into the sync function, we can then partition them out. In this case, my collection of three documents was broken into two channels. The first channel has two documents, the second channel has one document. We do this as our sync function which gets the incoming document, applies the use of some of these additional routing functions. We have the channel function which will then take that document and assign it to a new named collection or an existing named collection. So I can build a channel, for instance, called public, which will have all of the metadata my application needs so that everybody can read that and have read only access. Or maybe I have a user named specific channel, so that all of the users individual documents are listed in that single channel where only the have write-access, and maybe nobody else has read-access either. Or I could build team level channels, or more specifically in the retail case, I could have a store level channel and a regional channel, so that any documents in the regional level channel will automatically come down to any users in a store location within that region, and similarly with a store level channel, I could have the store ID function as the channel name, and any user who is syncing within that store level channel will see all of those same docs and sync with each other as well. It gives us some very powerful tools to segment our data and drive some application level policies around that, so everyone has exactly what they need and nothing more.
- こちらはSync Functionのとても簡単なサンプルコードです。chat_roomというドキュメントしか処理しません。typeというのは保存した時点で入れたキーだけです。 chatroomのドキュメントに対してmembersというキーの配列バリューに入っているメンバーにアクセスを与えます。そしてそのドキュメントを適切なチャンネルに割り当てます。Here is a very simple example of what a sync function looks like. In this, I’m only dealing with a specific type of document, called “chatroom”. Type is simply a key that I defined in my document when I saved it, in this case, I’m looking at “chatroom” as the value. For any document that represents a chatroom object, I can grant access to anybody that’s in the members array that I included in my document, and I can even let my document store channel name key-value pairs, so that anyone in that channel can have access as well. Finally, I put this document in the channel, so that it shows up to those users with access.