Q&A
だれにでも意味が通じる日本語を使ってください。
例えば
- サーバー: rails
- フロント: js
なら
railsで入れちゃいけないデータ消して全部返して、
あとはjsでやれば各々のデバイスで処理されて、
結果的にレスポンス速いのでは？
Twitterやインスタみたいなデータがでかいのはあれだけど、
そこそこの中規模なアプリとかは
全部のデータ落としてきても、通信もそんな重くなくない？
jsめっちゃ速いで。
(つまりAcriveRecordをjsがやればいいのでは？って考え)
追記しました
それでもわからない場合、例をあげてください
何を言いたいのかわからない質問。。。しっかり具体例を使って書きましょう。。。
他の方は文章を理解していただいてるようです。読解力はこの業界で確実に力になります。
煽ってる所悪いですが、この質問文は上がっている質問の中でも文章として屈指のヤバみがあります。私は回答者ランカーですし、他上位回答者もエスパー揃いなので裏の意味をなんとなく理解出来ますが、エスパー以外の方も理解出来る文章を書く努力はするようにしてください。
回答4件
0
その思想はSPAとして2014年頃からぼちぼち流行りつつあります。
所謂JSフレームワークというジャンルのルータ系ライブラリとセットで質問文のようなことを実現出来ます。
Angular、React、Vue.js等を覚えましょう。
結果的にレスポンス速いのでは？
そもそも有名ライブラリjQueryがmin.jsバージョンで100KB前後という事を考えれば、
単純なJSONデータならば数万行をドカンと落としてきてもgzipを効かせたり工夫すれば0.1秒やそこらでしょう。
とは言えネットワーク帯域、DBの送受信部分がボトルネックになるので遅くなる可能性はありますし、
検索ロジック的な問題もあります。
例えばMySQLの裏で動いているプログラムは最速の高級言語として有名なC++です。
もしJavaScriptと同じロジックでよーいどんで走らせれば1:20くらいの差が出ます(そもそもMySQLは天才ハッカー集団が寄ってたかってカリカリにチューニングしているので、そこらの一般人がアルゴリズムを工夫してもその境地にそもそもいけませんが)
実際に業務でその思想のままクライアントに10万件のデータを送り付けて処理させるWebアプリを作りましたので、その感想から言いますが、結構面倒です。
JSONデータを精査する場合、よほど練らない限りまぁ線形探索になるので、
数万行を何度も重ね読みしていると普通に分単位で砂時計になります。
n^2ではなく、1n+αや2n程度の計算量で終わるように工夫する必要があります。
まぁまぁJS上で出来る事を総動員しましたが、結局上長から「遅い」の一言で片付けられ、
SQLのソートや絞り込みを多様するようになりました。
その辺を許容出来るアプリなら作れば良いですし、許容出来ないならやめましょう。
投稿2018/11/30 03:34
総合スコア21158
0
全部のデータ落としてきても、通信もそんな重くなくない？
そのような、ごく小規模かつ誰が誰のデータを見られてもいいようなシステムを作っているのであれば、そうかも知れません。
ただし、多くの場合、実用的なWebシステムはこの条件を満たしません。
投稿2018/11/30 03:21
総合スコア145184
>誰が誰のデータを見られてもいい
"入れちゃいけないデータ消して"
権限の切り分けをするのであれば、結局サーバサイドに相応の実装は必要となります。なら、「条件を満たした全データ」を送信して通信に負荷をかけるより、ついでに絞り込みも実装してしまったほうが合理的でしょう。
> 相応の実装は必要となります。なら、...絞り込みも実装してしまったほうが合理的
私にとって意味が繋がりません。もう少し詳しく解説できますか？
0
RubyよりJavaScriptが良いという言語的な話をしているのでしたら
サーバ側をNodejsにすれば良いでしょう。
サーバ側とクライアント側どちらで処理すべきかという話になれば、
基本的には言語よりマシンスペックが重要視されます。
クライアント側はユーザによってどんなスペックかは不明なので
一概にJavaScriptの方が優秀という断言はできません。
（サーバのスペックがよほど低スペックなら話は別ですが。）
投稿2018/11/30 03:16
総合スコア5158
>サーバ側をNodejsにすれば良いでしょう。
クライアント側へ処理を移すこどで、処理分散の話しをしています。
>クライアント側はユーザによってどんなスペックかは不明
近年では低スペッククライアントは圧倒的に少ないですし、対象外でいいと思います。
> 近年では低スペッククライアントは圧倒的に少ないですし、対象外でいいと思います。
モバイルアクセスや低速回線を無視できる、恵まれた環境ならそういう考えも通じるかもしれません。
それでいうと多くの方が恵まれていると思います。
あくまで「プログラマーにとって」恵まれている、というある種皮肉を込めた意味だったのですが。
一般サイトでモバイルアクセスを無視・軽視するような選択は、この現代においてまずできません。
> クライアント側へ処理を移すこどで、処理分散の話しをしています。
「js速い」と仰ってたのでその可能性もあるかなという回答でした。
> 近年では低スペッククライアントは圧倒的に少ないですし、対象外でいいと思います。
圧倒的に少ないというソースがわからないので断言はできませんが、
開発者が対象外で良いと判断したならそれで良いと思います。
スマホからのアクセスでは通信制限等で大量データを受け取るのに時間がかかる場合もあります。
まあそういう状況を対象外にするということならありではないでしょうか。
あなたの回答
tips
プレビュー
