Zennの技術まわりの質問があれば答えるよ

スクラップについてまだ周知していない段階で見つけていただきありがとうございますw
（どうやって気づかれたのか気になります）

通知はけっこう苦労した部分です。仰る通りオブジェクトの種類（Article, Book, Comment, User）が多いんですよね。

Zennの場合、notificationというテーブルがあって、通知が必要になったタイミングでnotifiable_typeとnotifiable_idに通知に関連するアイテムの情報を入れています。合わせて通知の種類と、通知先のuser_idなども保存しています。

例えば「あなたの記事にコメントがつきました」と通知したい場合、こんなイメージでレコードが追加されます。

notifiable_type: "Article"
notifiable_id: コメントがついた記事のID
user_id: 通知先のユーザーID
action: "commented" # コメントがついたという意味で
notified_from_user_id: 通知元のユーザーID（nullのこともある）

メール通知については、15分おきとかにバッチ処理でread:false（既読済みかどうかのフラグ）となっているものを（ユーザーの通知設定がONになっている項目のみ）一括で送るようにしています。

現状こんな感じですが、もっと良い方法はあるような気がしてます。

永続化の際はイベント駆動などで何かしら非同期的な機構が走っているのかと予想しますが、実際に使われているシステムやアーキテクチャなども参考にしたいです

バックエンドにはRails（on App Engine） + PostgreSQL（on CloudSQL）を使っています。Railsだと非同期処理についてはSidekiq（+ Redis）を使うのが一般的だと思うのですが、サービスのリリース直前までApp EngineではなくCloudRunにデプロイしていた関係で、Sidekiqなどにより非同期処理は使っていません。

関連
https://stackoverflow.com/questions/60297681/rails-jobs-with-sidekiq-in-google-cloud-run-not-working/60303701#60303701

現時点では通知なども同期的に永続化しており、負荷の大きいタスクは定期的なバッチ処理で対応していたりします（タスク用のApp Engineインスタンスを作っています）

ただ、既に限界は感じているので、このあたりは今後着手しようと思っています。

勝手に使わせていただきすみませんw
catnoseさんのユーザーページのコメントタブでたまたま発見して、新機能のようだったので少し興奮してしまいました笑

なるほど！テーブル設計までありがとうございます、参考になります。バッチ処理と同期処理を使い分けられてるんですね。

ついでに思い出したので、もう一つだけ。Like判定に特化したAPIが用意されているようで最初ほうっと思ったのですが、この辺りはISRとユーザー認証をうまく共存させる工夫でしょうか? UGC型のサービスでISRを活用するための一つの指針となりそうな解決法ですね。

なるほど！ミスってしばらくコメント一覧に出ちゃってたんですよねw

まさにその通りです。ごく一部を除いて認証が絡む部分はクライアントでマウントされてからリクエストしています。「Incremental Static Regeneration」のようにガッツリとページをキャッシュする場合、そのあたりが少し面倒になりますね…。

一応他の手段として、キャッシュするデータに「LikeしたユーザーのID一覧」を含めて、クライアント側でログインユーザーのIDと一致するか検証する方法も検討したのですが、その場合Likeした直後にページをリロードするとLikeしていないことになってしまうという問題があり、このようにしています。

Local Storageなどを使えばクリアできる問題とは思いますが、あまり複雑にしたくなかったので現状こんな感じにしています。同じ構成のサービスがどうしているのか気になるところです。

なるほど〜面白いですね。シンプルで良さげな方法だなと思いました。まだISRを活用したサービスって少なそうなので今後ベストプラクティス的なものが確立されていくのか楽しみですね。

色々とご教授ありがとうございました！サービス共に末長く活用させていただきます。

Webアプリ（zenn.dev）の方はバックエンドを中心にテストを書いています。カバレッジは測っていませんが、主要な部分はだいたいカバーできているんじゃないかと思います。

