はてなブックマーク

クリーンアーキテクチャというと設計における銀の弾丸のように扱われていて、クリーンアーキテクチャを導入するという記事をよく見ます。しかし自分の経験だとクリーンアーキテクチャで書かれているのにもかかわらず開発効率が落ちているという事が多く、いつでも使っておけばいいというものではないと思っています。 最近目にしたクリーンアーキテクチャに対する批判 本筋ではないので詳細は省きますが、あるとき[1][2]にUncle Bobの著書であるCleanシリーズへの批判をXで見ました。 ここで一番載せたかったものが今見つけられないのですが、以下のようなポストがありました。 書籍クリーンアーキテクチャに書いてある内容を抜きにして起こった現象だけを見るとマイナスの方が多い このポストが自分の感じていることを端的に表現できているように感じました。書籍クリーンアーキテクチャの内容を悪いと思いませんが、その影響により

Next.js App Routerのリリース以降、 async function で書けるServer Componentsいいじゃんファイルベースルーティングも使いやすいなと触ってたのですが、まだ安定していないこともあり不可解なエラーメッセージや複雑なキャッシュの仕組み、デプロイ先を選ぶ感じなどこのままNext.jsにベットしてていいのかなと感じていました。 そんな折にHonoでシンプルなフォームを持つWebアプリを書く機会があり、非常に優れた開発者体験に驚きました。5年以上前にMPAを開発した経験もありますがそこから比べてもとても良くなっていて、Honoの良さを感じるとともにMPAというアプローチを見直すきっかけになりました。 そもそも現在Webフロントエンドを構築する際に当たり前のように選択肢に上がるSPAですが、必ずしもSPAが適していない場合でもSPAが選択されることが少なくな

2022年上半期はとある都合もあってかなりの数の技術書を読んだので、その中でも良かったものとかの感想をまとめておきます。 2022年上半期で一番良かった技術書 A Philosophy of Software Design ソフトウェア設計の目的は複雑さを軽減することであるとして、その複雑さの定義と軽減する手法が書かれています。最近まで2年ほどフリーランスで色んな会社の開発に参加して、DDD的な設計やクリーンアーキテクチャを採用している現場が多かったもののそれらが逆に開発効率を低くしているのではという感想を持っていました。そこでこの本を読み、それらの目的であるはずの「複雑さを軽減する」という視点が抜けていたのかなと気付かされました。コードを読み書きしていて複雑さを感じなければモノリスでもMVCでもいいケースは多いと思います。複雑さを軽減する手法を解説する章では、やりすぎると逆効果であるとは

Webフロントエンド向けにGraphQL/REST/gRPCがよく比較対象になるので雑にまとめたい。 WebとiOS/Androidなクライアントに対して静的型を生成したいときというユースケースがメイン。マイクロサービス間通信とか他の用途ではまた別の議論があると思う。 筆者はGraphQL推しなのでそこがメインの主張になると思うけどREST/gRPC側の意見も是非聞きたい。 「Webフロントエンド向け」という前提を置くとGraphQLにしかない大きなアドバンテージがあると思ってて、よくあるのがリソース指向でAPIを定義したいサーバーサイドと、画面・ユースケースベッタリなAPIがあると便利なフロントエンドでこのミスマッチをどう解決するかというやつ。 REST/gRPCだと、クライアントサイドでJOINするか、BFFを置いてリソース指向のAPIを画面向けに束ねる処理を書くかしかないと思う。Gr

タイトルのとおりです。この本を読まずにGraphQLについての記事を書いたりしツイートしてたのが恥ずかしいくらいに良質なプラクティスが記載されています。GraphQLを採用して悩むことのほとんどはこの本に書いてあるくらいな印象で、この本を読むと効率よくGraphQLを使った開発の品質を向上できると思います。 どんな人が書いた本なのか 著者はMarc-André Girouxという方で、GitHubとShopifyに勤務しGraphQL APIを開発する仕事をしていたと書籍に書いてあります。GraphQLをやってる人ならこの時点でもう刺さったかもしれませんが、どちらの企業もGraphQLを採用していることで有名です。GraphQLスキーマを設計する上でGitHubやShopifyのスキーマや記事を参考にする方も多いのではないでしょうか。その両方で働いてたという時点で納得の説得力です。Grap

これまでいろんな現場でWebフロントエンド開発をしてきて、メンテナンスしやすく効率の高いWebフロントエンド開発をする上で重要になる考えが自分なりにまとまってきたので記事にしてみます。 Worse is Betterという考え方 自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。 少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必

GraphQLのクライアントといえばApollo Clientが使われることが多いと思いますが、urqlというクライアントをおすすめする記事です。 TL;DR urqlのドキュメントキャッシュはApolloみたいなキャッシュ管理が要らなくて楽だからおすすめ ドキュメントキャッシュは、Mutationの __typename を見て汚れたキャッシュを捨てる仕組み Mutationのあと refetchQueries やってるならそれはurqlが自動でやってることと同じ なぜurqlをおすすめするのか この記事ではurqlのドキュメントキャッシュというキャッシュを仕組みだけを紹介します。雑に言うと、Apolloの正規化されたキャッシュより多少効率は落ちるものの煩雑な正規化されたキャッシュの管理から解き放たれるというものです。Apolloのキャッシュの管理に疲れた人にめちゃくちゃおすすめですし、

GraphQL Working Groupで進められている標準化で先日Stage 2に上がったProposalである @defer, @stream ディレクティブの概要をさらって動作を試してみる記事です。 参考記事 以下の記事に詳細な情報が書いてあり、この記事のほとんどはそれを参照したものです。 @defer, @stream ディレクティブの概要 GraphQLは画面に表示する情報を一度のリクエストで取得できる便利な技術ですが、その反面サーバー側で要求されたデータすべてが揃うまでレスポンスを返せないという欠点もあります。それを補うための仕様が @defer, @stream ディレクティブです。GraphQLのレスポンスを複数に分け、これらのディレクティブが付いたフィールドをあとから返すことで遅いデータにクエリ全体が引きずられることがないようにできます。 以下のような、 person