まだまだ続くJSONの代わりにSQLiteを使う話 - アニマネ開発日誌
ありがたいことにまだ色々と反応を頂いています。 animane.hatenablog.com animane.hatenablog.com 斜め上の発想なのは自覚しているので、もう少し真面目に考えてみます。 前の記事でも書きましたが、サーバー側のリソースをあまり使いたくないというところから発想しています。 お金も人も揃っているなら、従来通りの手法がベターと考えています。 ただ、サーバーが数100台の規模で行っているサービスで、用途にあうなら検証してみもいいと思います。 今までサーバー側で行っていた計算処理をクライアントに移せるので、かなりのコスト削減が可能になるかも知れません。 密結合じゃね？ これはもうその通りなんですね。 最近のマイクロサービス的な考えからは真逆の考えだと思います。 Web向けには使えない手法なので、APIの提供を考えるとJSONとかの方がいいですね。 もしアプリのみの
続JSONをSQLiteで置き換えた時の話 - アニマネ開発日誌
animane.hatenablog.com 前回の記事が予想以上に反応を頂いたので、少し補足します。 ユースケース 記事中ではあまり書いていなかったのですが、基本的に参照系のデータが対象になります。 サーバー側で生成しておいたDBをそのまま使う形です。 なので更新系のデータについては別DBに保存してます。 SQLiteのATTACH DATABASEを使えば、異なるDB(別のファイル)でもJOINが使えるので、 CoreDataで作ったSQLiteのファイルも問題なく扱えます。 ただ、DBのサイズが大きくなりすぎると通信に時間が掛かり過ぎるため、 そのような場合は従来通りAPI経由でJSONなりXMLを使う方がよいです。 他にも日本のネットワーク環境を前提にしているので、通信が遅い環境では別の配慮が必要になります。 あと、ブラウザでは残念ながら使えないと思います。 SQLiteのDBをD
アプリとサーバーの通信にJSONではなくSQLiteを使うと幸せになれるかも知れない条件まとめ - アニマネ開発日誌
軽い気持ちで投稿したら、思わぬ反響を頂いたこの話。 賛否両論で色々な意見を頂きました。 問題点も含めてある程度メリット・デメリットが見えてきたので、最後にまとめてみます。 ブコメ、Twitterで色々と意見を頂いた方々ありがとうございました。 この場を借りてお礼申し上げます。 前回までのおさらい クライアントとサーバー間で何らかのデータの受け渡しをする時に、 よく使われるフォーマットとしてJSONやXMLがあります。 構造がシンプルなテキストで汎用性が高いため、あらゆるプラットフォーム間の差異を吸収するフォーマットとしてメジャーな存在です。 モバイルアプリも例外ではないのですが、JSONなどを使わずにSQLiteのDBファイルを直接渡してやりとりするというのが先日書いた記事です。 SQLiteはクロスプラットフォームな上に1ファイルで完結するので、1つのファイルで様々なプラットフォームから
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