すみません、zenn-editorではまったくテストを書いてません。書きたいと思っていたのですが、色々と急いでいたので…。そして書こうと思っているのですがまだ着手できていません。

純粋に自分が初心者なので社会人の方々のそういった環境が気になる

これは社会人として参考にするべき例ではないです。個人開発だからこんな感じですが、本来最初から書くべきだと思います。
（もうすぐ個人開発じゃなくなりそうなのでちゃんと書く予定です。はい）

可能なら暇な時間にテストを書いてプルリクエストを投げたい

ありがたいお話ではあるのですが、あくまでもzenn-editorはzenn.dev依存のものなので申し訳ないです。もっと幅広く使われているOSSへ貢献した方が実績/勉強になると思います。
時間が出来たらテストは書く予定です。すみません、はい。

（「時間は作るもの」ですよね。すみません、はい。）

お忙しい中すみません、ご返事いただきありがとうございます
catnoseさんがほぼ一人でやっていらっしゃるとの事ですので、より優先順位の高いサービスの重要なところから実装していくのは当然の事だと思います。急かすみたいな形になってしまいすみません。

ありがたいお話ではあるのですが、あくまでもzenn-editorはzenn.dev依存のものなので申し訳ないです。もっと幅広く使われているOSSへ貢献した方が実績/勉強になると思います。

純粋に自分が普段使わせていただいているもの/見ているものに対しまずは貢献/勉強したいなと思っていました、ただそれこそお忙しいでしょうし個人のプルリクエストに時間を割いていただくのも申し訳ないのと他の部分に時間を割くべきというのがありますよね、ごめんなさい。

いえ、プルリクについてはありがたさしかないです！ただあまり時間を取っていただいちゃうと、手数料を取っている商用サービスなのに対価をお支払いできずすみません…ってなりますw

後から見た人のために追記）zenn-editorもテストちゃんと書き始めました

検索は現在はバックエンド(Rails)のRansackと呼ばれるもので行っています。できることが限られているのでそのうちAlgoriaかElasticsearchに置き換えたいと思ってます。

関連記事についてはタグを見ています。

PostgreSQLを選んだ理由は開発当初Herokuにデプロイすることが選択肢にあったからです。

お忙しい中、ありがとうございます！
Algoriaはよく聞きますが、やはり色々やれることが多いんですね...。
PostgreSQLにつきましてもご回答ありがとうございます。
いつも本当に参考にさせて頂いております。

getServerSideProps使おうと思っていたのですが、色々比較してみたところgetInitialPropsの方がページ遷移時の体験が良かったので現状ではgetInitialPropsを使っています。
（エラーハンドリングはどちらも同じようになると思います）

イメージ的には以下のようなことをやっています（色々抜粋）。

type Props = {
  posts: Post[];
  errorCode?: number;
}

function Page(props: Props) {

  if(props.errorCode) return <Error status={props.errorCode} />; // エラー用のコンポーネント

  return <div>色々</div>
}

Page.getInitialProps = async (ctx) => {
  try {
     const { posts } = await requestSomething();
     return {
        posts,
     }
  } catch(err) {
     const errorCode = err.response?.status || 500;
     return {
        errorCode
     }
  }  
}

export default Page;

ここでは省いていますが、エラーコード周りの型はTypeScriptのユニオン型で「あるかもしれない」プロパティを表現するときのTipsのような形で表現しています。

やっぱそうですよね。cDCはランタイムだけで起きた予期しないエラーにより画面が真っ白になるために置いておくが、基本的にstatusCode的なのをreturnしてコンポーネント側でnext/errorを返すみたいな実装ですよね...

ありがとうございます！少し自信が持てました！

nextjs とnextjs の api route を利用する形なら next-auth が便利そう

同意です。小規模のアプリであればこの形が良さそうだと思っています。
blitzを使ったりするとそのあたりも気軽にできたりするのかも…？（まだ触っていないので分からないですが）

