https://panda-program.com/posts/why-frontend-engineers-have-self-deprecation
フロントエンドエンジニアの間では、「私の仕事は JSON に色を付けることです」という有名な自虐ネタがある。 おそらく初出は以下のツイートなのだろう（*1）。ただ、出典はあまり詳しく調べていない。
初めてこの言葉を見た時、面白い言い回しだなと思った。確かにフロントエンドの仕事にそういう側面はある。
実際、コンテンツの表示がメインのページで作業すると上記のような気持ちになる。この場合、フロントでやることといえばせいぜい日付の表示形式を適切にフォーマットするくらいだ。結局バックエンドからデータが返ってこないとフロントだけでは何もできないと思うこともある。
もちろん、フロントだけで簡潔する手書き風グラフ作成ツール excalidraw のようなものは別だし、フロントで複雑な状態を扱う部分を書いたり、フォームを使ってユーザー入力を受け付け、入力値を検証するバリデーションをしてからバックエンドに POST リクエストを送るような処理を書いていると、自分は JSON 色付け係だなんて思わない。やっぱりフロントエンドエンジニアは必要なんだなと思う。
ただ、なぜフロントエンドエンジニアは JSON 色付け係と自虐（自己卑下）するのか。
この言葉を知った時には次のように考えた。自分達はインフラやバックエンドのように高度なエンジニアリングをしているわけではなく、API から送られてくる JSON のデータをユーザーに表示しているだけで大したことをしていないという感覚を誰しもが持ったことがあるからだと。
しかし、これでは JSON 色付け係という言葉が指していることを説明しただけで、言葉が使われて受け入れられる背景にまでは辿り着けていないなあと漠然と思っていた。
そのうち「JSON 色付け係」という言葉は Twitter のタイムラインであまり見なくなった。 しかし、最近ある偶然から「JSON 色付け係」という言葉を使うメンタリティはこれだという洞察を得たので、ここで紹介したい。
その偶然とは、PoEAA本で DTO を調べてみたことである。調べた内容を 「GraphQL と Data Transfer Object は似ている」 という記事にした。そこで DTO は XML にも JSON にもシリアライズできるものだと書いた。
すると、その記事を読んでくれた元同僚が「CQRS を考案した Greg Young 氏が、DTO を介してサーバーとクライアントがやり取りするとドメイン知識は失われてしまうと指摘している」と教えてくれた(*2)。
CQRS の文章を読むと確かに以下のように書かれている。抜粋した文章はクライアントから送られてくる DTO をバックエンドで処理する際の指摘だが、Greg Young 氏が考えている課題の内容が伝わってくる箇所だ。
One cannot even create and Anemic Domain Model with this architecture as then all of the business logic would be in services, here the services themselves are really just mapping DTO’s to domain objects, there is no actual business logic in them. In this case a large amount of business logic is not existing in the domain at all, nor in the Application Server, it may exist on the client but more likely it exists on either pieces of paper in a manual or in the heads of the people using the system.
CQRS Documents by Greg Young, p.7
超訳すると以下のようになる。
「クライアントから送られてくる DTO をバックエンドで受け取ってサービスが DTO をドメインオブジェクトに変換するだけだと、ビジネスロジックとドメイン知識がすっかり失われてしまう。ドメイン知識はクライアント側に存在するかもしれないが、それよりも紙のマニュアルやシステムを使う人の頭の中の方にあるのだろう」