その他 #1497: 【基本情報】構成等について - HeySushi - SYS開発事業部 - AppTime株式会社

その他 #1497

## 基本情報 
 - **構成** 
 monorepo構成（１つのリポジトリに２つのプロジェクトが入っているようなイメージです） 
 apps/ 
  ┝    bot（slack側の処理　slackAPIを叩いたりしてます） 
  └    web（webサイト側）<br /> 
 またbot、webともに共通で使用するDBに関するものはpackages配下に全て置いています 
 packages/ 
  └    database 
  　    └    prisma<br /> 
 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）<br /> 
 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 
     ``` 

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

戻る

プロジェクト

全般

プロフィール

HeySushi

その他 #1497