2016年5月22日日曜日

SPAで作る理由

ちょっと前に友人と飲んでた時に、SPAで作る理由について話していたので、軽くまとめとこうと思う。

まずその前に、友人と自分についてだけど。友人は普通のWebサイト、ページを動的にサーバ側で生成し、頻繁に更新されないからキャッシュしとくと良いくらいのものを保守開発している。対して自分はAPIがあってそれをブラウザから操作できるようSPAをここ数年ずっと開発。といった感じで、認識のギャップ、「SPAの必要性がよく分からん」と「SPAが当たり前だろ!」というのがあった。


 

APIファースト / マルチデバイス?クライアント?

そもそもSPAの前提としてAPIがある。そしてAPIが必要な理由は、モバイルやCLI、各プログラミング言語向けのライブラリの開発など、プログラマブルWebという言葉があったと思うけど、結局プログラムで操作できる方が良い、もしくはその手段を提供しておかないとまずいケースがあることだと思う。

APIもWebアプリも必要な案件をRailsで考えると、通常のWebアプリを作りつつ、/apiディレクトリを掘って、/api以下はJSONだけを返すように開発することもできる。けれど、できればそれは分割したい。というのは、API はAPIに注力して、アプリはそのAPIを元に開発した方が、API自体のドッグフーディングもできるから。そういった理由から、自分はほんの一部だけAPIが必要なケースを除いて、APIありきなものは、APIファースト、プログラマブルであるべきと考えて、ブラウザはその真正面にいるのではなく、多数あるクライアントのプラットフォームの1つだと捉えている。ネイティブアプリも同じAPIを元に開発すると考えると、うまく分離してるように見えると思う。


SPAのメリット

APIがあることが前提で、APIのクライアントはネイティブアプリなどいろいろあり、ブラウザはその中の1つで、それをSPAで実装するのは、理解できると思う。それでもブラウザ向けの実装は、通常のWebアプリでもいいし、必ずしもSPAである必要もないのもまた事実。ではなぜSPAを選択のかを考えてみると、簡単にまとめて、これらのメリットがあるから、もしはある場合にだけ選んでるからかも。


  • 静的ファイルを返すだけで良い(あとはブラウザが頑張る)
  • 作り方を間違わなければ、初期描画と再描画が速いことが多い
  • ユーザから見て視覚的レスポンスが速いとUX的に吉
  • ページ遷移毎に無駄なHTTP通信が発生しないので、サーバもクライアントもwin/win
  • 通常のWebアプリでは、ページ遷移中にJavaScriptで制御できるものにはかなりの制限がある。ユーザの操作も次のページが描画されるまで受付けられない。SPAにはそういった制約がない。これもUX的に吉な機能を実装しやすい。

SPAでなくても、レスポンスが速ければ、最近のブラウザは描画スピードが驚異的だから、あまり差はないかもしれないし、コンテンツによってはクライアント側で全部描画するより、サーバ側で描画して、それを大多数のクライアントが参照する方が、世界的に電力消費量が減ってエコかもしれない、といったそういったのもあると思うので、いろいろと加味した上で、どういう構成にするのかは決めればいいと思う。サーバにかからなくなった負担がクライアント側に来るわけで、それが良いか悪いかはケースバイケースだし。


まとめ


ずっとSPAをやってきていたので、当たり前の感覚になっていて、それを急に言葉で説明するというのは難しいなと思ったので、今回頑張って言語化してみた。お互い違う前提で話をしてる間は話がかみ合わないってことがあるよね。

2016年5月10日火曜日

続・Rustを習得したい

前回の、Rustを習得したいから、だいぶ時間も経ったのと、「rust 用途」で検索すると、その記事が検索で上位に来てたらしく、ちょっと付け足したいことがあるので書いてみようと思う。


Rust1.0リリース前から現状(2016/05)の環境変化


まずは、日本語でも情報が追いやすくなった。



英語も情報は追いやすい。This week in Rustを筆頭に、This week in Rust Docsなど、週ごとにまとめがでてくる感じ。他にも@rustlangをフォローしたり、Redditやinternalsあたりを見とけばだいたいの情報が入ってくる。Rustのコミュニティは情報共有に意欲的で良いと思う。


開発環境のセットアップの簡単さとクロスコンパイル


Rustは6週間毎に最新の安定版がリリースされる。いろいろ省くけど、とにかく最新バージョンを使ったり、nightlyやbetaを落として使いたい場合に、multirustがあれば簡単に実現できる。rbenvやndenvなどを知っていれば、それのRust版という捉え方で大丈夫だと思う。

ただ、multirustはシェルスクリプトで書かれていて、Windowsではきちんと動作しないらしい。なので、Windowsサポートもターゲットに、rustupに移行予定。(この投稿で作者がThe future of multirust is rustup.rsと書いている。)


クロスコンパイルについては、公式ブログのRust in 2016で書かれていたように、コンパイル済みのlibstdをダウンロードできるようになってきていた気がする。この辺はまだちゃんと追ってないけど、本当に `cargo build --target=foo` だけでコンパイルできるようになればGo並みに楽だなーと期待している。そういえば、rust everywhereというのもあるのでリンクだけ貼っておく。


Ruby/Node.jsの拡張

そもそもRustをやろうとしたきっかけが、RubyのC拡張を書く時に、「C怖い」から始まっていて、同じような人がいたんだけど、それがたまたまYehuda Katzで、あれよあれよとRustで書いて実際にプロダクション(skylight)で使っちゃうし、コアメンバーにもなっちゃうし、そして時々イベントで発表するので情報が入るという状況だった。それとsteveklabnikもコアメンバーになって、今はもうやめたけどRust for Rubyistを書いたり、ドキュメント周りの整備からTRPLを執筆したり、イベントに登壇して発表したりして、追ってるだけで情報が入ってくる。Rubyistだから共感する部分もあるからかもしれないけど、彼の説明はわかりやすいと思う。

いきなり話が逸れたので戻すと、skylightを開発運営しているTildeはTurboRubyというのを試験的に作っていたけど、最近rustbridgeというGithub orgができて、helixという名前に変わった模様。nodeのもrustbridgeに入ったみたい。


他にも、ruby-sysRurumrustyというのがあるので、将来的にずっと開発されるものかどうかは知らないけど、とりあえずリンクだけ貼る。


そろそろ試さないとなー...でも必要に迫られる機会がないのよねぇ、今のところ、、、


Web

Are we web yet?を見れば、RustでWeb開発する場合にどういうツールやライブラリがあるかざっと知ることができる。が、RustはWeb開発用の言語というより、システムプログラミング言語なので、プロジェクトにあった選択をしたほうが良いし、Web開発用に豊富にライブラリがあるわけではないのが現状だと思う。サイドプロジェクトでちょろっと遊びたいよね。


その他


Rustはシステムプログラミング言語にしてRubyやJavaScriptのようにも書ける(全部ではない)素晴らしい言語で、比較的新しい言語に見られるパラダイムや独自のパラダイムがあり、それを知ることで他の言語のことも理解できたりして、勉強してみるのも良いと思う。全くのプログラミング初心者にはおすすめはしないけど、例えばSwiftのOptionalとか、Rustを知っていれば理解が早いといったところ。TypeScriptだってフィーリングで理解できる気がする。(乱暴)

それとまだプレゼンは英語が多いので、英語の勉強にもいいんじゃないかと思うので、自分が見た動画をいくつか紹介して今回は終わりたいと思います。



動画はまだ他にもあるけど、長いしいいかなと思って省いた。また何か情報があれば書こうと思う。