私がTypeScriptで `interface` よりも `type` を好む理由
テックリード @ 株式会社カケハシ 医療SaaSの共通基盤を開発。TypeScriptと関数型プログラミングで堅牢なシステム設計を実践。 はじめに TypeScriptで型を定義する際、interface と type のどちらを使うべきか。これは、多くの開発現場で一度は議論になるテーマではないかと思います。 世の中の多くのドキュメントや記事では、クラスへの implements のしやすさや、interface が持つ「宣言のマージ（Declaration Merging）」の利便性が紹介されることもあり、interface の利用が推奨されるケースもよく見かけます。 しかし、特にサーバサイドアプリケーションや、ある程度規模のあるシステムを開発する上で、私はこの「宣言のマージ」機能が、時として予期せぬ挙動や、場合によってはセキュリティ上のリスクを静かにもたらす要因になると感じています。
ユーザーの内部IDの発行権を他人に握らせてはいけない
テックリード @ 株式会社カケハシ 医療SaaSの共通基盤を開発。TypeScriptと関数型プログラミングで堅牢なシステム設計を実践。 結論 ユーザーの内部IDを自システム以外に委ねるべきではありません。 ユーザーの内部IDの実装について気をつけるべきことを2つ紹介します。 外部サービスが発行したIDを内部IDにするべきではない ユーザーが変更可能な値を内部IDにするべきではない 外部サービスが発行したIDを内部IDにするべきではない 外部サービスが発行したIDを内部IDにすることは避けましょう。 内部IDは、システム内で一意で永続的な識別子であるべきです。 例) 外部IDプロバイダのユーザーID 例えば、GoogleをIDプロバイダとして利用する上で、GoogleアカウントのユーザーIDをそのままユーザーの内部IDとして使用した場合、どんな問題が起こるかを考えてみましょう。 例えば、後
Go コンパイラのコードを読んでみよう
テックリード @ 株式会社カケハシ 医療SaaSの共通基盤を開発。TypeScriptと関数型プログラミングで堅牢なシステム設計を実践。 はじめに 本記事は、 DeNA Advent Calendar 2020 の 11 日目の記事です。 突然ですが、「コンパイラのコードを読んでみよう」なんて言われても、「どうせ巨大で難解で複雑なロジックを理解しないと読めないんでしょ？」と思いませんか。 コンパイラの構造を理解しようとしても聞いたことのないような専門用語がずらりと並び、コードを読もうとしたらそれらをすべて完全に理解してないと一行も理解できないんじゃないか…。Go のコンパイラ gc のソースコードを読むまでは、私もそう思っていました。 しかし、あまりにも暇な休日のある日、思い立って gc のコードを読んでみました。すると、「コンパイル」という難解な響きの処理も、一つひとつを小さなタスクに分
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
