でも、クライアント用のコードとサーバー用のコードは基本的に言語が同じだけの別物と考えたほうがよく、あまり共有できるものがなかったりします。
それでは悔しいので、共有できそうなコードをピックアップしてみました。
その1: 汎用的なライブラリ
まあ最初はコレです。本当に汎用的なものはnpmで公開できますし、そこまで汎用的でないものでもプライベートリポジトリを使えます。
クライアントサイド用のコードはWebpackでバンドルしてしまいましょう。
その2: パラメーター値の検証
入力フォームからデータを送信するときはもちろんサーバー側で値を検証するわけですが、応答性を高めたり無駄な通信を防いだりする目的で、データ送信前にクライアント側でも値を検証することはよくあります。もちろんその場合、検証内容(正の整数か、メールアドレス形式か、8文字以上か、etc…)はクライアント側でもサーバー側でも全く同じです。
ということは、共通化できますね。
というわけで、値の検証にはadjusterを使いましょう。
その3: APIの型情報
TypeScript限定の話になってしまいますが、Web APIが受け取る/返す型の情報も共通化できますね。チームで開発していて、いつの間にかAPIの挙動が変わっていたという経験はありませんか。
例えばユーザー情報取得APIがこんな情報を返したとして
interface User { id: number; name: string; email: string; }これをサーバー側の「ユーザー情報を返す関数」とクライアント側の「サーバーからユーザー情報を取ってくる関数」の型情報として使えばOK。
「やっぱり
email
が入ってたらスパムの温床になりそうだからやめるか」という場合、このインターフェースを変えるだけで済みます。クライアント側でこのemail
を使っているところがあればビルド時に型エラーでコケるので、仕様変更に気づかずにリリースしてしまうのを防げます。
0 件のコメント:
コメントを投稿