まだまだ続くJSONの代わりにSQLiteを使う話

ありがたいことにまだ色々と反応を頂いています。

斜め上の発想なのは自覚しているので、もう少し真面目に考えてみます。

前の記事でも書きましたが、サーバー側のリソースをあまり使いたくないというところから発想しています。

お金も人も揃っているなら、従来通りの手法がベターと考えています。

ただ、サーバーが数100台の規模で行っているサービスで、用途にあうなら検証してみもいいと思います。
今までサーバー側で行っていた計算処理をクライアントに移せるので、かなりのコスト削減が可能になるかも知れません。

密結合じゃね？

これはもうその通りなんですね。

最近のマイクロサービス的な考えからは真逆の考えだと思います。

Web向けには使えない手法なので、APIの提供を考えるとJSONとかの方がいいですね。

もしアプリのみのサービス提供であれば、model層の処理をC++とかで書けばAndroidとiOSの両方で共通の資産が使えるので、アプリのみなら開発工数は下がるかと。

それでも密結合なのは変わらないので、別のプラットフォームへの展開とか、SQLite縛りから抜け出すことを考えると大変なので、あとあとのことを考えるなら、JSONとかにしておく方が痛い目をみなくて済みそうです。

アニマネの場合は個人アプリなので、そこまでは考えていません。

ハードとネットワークの進化に応じてソフトウェアの作り方はどんどん変わるので、またその時に作り替えればいいかぐらいの感じです。

これも最初試したんですが、まとまった量のレコードだとデータ更新時の待ち時間が(JSON圧縮済みでも)気になって不採用としました。

じゃあ差分更新すればいいじゃね？ということで、差分更新も考えましたがこれもかなり大変。実装したことがある人なら分かると思うんですが、多数のクライアントが存在して、データの更新状態がバラバラのことを事を考慮すると実装が大変なんですね。

常時回線が繋がっているわけでもなく、サーバー間のように安定してデータのやりとりが行いにくい環境。
そんな中でトランザクションのこととかを考えると、ちょっと大変なので諦めました。

今の回線速度なら、全データを受信できるぐらいのデータ量なので、シンプルにSQLiteのファイルごと受信して置き換える形にしています。

一括で受信できない規模になったら、差分更新するしかないかなと思います。

LINQというのは初耳だったので調べてみたら、Windows系の技術なのかな？
検索すると同名のアイドルの情報が多くて調べにくかった。
マイクロソフトはもう少しSEOを頑張るべき。

軽くみただけですが、統一したAPIで色々触れるのはよさそうですね。

1000件ぐらいのレコードの処理が速度的に変わらないのであればいいかも知れません。

アプリのユーザーデータはSQLiteか最近だとRealmに保存するケースが多いけど、その辺のミドルウェアとの連結が手軽にできるなら選択肢に入りそうです。

これも初耳だったのですが、ブラウザでSQLを使えるようにする計画があったんですね。

SQLite縛りになる仕様はどうかと思うので廃案なのは理解できますが、ブラウザでガリガリデータが扱えるのはちょっと興味があります。

ブラウザゲームとか作ってる人とかには魅力的なんじゃないでしょうか？

アプリのデータ保存にSQLiteが多いケースならまだまだ選択肢に入ると思います。

ただ、RearlmとかのSQLiteを置き換えるミドルウェアがでてきているので、あと数年後ぐらいには廃れている可能性はありますが。。。

Webサイトを構築する時にサーバーからクライアントへの1方向だった時代から、双方向の時代に向かった背景にはハードとネットワークの進歩がある考えているのですが、同様にモバイルアプリも環境が変われば、実装方法も変わるのでこんなやり方があってもいいと思っています。

冒頭でも書いたとおり、斜め上の方法なのは自覚しているので、一つのやり方として実際に手を動かしてメリット・デメリットを体感していければと考えています。

業務で投入するにはかなり勇気が入りますが、気軽に試せるのは個人アプリのよいところです。