僕なら今小規模なサービスを作るならDBはFirestoreやMongoDB Atlasとかにして、認証はFirebase Authenticationに任せてしまう気がします。

ZennのRails APIは2020年12月時点ではdeviseというgemを使ってcookieによるセッション認証を行っています。セキュリティのためにcookieはhttp-onlyにしたりとごく一般的な実装です。

ただ現在NestJSへのリプレイスを検討しています。その場合はpassportという定番ライブラリを使うことになりそうです。

認証・認可の仕方については上記のコメントの通りです。
セキュリティという観点で大まかなにやっていることは

• 通信はhttpsに限定する
• cookieはhttp-onlyにする
• CSRF対策のためcookieはSameSite=Laxにする

などですね。

もちろんCORSの設定もしています。

なるほどー
ありがとうございます。

react-svg-loaderを使っています。使い方はごく普通で以下のような感じですね。

import SvgPencil from '@assets/svg/pencil.svg';

<SvgPencil width={50} height={50} class={styles.editIcon} />

とても助かりました！
お忙しい中、ありがとうございます！

遅くなりすみません。記事ページはISRです。著者本人によるアクセスの場合にはクライアントでのマウント後に再フェッチしています。

なるほどです...!!
お忙しいところありがとうございます。勉強になります。

エディターライブラリを色々見た結果、react-simple-editorを使うことにしました。その中でCodemirrorが使われているわけなので、僕がこだわって選んだわけではありません。とはいえCodemirrorはAPIが豊富で個人的に気に入っています。

認証系のSaasを使わなかった理由はサーバーサイドで十分使いやすいライブラリがあったからです。あとAuth0はわりとお金かかりますよね。

なるほどですー！
Auth0はユーザー多いとかなり高くなりますよね。。
ご回答ありがとうございます！とても参考になりました!

良い質問ですね…。その部分は試行錯誤したところで、最終的には_app.tsxから読み込むLayout的なものを作って実現しています。そのうち記事にします。

お返事いただきありがとうございます！

_app.tsxで実現されていたんですね。記事楽しみにしています！

（自分の文見直したら「再レンダリング」と書いていましたが「再マウント」でした 😞 意図が伝わっていてよかったです）

分かりづらくてすみません。

まず、できれば全部英語にしたいという思いがあります。その方がきれいに見えるので。ただ、ユーザーさんが何の操作なのか分からない可能性があるなと感じた部分は（本当はあまりしたくないのですが）日本語にしています。

ちなみにリリースから少しずつ英語を日本語に書き換えていっています。最初はパッと見たときにカッコいい方が目を引いてユーザーが集まりやすい気がしますが、だんだんと見慣れてパッと見のカッコよさより分かりやすさの方が重要になるんじゃないか、という考えです。

なるほど！！ありがとうございます。分かりづらいとかでは全くなくて、自分もプロダクト作るときに表記に迷うところでもあり、zenn ではどうしてるのかな〜ってふわっと思っただけです！！お時間いただきありがとうございました！！

1の答え、Twitterで教えてもらいました、、
Zennも同じかと思います
https://twitter.com/konojunya/status/1356784611276197889?s=21

1はこのツイートのとおりです！

• utm とかのクエリパラメータが色々つくケースがあるので統一したい
• 明示的に防がない場合 PaaS などが提供する http://web.app や http://vercel.app みたいなドメインも一応あるので重複扱いにならないようにしておきたい

2は多分ミスです。見落としてました…。ありがとうございます。

1. Proプランを使っています。
2. 他サービスへの移行は予定していません。やはりNext.jsの色々な機能を使う際の検証コストが小さくて楽なので…。ただ危機感は持っていて、いざというときは移行する心の準備はできています。
3. そこなんですよね。アクセスが増えてもEnterpriseの規模ではないので1TBに納める必要があります。現時点ではまだ余裕がありますが、増えないように気をつけています。たとえば以下の部分ですね

