Closed5
memo @240105＊
nakamotoNeon
- Neonは、WebSocketを使ってDBへのリアルタイムアクセスを提供するというアプローチをとる。
TCPではなくWebSocketを使ってDBにアクセスするというのは画期的。 - ただWebSocketだと最初のコネクション確立に時間がかかってしまうのと、
型のサポートも弱い。そもそも日本だとシンガポールリージョンがもっとも近そう。
nakamotoPrisma
- ORMとしてはわりと一強に近づいてる。
- Prisma Data PlatformのAccelerateとPulseを提供してる。
- Accelerateは東京リージョンがあるものの、コールドスタートの問題は依然としてある。
CFWorkers環境におけるPrisma
- Prismaは高度なクエリ最適化エンジンにより多くの機能を提供するため、大きなバンドルサイズが必要となる。このサイズは、CFWorkersの許容するデプロイ可能なバンドルサイズを超えるため、CFWorkers環境にそのまま適用するのは難しかった。その結果、Prismaはdrizzleやkyselyのような軽量なORMやクエリビルダと比べ、CFWorkers上でのネイティブ動作への適応が遅れてしまった。
- Prismaにはprisma-kyselyというライブラリがあって、Prismaでスキーマを定義するけども実際にクエリを投げるのはkyselyだから使い勝手はいい。
CFWorkers上で動かせることがなぜ大事なのか
- VercelのEdge Functionsは裏側がCFWorkersになってるため。そのためNext.jsのRoute HandlersやAPI Routesをエッジ環境で使用すると、DBに直接アクセスでき、中間層の必要性を減らせる。このアプローチにより、エッジコンピューティングからデータベースへの直接アクセスが可能になり、インフラ設計が簡略化される。Vercelを使用できる場合はVercelとNext.jsを、使用できない場合はCFWorkersとRemixやAstroを選択し、あとは好きなDBを組み合わせれば、アーキテクチャに悩む必要がほとんどなくなる。
nakamotoHyperdrive
- データベースとエッジコンピューティングの間に設置される比較的寿命の長いコンピューティングリソース。その主な役割は、データベースとの間に予めコネクションを確立し維持すること。CFWorkersから、リクエストのたびにコネクションを確立する必要があることには変わりないが、接続の対象はオリジナルのDBではなく、物理的に距離が近いHyperdriveであるため、再接続によるレイテンシを大きく削減できる。
Hyperdriveが必要となった背景
- CFWorkersはTCPのダイレクト接続を実現し、CFWorkersからの外部DB利用が大きく加速したが、コネクションの確立と維持、地理的な距離によるレイテンシの問題などいくつかの課題があった。これらの課題は、特にステートレスな設計のWorkersを利用する際に顕著に現れる。
往復の発生とステートレス性
- TCPとTLSでのDB接続には、コネクションを確立するためにネットワーク上での往復が発生する。一般的なステートフルなサーバなら、一度DBとのコネクションを確立したら、以降のリクエストに関してはコネクションの再利用ができるので高速にクエリを解決することができる。しかし、CFWorkersはステートレスな設計なのでリクエスト間でコネクションを再利用することはできず、パフォーマンスと効率性に影響を与える。
地理的な距離とラウンドトリップ
- CFWorkersなどのエッジコンピューティングの利点はクライアントが物理的に近い距離のリソースから低遅延にレスポンスが得られることであり、それは、全世界にコンピューティングリソースが配備されていることによって成り立つ。しかし、データベースは一般的に特定のリージョンに配備されるため、使用するエッジロケーションによってはDBとのラウンドトリップタイムが長くなり、パフォーマンスにばらつきが生じる可能性がある。特に、コネクションの再利用ができない環境下ではこのラウンドトリップによる影響が大きな問題となる。
nakamotoTurso
- SQLiteデータベースのレプリカを世界中のリージョンに配備するアプローチを採用する。この方法により、データベースが分散され、どのエッジロケーションからのアクセスでも、地理的な影響が小さくなる。読み取り操作ではレプリケーションに対してクエリを投げるため高速だが、書き込み操作ではプライマリデータベースへの接続が必要でこれが課題となる。また、Cloudflare D1の登場により、SQLiteベースである点でTursoと競合する可能性がある。
nakamotobestofjs
- 1位はshadcn/uiとなってて出てきたタイミングもよかった。
RSCが出てきたときにCSS in JSは基本的に使えなくなってしまって、
RSCに対応するのにいずれも時間がかかってしまった。 - npmパッケージではなく、コードを自ら管理するというのが斬新。
このスクラップは2024/01/07にクローズされました