博士

やあ、ロボ子！今日はStringly Typedについて話すのじゃ。

ロボ子

Stringly Typedですか？それはまた面白い名前ですね。具体的にはどういうことですか、博士？

博士

Stringly Typedというのは、もっと適切な型があるのに、文字列をやり取りすることなのじゃ。たとえば、数値を文字列で表現したりすることじゃな。

ロボ子

なるほど。型情報が利用可能なのに、文字列を使うのですね。API呼び出しもStringly Typedになりやすいと記事にありました。

博士

そうじゃ！APIはリクエストとレスポンスのボディが文字列化されたJSONデータであることが多いからの。ほとんどのAPI呼び出しはStringly Typedじゃな。

ロボ子

たしかにそうですね。JavaScriptだと、型の損失は大きな問題ではないと書かれていますね。

博士

JavaScriptは型安全性の低い、弱く型付けされた言語じゃからな。でもTypeScriptだと話は別じゃ。

ロボ子

TypeScriptで`user`オブジェクトを`any`または`unknown`型として受信すると、型安全性が失われるというのは、よくありますね。

博士

そうじゃ！手動で型チェックが必要になるのじゃ。異なるチームがメンテナンスしているAPIに接続するSPAを構築すると、Stringly Typedインターフェースが問題になることが多いぞ。

ロボ子

ネットワーク上の型安全性を実現するために、tRPCやGraphQLなどの型付きAPIインターフェースがあるんですね。

博士

その通り！Stringly Typedなアプリケーションに対処したくないなら、これらの解決策を検討する価値があるのじゃ。

ロボ子

勉強になります！ところで博士、Stringly TypedなAPIを避けるために、APIエンドポイントをフロントエンドアプリケーションの一部と見なすというのはどういうことですか？

博士

ふむ、それは面白い視点じゃな。APIエンドポイントをリモート関数呼び出しではなく、フロントエンドの一部と考えることで、より型安全な設計が可能になるということじゃ。

ロボ子

なるほど！型情報を共有しやすくなるということですね。

博士

そういうことじゃ！ところでロボ子、Stringly Typedなコードを見てると、まるでスパゲッティコードみたいじゃな。

ロボ子

確かに、絡まってて解読が大変そうですね！

博士

そうじゃろ？でも、Stringly Typedなコードを直すのは、まるでスパゲッティをフォークで食べるようなものじゃ！