9月/10月社内Tech勉強会レポート – NodeJS/Privacy Sandbox API/3rdPartyCookie/NodeJS/PromiseAll/cascae/

@1Day Office オフラインTech勉強会開催レポート

こんにちは。毎月社内Tech勉強会のレポートをブログにあげる予定でいる江口です。

今回は1Dayオフィスの開催日に合わせて、9月/10月まとめてのオフライン開催となりました。

早速毎月ではなくなりましたが、よろしくお願いします。

前回のレポートはこちらです。興味ある方はどうぞ。

(勉強会の様子です。映っていないですが、カメラの後ろに社員がたくさんいますよ)

Tech News

今回のNewsは「NodeJSでenvがbuildinサポート」と「Privacy Sandboxによる3rd party Cookie廃止とPrivacy Sandbox APIの紹介」についてとりあげました。

MardownViewerによる要約は例によってこちらとこちらにまとめております。

Node.js v20.6.0から.envがbuiltinサポート

Privacy Sandboxによる3rd party Cookie廃止とPrivacy Sandbox APIの紹介

詳しくは取り上げませんが、内容としては

  • いよいよ2024からChromeでも3rdPartyCookieが廃止される
  • 代替手段として、Privacy Sandbox API を紹介
    • Private State Tokens API
      • reCaptch(私はロボットではありませんのあれ。Botかどうかのチェック)の利用状況から信頼性を証明・認証するためのAPI
      • Chrome DevtoolからApplicationタブからトークンの確認ができる
    • Topics API
      • ユーザーの興味のあるトピックを提案するAPIChromeでは閲覧履歴から提してた(Cookieを利用)
    • Protected Audience API
      • サイト訪問者にリマーケティングをするためのAPI従来はCookieを使って閲覧履歴・行動履歴を追跡してたが、廃止されてこのAPIが使われる
    • First-Party-Sets
      • 別ドメイン間で限定的に3rdパーティCookieを許可するドメインをまたいでCookieを共有できるGithub上のjsonファイルを申請して共有できるようになる
    • Shared Storage API
      • ドメインが異なっていても共有できるStorage
    • Fenced Frame API
      • iframeみたいなやつ
      • Privacy Sandbox API を埋め込みコンテンツからも利用できるようにするもの

となります。

また、改めて3rdPartyCookieってなんぞや？という説明とlocalhostで実際に体験する方法についてざざっと紹介させていただきました。

> 実際に体験する方法

こちらにサンプルを置いてありますので、興味がある方はどうぞ

※3rdPartyCookieのセットには3rd側のCookieは SameSite=None; Secure; である必要があり、また、Secureがつくとhttpsでないと機能しません。 そのため、localhostでhttpsを実現するのにmkcertを使ってます。

TechShare

今回の自由枠は「大規模システムの大量レコード削除手順についてレビューして欲しい」というものでした。

詳しくはご紹介できないのが残念でなりませんが、具体的なレビュー対象処理としては

  • 大規模レコードのChunk Delete
    • レコードは事前に外部API経由で削除する必要あり
    • 外部APIで削除成功したレコードのみ、DBから削除
      • DBで更新の入ったレコードは外部データストアにもTriggerでデータ連携している

となります。

レビューして欲しいポイントとしては、

  • レビューポイント
    • 処理完了に数時間かかる想定でいるが改良できないか？
    • 特定のテーブルに紐づいている子テーブルの削除も必要だがうまい方法ないか？

となります。

このライブレビューは当日非常に盛り上がり、さまざまな質疑応答と処理改善の提案・意見があがってきました。

いくつか紹介できる範囲で共有します。

  • 外部APIを呼び出して削除する処理はNodeJSでasync/awaitで1件1件処理しているため時間がかかってる。PromiseAllでまとめて処理させた方が効率がいい
    • ただし、処理に失敗したレコードを特定できるように、処理失敗したIdをtmpなどにファイルで記録しておくなど、リトライ/バッチのリラン処理を可能にする必要がある
  • 親テーブルレコード削除時に、子テーブルを複数削除しているloop処理があるが、途中でエラーが発生するとリトライ/リランが難しくなるため、トランザクションさせて、すべての関連テーブルが削除した時にcommitする処理にした方が良い
    • 毎回commitせず、1000件commitなどある程度の塊でトランザクション貼った方が良さげ
  • 親テーブルにぶら下がる子テーブルはcascase deleteさせれば良いのでは？
    • Triggerで外部データストアにレコード連携させているため、cascadeではtriggerが発火しなくて厳しいかも

などなど。

一方的な意見の押し付けではなく、質疑応答で認識確認しつつ、改善案を出し合うというスタイルで進んでいました。

そのため、若手からしたら「そこまで考えないと危険なのか、今後参考にしよう」と思う方や、ベテランであっても「この手法は知らなかった。勉強になります」といった誰にとっても得るものが多いレビュー会になったのではないかと思いました。

なかなか「私のプログラムレビューしてください」って言える人は少ないかもですが、それを言いやすい会にできたらえーなと、主催者として改めて思いました。

今回は以上です。ありがとうございました。

僕/私もライブレビュー参加してみたい！という方は、ぜひアシアルとカジュアル面談から情報交換しましょう👋

ではまた、次回11月レポートをお楽しみください(?)