Posts

NestJSを用いAPI作成をしているのだが、Responseを共通化したいと思ったので、実装してみた。 Responseの定石 とは言えそもそもResponseの形をどのようにするのがいいのかわからなかったので調べた結果、omniti-labs/jsendが参考になりそうだった。 これを参考に以下のような型で返すことにした。 export interface Response { status: 'success' | 'error'; data: any; message: string[] | null; } ValidationPipeを使用する場合、エラーレスポンスの形式はBadRequestExceptionがデフォルト たぶんドキュメントにある通り（Documentation | NestJS - A progressive Node.js framework）なので、ほとんどの場合ValidationPipeを使用することになる。 そうするとエラーレスポンスの形式はBadRequestExceptionがデフォルトになるので、以下のように返ってくる。 { "statusCode": 400, "message": "Bad Request Exception", "error": "Bad Request" } これは意図した形ではないのでカスタマイズする必要がある。 http-exception.filter.tsを作成する カスタマイズするにはそれ用のException filtersを用意する必要がある。 Exception filtersとは、 Nestには例外処理レイヤーが組み込まれており、アプリケーション全体で処理されない例外をすべて処理する責任を負っています。アプリケーションのコードで処理できない例外は、このレイヤーでキャッチされ、適切なユーザーフレンドリーな応答が自動的に送信されます。 というものらしい。 とにかく例外フィルターは、NestJSアプリケーションが例外をキャッチした場合に呼び出されるらしい。 実装は簡単 まずはhttp-exception.filter.tsを作成する。 import { ExceptionFilter, Catch, ArgumentsHost, HttpException, } from '@nestjs/common'; import { Response } from 'express'; @Catch(HttpException) export class HttpExceptionFilter implements ExceptionFilter { catch(exception: HttpException, host: ArgumentsHost) { const ctx = host....

ER図の種類 そもそも知らなかったがER図には複数の書き方があるらしく、有名なのは「IE記法」と「IDEF1X記法」というものらしい。ふたつの記法は似ているがカーディナリティの違いがあるとか。 IDEF1X記法はリレーションを「●」などで表現することが特徴でIE方より細かい表現ができるが、その分直観さが失われるらしい。複雑なのは避けたいので、今回はIE記法で進めていく。 そもそもIE記法しかないと思っていた……。 カーディナリティの種類 記号 意味 ○ 0 l 1 鳥の足（3つ股の線） 2以上 主にこんな感じの記号を駆使していく。 実際にやってみる 内田百閒という好きな作家でER図を作っていく。 ちなみにおすすめは、下記３作品。 １対１の関係 これはまあ、シンプルに内田百閒とその詳細を表すときが該当する。 例えば内田百閒という漢字とその読み方を表すと下記のようなER図になる。 内田百閒という作家名は「うちだひゃっけん」という読み方しかないので、１対１の関係になる。 １対多の関係 良く使われる表現だが、曖昧な状況を表している。 「1対多という関係は決まっているが、それ以上は決まっていない」という、データベース設計の初期段階の時に使う。 設計が進むにつれ、「1対0以上の関係」「1対1以上の関係」のように具体化してく必要がある。 例えば内田百閒とその作品はこれに該当する。 内田百閒はたぶん複数の著作を持っているので、１対多の関係になる。 1対0以上の関係 それじゃあ、１対多の関係を具体化していく。 １対多とはいえ、１に紐づくものが０の場合も存在する場合は、1対0以上の関係になる。 過去に遡り、百間がまだ著作を出版していなかった時、下記のようなER図で表現できる。 もしかすると百間は著作を出版することなく人生を終える可能性もあるので、0を許容する必要がある。 そういう場合は1対0以上の関係になる。 1対1以上の関係 とはいえ、百間は最高の作品を複数残した。 そのため、少なくとも1件以上は彼に紐づけることができる。 つまり、1対1以上の関係の関係になり、下記のように表現することができる。 多対多の関係 なんとなくこれがいまいち理解できてない気がする。 そして内田百閒だけだとこれは表現できない気がするので、「作家」と「出版社」というリレーションにする。 作家は0以上の出版社から本を出版することができ、出版社から出版する人が0人以上いる。 うん、そういうこと。 たぶんここら辺を理解できれば問題ないと思われる。 あとは結局数をこなしていけば、必然的に覚えれる。

Objectを返すPipe template側で展開するとこんな感じのやつ。 value | customPipe |json {hoge:'hoge', fugo:'fugo', piyo.'piyo'} 参照方法は簡単 (value | customPipe).hoge // hoge で参照できる、ただこれだけ。

WordPressの記事管理に頭を悩ませてきた。 で、行きついた先が、今後のことを考え、WordPressの記事をGitで管理しGithubに一元管理することにしただったのだが、色々運用を決めていくとどうにも面倒で仕方なくなってきた。 Githubでの運用方法 書きたい題材が見つかった時にIssueをたてる Issueからブランチをきり、記事を作成する プルリクを作成する 記事をWordPressにコピペ 公開 プルリクを承認する という手順を自らに課したせいで、更新が億劫で仕方なかった。 そんなときに救世主であるWordPress PostというVSCodeの拡張機能にであった。 WordPress Postとは？ この Visual Studio Code 拡張機能は、WordPress に記事を投稿するアクションを提供します。これは、人々が Visual Studio Code を使用して Markdown で WordPress 記事を作成するのに役立ちます。 簡単に言うと、VSCodeで記事を書き、WordPressの管理画面を開くことなく、公開まで持っていける。 という最強の拡張機能！ 使い方は作者のブログに詳しい。 これにより先ほどの手順が驚くほど簡略化された。 WordPress Postを使った公開手順 記事を下書き設定で書く WardPressからカテゴリ・タグ・アイキャッチ画像を選択 公開 WardPressからカテゴリ・タグ・アイキャッチ画像を選択 は個人的に独自の手法を使っているのでまあ仕方ない。 管理画面に行かなくてはいけないものの、相当簡略化された。 さらに当然Git管理も問題ない。 来世でも使うと思われるVisual Studio Codeの拡張機能をまとめてみた間違いなく、こちらの記事に更新をかけ、追加するべき拡張機能である。 だがしかし、過去にこれで管理してないファイルはどのように対処する必要があるのか…? たぶん、過去のは二元管理になるかしら。 とは言え、この拡張機能が素晴らしいことは間違いない。

依存関係をインストールする npm install --save @nestjs/swagger main.tsを編集する async function bootstrap() { const app = await NestFactory.create(AppModule); // Swaggerの記述 const config = new DocumentBuilder() .setTitle('Cats example') .setDescription('The cats API description') .setVersion('1.0') .addTag('cats') .build(); const document = SwaggerModule.createDocument(app, config); SwaggerModule.setup('api', app, document); await app.listen(3000); } bootstrap(); 後は上の記述を編集し、http://localhost:3000/api/を開けば作成されている。 非常に楽なので活用していきたい。 APIをグルーピングする これだとcatsというタグができるがその中は空になり、すべてがdefaultにグルーピングされる。 任意のグルーピングを作りたい時は、hoge.controller.tsを下記のように変更する。 import { Controller } from '@nestjs/common'; import { ApiTags } from '@nestjs/swagger'; @Controller('hoge') @ApiTags('hoge') export class HogeController { constructor(private readonly sService: HogeService) {} これで意図した形になる。