pkm.watasuke.net

ImGrate

11 min read

https://github.com/watasuke102/ImGrate

Image Gallery immediately rated by favorites or comments

  • その名の通り、お気に入りとコメントで即座に評価される画像ギャラリー
    • シンプルだからimmediateと付けたという建前にしている
      • 実情はサービス名の “Im” 部分に合わせただけ
  • ImaGe + Gallery + IMmediately + RATEdみたいなノリで命名
    • ChatGPTにどういう名前がいいか相談したけど、あんまり良いのが出てこなかったので自分で考えた

@Watasuke102: ちまちま作っていた画像の閲覧・評価サービスこと ImGrate 、完成に近づいてきた気がする
もうちょっと早く完成させられると思ったけど、そんなことはなかった
https://t.co/9ne50kODfs
imageimage

  • 身内に大量の画像を見てもらってコメントとかランキング付けをしてほしいと思う機会があったので開発
  • 類似サービスくらい探せばいくらでも見つかっただろうけど、フロントエンドのプロジェクトを立ち上げるチャンスを逃すわけにはいかなかった

技術選定

  • フロントエンド
    • Next.js
      • 話題のAppディレクトリやTurbopackを触ってみたかった
        • 前者はChakra UIが対応してなくて駄目だった
        • 後者は、最初Chakra UI導入前に導入したvanilla-extractとの兼ね合いで駄目だった気がする
          • つまり今やろうと思えば出来るのでは？
    • Chakra UI
      • 最近よく名前を聞く（気がする）コンポーネントライブラリ
      • そもそもコンポーネントライブラリというものを使ってみたかった
      • ロジック部分を特に書かないでもModalとかToastとかを使えてとても良かった
      • それはそれとして、デザインシステムの複雑さみたいなものや、コンポーネントライブラリのくせにHookまで用意している巨大さは本当に少し若干ちょっとだけ微妙に気になった
      • 次はヘッドレスなライブラリにしたい
    • Scaffdog
      • watasuke.netなど既存プロジェクトにおいて、絶対導入したほうが楽になるんだよなあ～～～と思いながらずっと導入を見送っていたScaffoldingを試したかった
      • 体感かなり良かったのでいつか入れる
    • CSSを書いていないせいか、フロントエンドはだいぶ軽いような印象がありますね
  • バックエンド
    • Golang
      • 「RustはWebバックエンドには重すぎる」という話をTwitterで聞いたことがある
        • もちろん実行速度的な重さではない
        • バックエンドを書く時に所有権を意識しなきゃいけないのはちょっとつらい、GCあり言語で書いたほうがコストが低くて良い、みたいな主張だったはず
          • セマンティクス？と言って良いのだろうか
      • Webバックエンドでモダンな言語といえばGolangかな～という偏見があった
      • Twitterでも全人類が書いているため、一度試してみたかった
      • よく揶揄されがちという印象があった if err != nil だらけ問題についてはさほど気にならなかった
      • 全体的に書きやすいという印象を受けたけど、気になる点もないわけではなかった
        • 特に forループ内で宣言した変数のアドレスをループ外にあるsliceにappendする という芸当がまかり通ってしまうことに恐怖を覚えてしまった
          • 調べたところ、Golangはヒープに確保するか否かをいい感じに決めてくれるらしく、それ故にこういうことが出来るらしい（たぶん）
          • 今までCやらRustやらしか触ってこなかった故の感想であって、別にGoが悪いわけではないと思うけど……
          • 僕の書き方が悪いだけかもしれない
    • GraphQL
      • いつか触ってみたいなあと思っていたもの
      • Gatsby.js（というよりwatasuke.net）で使っている時、「GraphQLってfilterとか使えて便利だなあ」と思っており、今回ユーザー名でfilterをかける等の使い方を考えていたので採用した
        • ちなみにこれは間違いで、Gatsbyが生やしてくれていただけだった
      • この「filterはGraphQLが勝手に実装してくれるもの」という勘違いを元に採用したものの、最終的にはこのプロジェクトには巨大すぎたなあと思った
        • 普通にREST APIで良かったと思います
      • ただし、Goのgqlgen・Node.jsのgraphql-codegenは非常に良かった
        • データ型を schema.graphql で管理し、それらを使ったquery / mutationを documents.graphql で管理
        • これらのライブラリを用いてコードを自動生成する
          • 特に後者は、面倒なAPI処理の諸々を省略できてかなり良かった
    • SQLite
      • ファイルひとつでデータベースを管理できるのが良さそうだとずっと思っていた
      • 一瞬だけNoSQLを触ってみたいかもという理由でMongoDBに手を伸ばしかけたけどやめた

感想

  • GolangとChakra UIに関してはかなり印象が良かったし、今後も書く必要があるなら喜んで書くけど、新しいプロジェクトを立ち上げる時に自ら率先して導入しようとは思わないかなというのが結論
  • ScaffdogとGraphQLはかなり良かった
  • TAGether ではバックエンドを薄くしすぎてしまったという後悔があり、それをある程度は活かすことが出来たのではないかと思っている
  • 今回も結局フェッチライブラリ（というよりSWR）に手を出せなかったのが少し心残り
    • SWRを使わなかったのは、別にミューテーションとか再検証とか使わないだろうし……と思ったのと、graphql-requestとの組み合わせ方がいまいち分からなかったから
      • 結局ミューテーションみたいなものを自前で実装したので、普通に採用しとけば良かった
    • 今度こそ採用したい
      • 今度っていつ……
  • ちなみに 開発を開始（initial commit）した日 はテスト一週間前
    • 当時は1日で終わるだろうと思っていた
      • こんなツイートもしている

        • @Watasuke102: テスト一週間を切ったらしいですね！今日はひとりハッカソンもどきを決行しようとおもいます

    • 結局終わらず、土日は全て開発に費やす事になった
      • GraphQL（というよりgqlgen）まわりで躓いてしまったのが原因だと思っている
    • おおよそこれのせいで、テスト本番においてそれほど難しくない積分を解くことが出来なかった
      • 教科書に類題があったはずだから、それをやっておけばよかったのに
      • そもそも前日にテスト範囲1周をちょうど終わらせるレベルで時間がなくてつらかった
  • しかもアイデア（？）を思いついてから開発を始めるまで数日しか空いておらず、設計や要件（そもそも何がしたくて何が欲しいのか）についてあまり考えることなく始めてしまったのは失敗だった
    • データベースの構造も幾度となく変更された
    • 設計はだいじだなあとあらためておもいました

Graph View