HeySushi

基本情報¶

• 構成
  monorepo構成（１つのリポジトリに２つのプロジェクトが入っているようなイメージです）
  apps/
  ┝ bot（slack側の処理　slackAPIを叩いたりしてます）
  └ web（webサイト側）
  
  またbot、webともに共通で使用するDBに関するものはpackages配下に全て置いています
  packages/
  └ database
  　 └ prisma
  
  monorepo構成のため主要な各ディレクトリ配下にpackage.jsonが配置されています
  ルートディレクトリ配下には全体で使用するもの、各ディレクトリ配下ではそれぞれで使用するものを配置しています

• 使用言語など
  • bot
    Node.js , Bolt , TypeScript
  • web
    Node.js , Next.js , React , TypeScript, Tailwind CSS , Prisma , shadcn , jollyui
  • database
    開発：postgresql , 本番：supabase
  • 画像登録
    開発：minIO , 本番：GCP（cloud storage）
  • デプロイ
    GCP（cloud run）
    
    botはそのままTypeScriptで実装を行なっています
    webはDBのやり取りはprisma（ORM）を使っていて将来的にDBを変更しても大丈夫なようにしています
    デプロイはGCPのcloud runにあげていますがmonorepo構成の場合は１つのサービスにまとめてデプロイすることが不可能なようで
    ２つのサービスを使ってbot用、web用としてデプロイして動かしています（そのためDockerfileがbotとwebで２つ作成しています）
    cloud runへの反映の仕方ですがgithub actionを使っています
    github actionを定義しているのが
    ./github
    └ workflows
    　 └ cloud-run-deployment.yml
    のファイルに処理が書かれています
    なのでmainにコードがマージされたタイミングでgithub actionが起動し自動デプロイされるようになっています
    githubのActionsタブで処理の経過が見れますのでそこでデプロイ完了しているか見てみてください
    もし、Actionsのworkflowがエラーで赤いばってんがついちゃうと何かしらどこかで落ちているのでエラーが吐かれていればいいですが大体意味わからんエラーだったり
    全く違う部分をエラー文言として出してきたりなので根気強くやるしかないです
    大体はデプロイに関わっているDockerfileかdocker-composeか上記に書いているcloud-run-deployment.ymlかgithubに設定している変数かそこらへんなので
    その部分で修正した部分などを中心に見ていけばいけると思います、

• その他
  細かい連携について記載しておきます

  • ブランチ
    mainとdevelopブランチを作っています
    mainにマージされるたびにビルドが走るのでdevelopに修正完了したものを溜めてある程度で一括でmainにPRでマージしてました（1人の時はdevelopにあげて溜めずにそのままmainにマージしてました）
  • envファイル
    ルートディレクトリ、web配下、database配下にそれぞれ配置されてますのでそれぞれで使用する環境変数を定義してください
  • ユーザーログイン
    ログインにAuth.jsのバージョン5だったかな？ベータ版を使っていますAuth.jsのバージョンによってwebのサーバーコンポーネント、クライアントコンポーネントで使用できる関数が変わっていますのでご注意ください
  • slack認証
    webサイトのログインにはslack認証でログインさせています（slackの情報が必要なため）
  • app-router
    webサイトではNext.jsのapp-routerを採用しています（今まではpage-routerと言われるもの）
    実際のディレクトリ構成がパスになる構成です
  • Next.js
    当該プロジェクトではサーバーアクション（server acrion）を使用してバックエンドを実装しています
    よくあるのがAPIを作成して画面から叩くというようなことをするのですがNext.jsがバックエンドの領域もわずかなら担ってくれるイメージです
    なのでaction.tsを作成してそこに関数を作成して各画面で呼び出すというやり方をしています
  • TanStack Query
    全てをサーバーアクションでするのにも色々とメリットデメリットがあります（サーバーコンポーネントならいいのですがクライアントコンポーネントでアクションを呼び出すのが面倒だったり２回呼び出されてしまうなど）
    そこでクライアントコンポーネントで利用できるTanStack Queryを使用しています（旧React Queryと言われていたものです）
    TanStack Queryは何となくのイメージで行くならsessionのような感じでキーバリューでデータ保持をしてくれて保持しているデータをとったり処理を実行してデータを取ることもできたりなどです
  • デザイン
    UIはshadcn/uiとjollyuiを組み合わせて作っています
    storybookも一応作成しています
    なのでボタンや色々な部品は自分で作成するというよりimportして配置するということをしてそこからカスタマイズが必要な場合はtailwindCSSでclass定義してって感じでデザインしています
    どの部品がどのUIを使っているのかは apps/web/components/ui 配下に部品のファイルが入っていますのでそこで見ていただければと思います
    大体、jollyuiはreact-aria-componentを元に作られているUIコンポーネントで shadcn/uiはradix-uiを用いて作られているコンポーネントです
    shadcn/ui：https://ui.shadcn.com/
    jollyui：https://www.jollyui.dev/
    storybookの起動の仕方は以下のコマンドを叩くと自動でブラウザが起動します（※storybookの起動をwebのNext.jsだったかな？Node.jsだったか忘れました、を使って起動させているのでstorybook起動しながらwebのlocalhost:3000を開くことはできないです）

  // ディレクトリはapps/webに移動しておく
  pnpm run storybook
  

  • メール
    本番においては「お問い合わせ」からメールを送れるのですが
    本番の環境変数を設定していないので（問い合わせメールを受け付けるメールアドレスのパスワードが必要で個人のアドレスを記載するとパスワードバレるため）
    どこに問い合わせメールを送るか決定しその環境変数を設定して本番に反映してから動かしてください
    ローカル環境にてlolipop（a.okada@apptime.co.jp）にメールが来ることは岡田が確認済み

• 参考記事など
  実際に実装を行なっていく中でサーバーコンポーネントとクライアントコンポーネントを使い分けていくと思います
  レンダリングのタイミングが違うのでなるべくサーバーコンポーネントでデータは取得してそれをクライアントコンポーネントなどで展開するとか多いと思います
  クライアントコンポーネントでデータを取得しようとするとuseStateなどを使うと２回、３回と同じクエリが流れたりします
  なのでサーバーコンポーネントで取得して、クライアントにPropsで渡すということになると思いますが
  Propsで渡すときにセキュリティに気をつけないとまるまる情報が見えてしまいます、
  なるべくPropsには個人情報は渡さず見えても特に大丈夫な情報などにするようにします
  https://zenn.dev/moozaru/articles/d270bbc476758e
  
  Reactの歴史からNext.jsのApp routerに至った経緯
  https://speakerdeck.com/nkzn/the-spas-chronicle-reaches-to-remix