世界回遊

World Travel

Webアプリの構成案

Webアプリの作成で技術の選定に悩む。

ポイントは、素早く作れること。他は二の次。

フロントエンドとバックエンドで何を使えば、サクサク作れるようになるのか?

 

 

理想案1 Elm+Haskell

  • フロントエンド:Elm
  • バックエンド:Haskell

 

コンセプトは全て「関数型」で書くこと。

ElmもHaskellコンパイルが通れば、ランタイムエラーが出ないことを保証できるので、バグ潰しに有効な道具だと思う。

 

SPAにすればバックエンドはAPIサーバーでしかないので、基本的には何でもいい。

ここでは一応関数型の代表例としてHaskellを挙げたまで。

ElmコンパイラーはHaskellで書かれているそうなので、ElmとHaskellなら親和性も高いのではないかと思った次第。

 

Vue、Reactは?

部分的な利用なら、VueやReactでもいいと思うけど、大規模になるならElmにしておきたい。

jQueryの代わりにVue.jsを使う程度?

 

Vue.jsやReact.jsを本格的に使い出すと、Nuxt.jsやNext.jsやTypeScriptを使うことになるので、そうなるとフロントエンドもバックエンドも全てJavaScriptのエコシステムで構築することになる。

JavaScriptあるいはTypeScriptとElmを比べて、どちらが書きやすいか?そこが1つの分かれ目だな。

 

HTML部分のテンプレート記法は、Elmの全てを関数として書く方法と、ReactのJSXのどちらがいいか?

これは優劣をつけるものではなく、単なる流儀~DSLの問題なので、慣れればどっちでもOKだろう。

 

SSR、SSGはどうする?

サーバーサイドレンダリングは、従来のWebアプリケーションフレームワークだと、

などの選択肢もある。

LLなのでコンパイルも無く、開発は楽だろう。

 

どれを使うにしてもフレームワークへの依存度は下げておかなければいけない。

=いざとなれば、フレームワークをすぐに交換できるような設計にしておかなければいけない。

 

nrslib.com

 

 

開発の工数で使い分け

最初のプロトタイプやβ版では、綺麗に作り込む必要はない。

どうせ後でリファクタリングが必要になるからだ。

 

リファクタリングを必要としないWebサービスは、需要がない~存在価値がない、とも言える。

アクセス数が多く、需要が高いWebサービスだと、結果的に改良が必要になり、それに伴いリファクタリングが実施されるはず。

 

  1. 最初は手抜き&時間でサクッと作る。
  2. 作り直しが必要になった段階で、改めてきちんと設計して、時間をかけてじっくり作り込む。

 

手抜き&時短の開発

 

欲を言えばキリがないから、この辺りでまずは公開してしまう。

 

リファクタリングでじっくり作り直し

一切妥協せずに、自分が理想と思う方法で作ればいい。

他人から見れば、単なる自己満足でしかなく、「言うほど良いものではない」という状況も予想されるが、まあいいだろう。

最初から完璧主義に陥って、作業が進まなくなるよりは、「後から作り直せばいいや」という割り切りで、まずは前進した方がいいから。

 

いくら素晴らしいアイデアがあっても、実現して世に公開されなければ、それは他人から見ればアイデア自体が存在していないことと大差ない。

 

まとめ

段階的な開発でOK。後でもっと良い方法が見つかれば、順次差し替えていく。

 

  1. 手抜きの試作品:LAMPスタック
  2. リファクタリング:Elm+Haskell

 

時間の遅れが生じないことが大事と肝に銘じて、焦らないで淡々と進めよう。