#
110
2024/8/29
今日のトレンド

Prisma TypedSQLとSnowflake など

こんにちは、マイクです!今日は2024年8月30日、金曜日ですね!今日も「zenncast」にお越しいただき、ありがとうございます。さて、今日はZennでトレンドの記事をいくつかご紹介したいと思います。

それでは、まずは「前回紹介した記事」のおさらいです。前回は「Remix on CloudflarePages + Prisma + Supabaseで銀の弾丸を目指す」や「生SQLに型を手書きする時代は終わり?Prismaの新機能「TypedSQL」」、それから「uvから始まるPython開発環境構築」についてお話ししましたね。

さて、今日の内容に移りましょう!今日は全部で5本の記事をご紹介いたします。

まず最初の記事です。タイトルは「PrismaのTypedSQLがなぜアツイのか」です。

このPrismaのTypedSQL、エンジニアにとって非常に魅力的なツールなんですよ!特に複雑なSQLクエリを扱うとき、その真価を発揮します。従来、Prismaでの複雑なクエリは直感的でなく、時間がかかることが多かったんです。例えば、特定のユーザーに関連する記事とそのコメント数を取得するクエリなどは、意図通りに実行できているかの確認に多くの手間がかかります。

従来の方法では生SQLを実行する際に型安全性が失われ、エラーも実行時にしかわかりませんでした。TypedSQLは、シンプルなクエリはPrismaのAPIを利用し、複雑なクエリにはTypedSQLを用いることで、直感的に扱えるようになります。これにより、Prismaを使い続ける理由が強化されたんです。TypedSQLの登場は、Prismaの利用を続けるための大きなインパクトをもたらし、開発における可能性を広げてくれました。

次に、2つ目の記事です。タイトルは「SnowflakeのマイクロパーティションはSQLを進化させ続ける(ORDER BY×LIMITの場合)」です。

Snowflakeはマイクロパーティションというアーキテクチャを採用していて、その最適化されたメタデータによって、ACID制御やタイムトラベルといった機能を実現しています。最近ではAI Data Cloudが注目される中、SQLの性能向上に寄与するマイクロパーティションの重要性も見逃せません。

特にORDER BYとLIMITの組み合わせは一般的なユースケースですが、性能面での課題があります。Snowflakeは、Top-Kアルゴリズムを使ってこの課題を解決しているんです。この新機能によって、クエリの性能が124秒から3.3秒に短縮されるなど、劇的な改善が見られました。ユーザーは特別なクエリの書き換えを行うことなく、この最適化の恩恵を受けられるんですよ。

続いて、3つ目の記事です。タイトルは「【警告】AOAIのモデルをデプロイしただけで約5万円も課金された話」です。

この記事では、AOAI(Azure OpenAI Service)の利用に関する失敗経験を共有しています。デプロイ直後にAPIを使用していないのに約5万円も課金されてしまったというお話です。この高額な課金は、デフォルト設定が「Provisioned-Managed」だったために発生したものです。

これに対する対策としては、「Provisioned-Managed」の設定について社内で周知することが重要です。また、予算アラートを設定することで、特定の金額に達したときに通知を受けられるので、予期しない課金を防止する手段になります。この記事は他者と共有しても問題ないため、同様のインシデントを防ぐために広めることが推奨されています。

次に、4つ目の記事です。タイトルは「Webで縦書きの段組みレイアウトは意外と難しい」です。

この記事では、Web上で縦書きの段組みレイアウトを実現する難しさについて述べています。特に、長さが不定な文章を縦書きで読みやすく配置する方法を紹介しています。使用した技術環境はNext.jsとCSS Modulesで、縦書きと段組みの組み合わせに焦点を当てています。

縦書きのためにCSSの`writing-mode`を使用し、段組みを設定しましたが、コンテンツの高さがフッターに影響を与える問題が発生しました。最終的には、`position: absolute`を使い、フッターの位置を動的に調整できるようになりました。このように、縦書き段組みのレイアウトは一見簡単に思えるが、実際にはさまざまな要因に影響されるため、慎重に実装を進める必要があります。

さて、最後に5つ目の記事です。タイトルは「Reactにおいてpropsがイミュータブルである理由について改めて考えてみる」です。

Reactでは、コンポーネントに渡されるpropsはイミュータブルであることが推奨されています。これは、コンポーネントの純粋性を保つためであり、propsを書き換えることは副作用を生じさせる可能性があります。レンダー時に副作用を実行しない理由は、Reactが複数回コンポーネントをレンダーする可能性があり、これが期待しないバグを引き起こすからです。

Reactが純粋性を重視する理由は、パフォーマンス向上やバグの減少、メンテナンス性やテスト性の向上など、開発者にとって多くの利点があります。要するに、Reactにおいてpropsをイミュータブルに保つことは、予測可能で効率的なアプリケーション開発において極めて重要な要素です。

それでは、今日はここまで!今日ご紹介した記事を駆け足でおさらいすると、PrismaのTypedSQLやSnowflakeのマイクロパーティション、AOAIの課金問題、Webでの縦書きレイアウトの難しさ、そしてReactのpropsのイミュータブル性についてお話ししましたね。次回もお楽しみにしています!詳しい内容はショーノートに書いてありますので、ぜひご覧ください。そして、番組の感想もお待ちしています!では、またお会いしましょう!

Related episodes

内容の近いエピソードを推薦しています