はてなブックマーク

はじめにlink あまりモノレポの構成について語られている記事が多くないなと感じたので、現時点で自分が考えている設計をまとめてみる。 以前にTwitterでディレクトリ構成と内容については言及したが、実際に利用する技術についてはあまり触れなかったので改めて検証してみた。 https://twitter.com/koh110/status/1617510034266808322 クライアントサイドとサーバーサイドのコード共有については下記の記事がよくまとまっていた。 https://capelski.medium.com/effective-code-sharing-in-typescript-monorepos-475f9600f6b4 上記の記事の構成も参考にしつつ、自分の考えも加えて検証していく。 相対パスを利用する方法 npmのローカルパス指定（file:xx）を利用する方法 シンボ

はじめにlink 実践Node.js入門という本が技術評論社さまより発売されます。人生初の単著です。 発売日は2023/01/26です。 電子書籍版はKindleとGihyo Digital Publishingから購入できます。 Amazon 技術評論社様のほうではPDFとEPUB形式で購読可能です。 https://gihyo.jp/book/2023/978-4-297-12956-9 内容link Node.jsの入門書です。実際にアプリケーションを作成、運用するためのノウハウを全て詰め込みました。 Node.jsの基礎知識、特徴や活かし方、アプリケーションの開発、設計の考え方、運用、テストの方法、パフォーマンスチューニングなどに触れながら解説していきます。 本書はNode.jsをほとんど知らなかった新卒のころ自分に、今の自分が全力で教えるというコンセプトで書き進めました。 当時の

はじめにlink Redis Streams とはざっくりいうと Redis v5 から加わった Pub/Sub とはまた違うキューイングの仕組みです。 https://redis.io/topics/streams-intro Pub/Sub は Subscribe したら揮発してしまうのに対して、Streams はキューが詰められるときに指定した Max を超えたものが押し出されて消える仕組みです。 登録した Stream に対して購読グループを複数作ったりすることで、1 つの Stream に対して個別のグループで購読管理ができたりします。（Kafka で導入されたアイデアを輸入したもの） 今回は上記のグループを使わずにキューを複数プロセスで受け取る実装のサンプルと、自分が勘違いしていた部分をまとめます。 Stream を触ってみるlink キューの追加は XADD というコマンドを

課題link お手伝いしているシステムでNestJSを採用しているバックエンドのテストが遅いという課題があったので対処した。 前提link フレームワークDBテストランナーその他 テストの総数は700弱。 最終結果link 最終的には2段階の改修を経てローカルのテストが3倍速程度高速化した。 # before Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 total Snapshots: 0 total Time: 925.063 s Ran all test suites. Done in 926.48s. # ts-jestを@swc/jestに置き換えた Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 t

Core Web Vitals とはlink 最近のフロントエンド周辺では Google が提唱した Web Vitals と呼ばれる指標が非常に注目されています。 これは Web で多くのユーザーが快適なユーザー体験を得るために、こういったポイントに特に気を使いましょう、というものを数値化したものです。 この中でも特に重要と定められている “LCP (Largest Contentful Paint)”, “FID (First Input Delay)”, “CLS (Cumulative Layout Shift)” の 3 つは Core Web Vitals と呼ばれています。 それぞれの観点を簡単に説明すると次のようになります。 LCP: 重要な要素がどれだけ早く読み込まれたか FID: 最初の入力ができるまでにどれくらいかかったか CLS: がくっとレイアウトが変わることがな

Node.js において Stream の処理というのはなくてはならないものです。しかし Stream の文法は慣れるまでは扱いにくいものです。 しかし、AsyncIterator の登場によって Stream を Promise の文脈で処理することができるようになり、「async/await に取り込み」「包括的エラーハンドリング」などができるようになりました。 ２年ほど前に AsyncIterator について記事を書きました。参考: さよなら Stream 以前に書いたときにはまだ Experimental な API だったため気軽に利用することはできませんでしたが、今はもう Stable なので、より色々なシーンで活かせる機会が増えるでしょう。 そこでこの記事では今まで書きにくかった Stream や Events のスマートな扱い方、その落とし穴と回避方法をまとめます。 fo

近年の Node.js は API のサーバとしてはもちろん、Nuxt.js や Next.js といった SSR や BFF などフロントエンドのためのバックエンド言語としての人気が高まっています。 フロントエンドエンジニアがコンテキストスイッチ少なくバックエンドの整備ができることは非常に大きな利点です。 ですが、フロントエンド（ブラウザ側）とバックエンド（サーバ側）ではパフォーマンスチューニングで見るべき点が大きく違います。 しかし Node.js アプリケーションのパフォーマンスイシューの見つけ方などがまとまっている資料は少ないです。 そこで、本記事ではフロントエンドエンジニアが Node.js でパフォーマンスイシューを見つけ、改善するため自分が普段パフォーマンスチューニングを依頼されているときにみている基礎的なポイトをまとめていきます。 1. 計測ステップlink Node.js

はじめにlink MongoDB (node-mongodb-native) + Node.js + TypeScript で RDB 並のスキーマ定義と、NoSQL の開発しやすさを両立できたのでまとめます。 Node.js と MongoDBlink MongoDB はドキュメント指向データベースです。簡単に言えば JSON のような形でデータを保持できる NoSQL です。 MySQL や Postgres などの RDB と違い、事前に CREATE TABLE のようなコマンドを打たなくても、insert されたタイミングで collection が作成され、データが保存されます。 また、MongoDB は後発のデータベースということもあり、RDB では 1 クエリで素直に表すことが難しいクエリも多くがクエリ化されていて 1 トランザクションで実行が可能です。（findOrUpd

まえおきlink 自分は普段 MacBook Pro の 13 インチを開発機として利用しています。メモリは 16GB にしているので Web 開発をする時にはあまり不便に感じることはありません。 ただ、サービスの開発のステージ環境や、自宅内の自動化や副業で受けている調査案件などはそれぞれ環境ごとに仮想サーバを立ち上げています。 仮想サーバは nuc に入れた Windows 上の Hyper-V で運用しています。nuc は 24 時間立ち上げたままでテレビにつないで Amazon プライムの再生機も兼ねています。 メモリも 32GB 積んであるので開発サーバが立ち上がってても通常使用するぶんには割と余裕があります。 この自宅環境は割と便利で、自宅で開発しているときは十分活躍してくれるのですが、外出中にも開発サーバに ssh で入りたくなることがちょくちょくあります。（あーあのサーバにコ