• next/imageは使っていない。使うことになってもCloudinaryを通す予定
• API Routesを使えば楽な部分でもCloud Functionsを使うようにしている

あとはアレですね。Proプランで収まらなくなったときにはクラスメソッド社の力を使えば（交渉などで）何とかなるかもしれない…というわずかな希望も持ってます笑

回答ありがとうございます！

1. Proだとかなりコスパいいと感じますね。Password Protectionが割高ですが。
2. 同感です。例えば今後も React Sercer Components + Vercel + Next.js などの相性などを考えると、なるべくVercelを活用したいと考えています。
3. Enterprise Planについて問い合わせをVercelサポートにしているのですがかなり割高と感じました。なるべくPro Planに抑えたいと考えていたので助かりました。next/imageやAPI RoutesはやはりBandwidthを大きく消費するのでこの観点だとなるべく避けたいですよね。

Proプランで収まらなくなったときにはクラスメソッド社の力を使えば何とかなるかもしれない…

Enterprise Planの国内事例を殆どしらないので楽しみにしてます！

2019年の夏頃に開発をはじめました。フルタイムで開発して2020年の1月頃に一旦完成したのですが、そのあたりで第一子が生まれたのでリリースを見送りました。

その後は育児をしながらゆるーーく開発して2021年の9月にリリースした感じです。
（ゆるーく開発してる頃にNuxt.jsからNext.jsへの移行や、GitHub連携機能などをつけました）

ご回答していただきありがとうございます。素晴らしいの一言です👏👏👏 こんな素敵なサービスを世の中に生み出してくださり感謝です。

ありがとうございます！

一応試したような気がしますが、ほとんど検討しなかったですね…。今思うと悪くない選択肢かも？

ただ、コンポーネントのjsx部分が膨らむのは気になりますね。そこも分割出来るのかもですが。うーん、もう少しちゃんと検討するべきでしたw

うおお!早速回答ありがとうございます!!感謝です。

そうだったのですね。

ただ、コンポーネントのjsx部分が膨らむのは気になりますね。そこも分割出来るのかもですが。

実は外出しも出来るようで、その問題は解消できるかもです。
https://github.com/vercel/styled-jsx#external-styles

ReactはCSS周りの選択肢多くて迷いますね〜。。
catnoseさんの記事も参考に色々検討したいと思います。

コンテンツ用のCSSやMarkdownパーサーはnpmにpublishすることで共有するようにしています。運用面ではnpm publishした直後に本番環境のAPIにデプロイするようにしています。

zenn-cliについてはいずれにせよユーザーさんがパッケージをアップデートするまで反映されないため、完全に整合性を取ることは諦めて、大きな変更があるときのみTwitterで周知することにしています。

よく分かりました。ありがとうございます。

※ 略語に馴染みがない方のために括弧で正式名称を書いておきます。

利用規約やプライバシーポリシー、AboutページなどはSSG（Static Site Generation）を使用しています。使い分けとしては

• ダッシュボードなどのログインユーザーのみ閲覧ができるページ => CSR（Client Side Rendering）
• SEO上重要かつページネーションが必要な一覧ページ => SSR（Server Side Rendering）
• スクラップのように更新頻度が高いページ => SSR
• 記事や本などの速度が重要なページ => ISR（Incremental Static Regeneration）

という感じです。

回答ありがとうございます！！

次いでリプライ失礼します

1. 現在はどのようなページ構成になっていますか？

Next.jsアプリをVercelからGoogle Cloudに移行した話

キャッシュを廃止した記述
なお、記事や本の詳細ページなどでは、キャッシュの設定を誤ったときのリスクの大きさからキャッシュ自体を廃止することにしました。（ソースコードの見通しが良くなった！）

少し前の記事ですが、zennではISRを廃止し、stale-while-revalidate（SWR）などを使って代替的に実装していくと書かれていて現在のページの構成を教えていただきたいです！
ちなみに、個人開発で有料ブログサービスを開発中なので特にBooksの構成が気になります！

2. 有料Booksを非購入者では閲覧できなくする工夫を教えてください

有料ページを下手にISRなどでデータ取得してしまうと非購入者でもdevtoolで内容を見ることができてしまうなどの問題があり、zennの有料Booksではどのように購入者,非購入者を判断し、表示を分けているのか教えていただけるとありがたいです！

現状では手数料などの関係から「Paymentsのみで、売上を運営が管理し、決済から振り込みまで実行」としています。

※ ちょっとした支払い・入金管理システムを独自で構築しています。

ご回答ありがとうございます！！
参考にさせていただきます！

はい、RESTな感じのAPIにしています。考え方的にはWeb API: The Good Partsにできるだけ則ろうとしている感じです。

途中でRestfulとパフォーマンスの両立が難しくなってきたのでGraphQLも検討したのですが、導入のハードルの高さで躓きました…。

そうなんですね。ありがとうございます！

Zennのアイコン画像の登録は、基本的に「ユーザーが申請して管理者が承認する」仕組みになっています。

例：Reactのアイコンの変更申請ページ

申請が送られると、topic_change_proposalのようなテーブルにレコードが挿入されます。その中にCloudStorage上の画像のファイル名が格納されています。

申請を承認するとtopic_change_proposalの画像ファイル名の値を、topicテーブルの画像ファイル名のフィールドにコピーします。そんな感じで最新の画像のパスをtopicテーブルにもたせています。

Zennのアイコン画像の登録は、基本的に「ユーザーが申請して管理者が承認する」仕組みになっています。

なるほどーー!ありがとうございます!!
申請性だったとは知らなかったです。この仕組みは良いですね
早速いくつか申請してみようと思います!

ですです！今はスマホからは申請できないので気づきにくいかもですね。
ありがとうございます！！

ロードバランサを自分で入れたりはしていないですね。GAEのオートスケール設定を使っています。
一定の条件を超えると自動でインスタンスが増えるようになっています。

具体的にはapp.yamlのAutomatic scalingのあたりで設定をしています。

なるほど、オートスケールだけで結構捌けるんですね。
ありがとうございます！

そういえば、時々表示に時間がかかる時が、インスタンスが増えてる時って感じでしょか？

今はリアルタイムで（フロントエンド側が依存している）AWSの障害が起きているので表示に時間がかかりますね…

あと2020年12月頃にオートスケール時のレイテンシと料金対策のためにStandard環境からFlexible環境へと移行しました。

https://zenn.dev/catnose99/articles/f99ea2a8b985b2

昨夜全体的に遅いなーと思ってたのは障害だったんですね。
普段の表示は早いですものね。失礼しました。

Standard環境からFlexible環境へと移行記事、読ませていただきます。
ありがとうございます！

はい、仰る通りです。不都合というのは「ユーザーページを/[username]にすることで発生する不都合」という理解で合っていますでしょうか？（この理解で回答させていただきます）

開発者側からするとユーザーページを/users/[username]ではなく/[username]にすることで面倒な問題が色々と発生しています。新しいページを追加するときには予約語をチェックしないといけないですし、ルーティングもやや面倒です。

とはいえ、ユーザーページのURLをできる限り簡潔にしたい、各ページのURLも推測しやすいものにしたいという考えからこのようにしています。（記事一覧は/[username]/articlesで、記事自体は/[username]/articles/[slug]など）

という感じの回答になりますが、質問の主旨にお答えできていますかね…？

回答ありがとうございます。（分かりづらくてすみません、意図通りの回答になってます）

面倒な問題が色々と発生しています。

やっぱりそうですよね。

ユーザーページのURLをできる限り簡潔にしたい、各ページのURLも推測しやすいものにしたい

とてもよく分かります。
面倒な問題が発生してでもこちらを優先したとのことで参考になりました。
このへんはどうしてもトレードオフになってしまうんですね。

合っています。GCPのAppEngine、AWS Lambda、Vercel自体のいずれかで障害が起きると影響を受けます。

了解しました。ありがとうございます。

tocbotというnpmパッケージを使っています。

headingタグから目次を自動生成してくれる + 現在見ている部分の目次に対して指定したクラス名を付与してくれます（activeLinkClass ）。そのクラスに対してfont-weight: 700とか指定するだけで太字にできます。

早々にご回答ありがとうございます。
npmパッケージの使い方についても、解説ありがとうございます。

横から質問失礼致します。tocbotかなり便利ですね。１つ質問なのですが、zenn ではスクロールした時に目次のstickyの方も正しくスクロールされていますがデフォルトの tocbot では sticky のスクロールはされないかと思います。こちらはどのような形で実現されているのでしょうか？

あまり詳しくは書けないのですが、銀行のオンライン振込を独自のJSを使って効率化しているような感じです（あまり参考になる回答ではなくすみません）

答えづらい質問をすみません。
どうもありがとうございます！

マークダウン時点の文字数を単純に割ることで計算しています。

ありがとうございます。

ユーザーごとのRSSフィードについては、負荷の都合により24時間CDNにキャッシュするような仕様にしておりました。そのため最大1日前のRSSフィードが表示されてしまっていたのだと思われます。ご指摘を受けてこの時間は長すぎると考えたため、さきほどこのキャッシュの時間を6時間に変更しました。

記事の更新後、しばらくは古いRSSが表示されてしまうことがありますが、ご理解いただけますと幸いです。

おぉ、仕様だったのですね。
もっと簡単に対応できるものを想定していました。
他の人が気にしてなさそうな事だったのにお金の掛かりそうな対応して頂いて申し訳ありません。

返信がとても遅くなってすみません！（見落としてました）
Zennではあらかじめ一部の単語をユーザー名として取得できないようにして、ご指摘の問題を回避しています。「reserved usernames」とかでググるといい感じのリストが見つかって楽だったりします。

昔作ったリストがあるので良かったお使いください😌
https://github.com/shouldbee/reserved-usernames

👏👏👏

僕はフロントエンドもバックエンドも両方書くので一つのリポジトリにまとめて管理しています。チームが大きくなって、メンバーの役割分担が明確になったときはリポジトリを分けるべきかなーと考えていますが、今のところは予定なしです。

ちなみにテストやデプロイが非効率にならないように、フロントエンドのファイルだけが更新されたときはバックエンドのCI/CDはスキップされるように設定しています。

ありがとうございます！
チームの規模なども考慮必要ですよね、、
参考にさせていただきます！

ユニーク制約をかけているため、slugが重複する場合はレコードを作成できないようになっています。

回答ありがとうございます!

返信が遅くなりすみません。
これはサービスのビジネスロジックの所在をバックエンド（Rails）に統一するためです。Zennではバッチ処理や非同期処理なども多く実行されており、これらを全てNext.jsのAPI Routesで行うのは（できなくはないと思いますが）非効率な部分が多く出てくると考えています。
また「記事詳細ページだけはgetServerSidePropsでDBから直接取得する」ということもできなくはないと思いますが、RailsとNext.jsのそれぞれで「どのように記事を取得するか」や「どのように公開可能な記事だとみなすか」というロジックを持たせることになりメンテナンスが難しくなります。

とはいえこのツイートのように、今1から小〜中規模なWebサービスを作るのであればPrismaを使ってgetServerSidePropsなどから直接DBに接続するような方法を取る気がします。

シンプルにこのあたりの組み込み関数を使っています。

https://apidock.com/ruby/SecureRandom/hex/class

idのように、既存のユニークなものを変換しているのかなと思ったのですが、単純にランダムな値を生成（その後、既存のslugと被っていないかチェック？）して、生成しているのですね。スッキリしました。ありがとうございます。