すべてのカテゴリ

はじめにNext.jsとSupabaseの認証機能を連携させる際、特に行レベルセキュリティ（RLS）を活用する場合、APIルートの使用は技術的な制約によって推奨されません。本記事では、Supabase SSRライブラリを使用した正しい実装方法について、サーバーコンポーネントでのSupabaseクライアントの使用方法に焦点を当てて解説します。Supabase SSRライブラリの概要2023年後半に導入された「supabase/ssr」は、Next.jsのApp Routerとの統合を強化した新しいパッケージです。従来の認証ヘルパーライブラリに代わるものとして、より一貫性のある認証体験を提供します。このパッケージは、サーバーコンポーネント用のクライアント生成関数、クライアントコンポーネント用の関数、そしてミドルウェア用のセッション更新機能を提供しています。サーバーコンポーネントでのクライアント初期化の重要性サーバーコンポーネントでSupabaseクライアントを初期化する際は、Next.jsのクッキーAPIを活用して認証情報にアクセスすることが重要です。サーバーコンポーネント用のクライアント生成関数には、クッキーの読み取りと設定のための機能を含める必要があります。この設定により、クライアントは認証情報を含むクッキーを読み取り、認証済みリクエストを送信できるようになります。また、認証情報の更新時にはクッキーを適切に設定することも可能になります。サーバーコンポーネントでの認証とデータアクセスサーバーコンポーネントでSupabaseを使用する際の基本的な流れは以下の通りです：① サーバー用

はじめにホテルの支配人を13年やった後、フリーランスエンジニアに転身し、今は JINZAI（ホスピタリティ特化の人材マッチングプラットフォーム）を一人で開発している。スタックは Next.js 14 / TypeScript / Supabase / Vercel。正直に言うと、マッチングサービスを作るのがこんなに大変だとは思っていなかった。この記事では、実際に手を動かして痛感した「3つの現実」を書く。同じように一人でマッチングサイトを作ろうとしているエンジニア、またはSaaSを0から立ち上げようとしている人の参考になれば。現実① マッチングサイトのDB設計は「関係者が多すぎる」問題が必ず起きる最初に設計した時、テーブルの数をなめていた。ECサイトなら users / products / orders の3本柱でだいたい話が成立する。でもマッチングサイトは違う。登場人物が多い。JINZAIの場合、主要なテーブルだけでこうなった：profiles // 共通ユーザー情報workers // 求職者プロフィールclients // 採用企業プロフィールjobs // 求人票applications // 応募messages // メッセージnotifications // 通知earnings // 収益・報酬管理documents // 提出書類（在留カード、資格証明など）verifications // 書類審査ステータスそして設計の難所は「誰が誰の何を見ていいか」という権

Supabaseは何がどこまで出来る？Webアプリやサービスを作るとき、「バックエンドをどうするか」は必ずぶつかる壁です。サーバー構築、データベース設計、認証、API設計……フロントエンドだけでなく、裏側の仕組みも整えなければなりません。そのときによく名前が挙がるのが Supabase です。では、Supabaseは実際に「どこまで」できるのでしょうか。1. できること① データベース管理Supabaseは、PostgreSQLをベースにしたクラウド型データベースです。できることテーブル作成リレーション設定SQL実行インデックス設定Row Level Security（行単位のアクセス制御）単なる「保存箱」ではありません。本格的なRDBと同じレベルの設計が可能です。つまり、予約システム投稿アプリ会員管理システム学習進捗管理こういった実務レベルのアプリを支える構造を作れます。2. できること② 認証機能（Auth）ログイン機能はアプリの基本です。Supabaseでは以下が標準で用意されています。メールアドレス認証パスワード認証OAuth（Googleなど）パスワードリセットセッション管理さらに、ユーザーごとにアクセス権限を制御することも可能です。自分でJWTやセッション管理をゼロから実装する必要はありません。3. できること③ APIの自動生成Supabaseは、作成したテーブルに対して自動的にREST APIを生成します。つまり、データの取得追加更新削除が即座に可能です。フロントエンド（Reactなど）からそのまま呼び出せます。APIサーバーを別途構築しなくても、基本的なCRU

初めまして。kanehara32です私自身、アプリ開発を受託・個人・準委任で行なっており、数多くのアプリを携わりフルスタックエンジニアとして活動しております。クラウド技術やSupabase/Vercel等を使用して運用コスト実装コストの削減が実現できるシステム開発を行なっています。AWS認定やGoogleCloudの認定、受賞歴もあったりと経験豊富なのでお客様と繋がれる機会がないかと思い、ブログを書いております。■システムの運用費、本当にその金額が適正ですか？「毎月のシステム費用が重い...」「でも、これが相場なのかな...」そんな風に思いながら、高額な運用費を払い続けていませんか？私がこれまでお手伝いしてきた企業様の多くが、実は必要以上のコストを払っていました。特に5年以上前に作られたシステムをお使いの場合、最新技術への移行で大幅なコスト削減が期待できます。今回は、私が実際に手がけている「Next.js + Supabase」という組み合わせが、なぜコスト削減に効果的なのかをご説明します。■従来型システムと最新技術の費用比較▼一般的な中規模システムの運用費（月額）《従来型（オンプレミス/レガシーシステム）》・データベースサーバー：15-30万円・アプリケーションサーバー：10-20万円・バックアップ・冗長化：5-10万円・セキュリティ・監視：5-10万円・保守・運用人件費：20-50万円合計：55-120万円/月（年間660-1440万円）《Next.js + Supabaseの場合》・Supabase（DB/認証/API）：0.5-5万円・Vercel（ホスティング）：0.

初めまして。kanehara32です。私自身、アプリ開発を受託・個人・準委任で行なっており、数多くのアプリを携わりフルスタックエンジニアとして活動しております。クラウド技術やSupabase/Vercel等を使用して運用コスト実装コストの削減が実現できるシステム開発を行なっています。AWS認定やGoogleCloudの認定、受賞歴もあったりと経験豊富なのでお客様と繋がれる機会がないかと思い、ブログを書いております。■「システムの運用費、高すぎませんか？」先日、ある企業の社長さんから相談を受けました。「月10万円もサーバー代払ってるけど、これって普通なの？」「開発会社に聞いたら『これが相場です』って言われたけど...」結論から言うと、その会社のシステムは月1万円で運用できるものでした。なぜこんなことが起きるのか。そして、どうすれば適正なコストで運用できるのか。今日は、私が実際に手がけた「コスト削減しながら性能アップ」の事例をご紹介します。■なぜ多くの企業が無駄なコストを払っているのか▼理由1：「昔ながらの技術」を使い続けている10年前の技術で作られたシステムは、10年前の料金体系のまま。でも技術は劇的に進化しています。《実例：ECサイトの場合》旧システム：・専用サーバー：月8万円・保守費用：月5万円・合計：月13万円新システム（Next.js + Vercel）：・運用費：月2万円（すべて込み）・性能：3倍高速・世界中から快適にアクセス可能▼理由2：「とりあえず大きめに」の罠「将来を見越して余裕を持って」この考えが、毎月の無駄な出費につながっています。最新技術なら、必要に応じて自