Webサービスの処理の分け方!

Silicon Valley Super Ware

2020年6月14日


Webサービスの処理の分け方!

Webサービスを作る上で必要な処理にはどんな物があるか考えた事ありますか?
これを良く考えて、作り方を考えると将来「管理しやすい」作り方にする事が できます。

Vue.jsを軸にWebサービスを作る場合、UIとデーター処理に大きく分ける事ができます。

UIはユーザーインターフェース、すなわち利用者の「操作」に関連した処理と データ処理は扱うデータをどのように「扱う」かの処理です。

なぜUIとデータ処理を分けるのか?

一番簡単な方法は全てを一緒に実装してしまう事です。 利用者の操作に伴うデータ処理を全て一緒にJavaScriptで書いてしまうという事です。 多くの方が、フレームワーク(ライブラリ)を利用してサービスを作るという場合に こうした作り方をしています。
4月、5月に作ったお問合せフォームのようなサービスはこの作り方でも余り問題がありません。 理由は簡単で、データの処理自体が余りないからです。
仮に全部作り直したとしてもたいした労力にはならないからです。

複雑なサービスになると事情が変わります。作り直すのは大きな作業になるからです。

そこで、UIは、利用者の操作の処理までにして、実際の処理は「データ処理」を 呼び出すような構成にして、別の部分でデータ処理をするような作り方が有利になります。
こうすると、利用者の要望でUIを変更しても実際のデータ処理は余り手を加える必要性は 大きく減ります。同様に、データ処理の性能を改善する場合も、利用者の操作の処理部分に は触れる必要がなくなるため、完全に独立にプログラムを管理できるようになります。
問題が起きた場合のデバッグも、問題は操作の処理にあるのか、データの処理にあるのかを 切り分け安くなるため、原因を特定しやすく結果的に効率的なデバッグが可能になるという メリットもあります。

データの一元管理

データを一元管理する場合、Vue.jsだと、VUEXを使う場合が多いですし、 Reactの場合はREDUXを使う場合が多くなります。
この場合、データ処理をVUEXやREDUXに集約するとこのUIとデータ処理を分けやすくなります。

実際の実装では、データ処理をさらに分割した方が便利な場合が多くなります

それは、VUEXやREDUXで管理するデータの部分と、そのデータを取得したり、加工する部分に 分ける事です。
例えば、今回のJSON Placeholderを利用したREST APIの実装の場合、 ブログで連載した部分では、「投稿データ」「コメントデータ」「ユーザー一覧」の データをVUEXで管理しています。
しかし、これらのデータを表示する際は、投稿データとユーザーデータを同時につかったり、 投稿データとコメントを組み合わせて表示をする方が利用者に便利な表示を作る事ができます。
この場合、投稿データとユーザーデータを使って、表示の為のデータを作る必要があります。

機能をどう作るか?

データを取得する場合は、「actions」の部分にデータをネットワーク経由で REST APIを利用して取得する処理を書いて、結果を「mutations」に送って挙げれば VUEXの「posts」「comments」「users」といった、「state」で管理するデータを更新できます。
表示の際も、「getters」でposts/usersのデータを使って、表示用のデータを作る処理をすれば 実現できます。

こうすれば、Vueファイル(xxx.vue)でUIの操作の処理、VUEXでデータの処理という 明確な線が引けます。

今月のテーマの実装にはこの方法で大きな問題なく実装できて、 データの処理とUIを綺麗に分離する事ができます。

サービスが大きくなり場合は要注意!

gettersは便利なんですが、欠点もあります。 getterの処理はキャッシュされる場合が多く、gettersに必要以上に処理を入れると 全体の処理性能が落ちる事があります。
もう一つは、Vue.js + VUEXという実装では大きな問題になりませんが、 将来的にフレームワーク(ライブラリ)を変える必要がある場合です。
例えば、最初は「Vue.js」 + 「VUEX」で作ったけれども 将来は、「React」 + 「Redux」に乗り換える可能性がある場合です。
データ処理側は、「Vuex」に書いているので、「Redux」を使う場合は 多くの部分を書き直す必要があります。 しかし、別の「class」を作って、実際のデータ処理を別の部分に移して Vuexでは、「state」のデータの更新を中心にすると、Reduxに移行する際も より簡単に行こうできます。
制作後に、別のフレームワークに切り替えるケースは少ないのかもしれませんが、 将来の予想される展開によっては、フレームワークを変更する事も考える必要が あるかもしれません。その場合は、更に処理の分割を勧めた方が上手くいきます!
シリコンバレースーパーウエアでは、シンプルなWebサービスの作り方だけではなく、 より複雑なWebサービスをテーマにした講座も同時に提供しています。 さらに、作ったWebサービスを利用したビジネスの展開まで考えたWebサービスの 作り方がわかるようになります。

興味のある方は今すぐお問合せください!



またよろしければ、ニュースレターの登録をお願いします!大体週一回お届けしています。ブログよりは一歩踏み込んだもっと濃い内容を発信しています。


Copyright(c) 2020 by Silicon Valley Super Ware, all rights reserved.

コメント

このブログの人気の投稿

ユーザーインターフェースの設計

足し算以外もできるようにする

改良版足し算プログラム