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

0 件のコメント: