「このコンテストがなかったら、あのコンテストに参加していなければ」
AtCoder tarareba は、過去を改竄してレートを最大化するサービスです。
（注意） 興味ドリブンで技術選定しています。そのため、アーキテクチャが冗長に感じる可能性があります。
- Go（サーバーサイド全般）（主要アルゴリズム）
- gqlgen（Go で GraphQL を書くためのフレームワーク。サーバーサイドと GraphQL をつなぐ）参考
- grpc-go 参考
- React （フロントエンドのフレームワーク。AtCoder Problems もこれ） 参考
- Appolo Client（GraphQL を React につなぐためのフレームワーク）参考
atcoder-tarareba は、マイクロサービスアーキテクチャを採用しています。
現在、二つのマイクロサービスが存在します。
tarareba-algorithms：レート最大化や、レート計算を請け負うtarareba-competition-history：コンテスト情報やパフォーマンスを取得する
tarareba-bff は、これら二つのマイクロサービスから情報を取得し、フロントエンドに提供する役割を果たす GraphQL サーバーです。（BFF とは、Backend for Frontend の略です）
tarareba-frontend は、TypeScript（React）で記述されたフロントエンドサーバーです。Apollo Client というフレームワークを用いて、上記の GraphQL サーバーと接続しています。
処理の全体の流れは以下の通りです。
競技プログラミングに例えると、インタラクティブ問題です。インタラクティブ問題を解いているつもりで考えてください。
上の図と合わせてみると、理解しやすいと思います。
tarareba-frontendは、ユーザーからuser_id（AtCoder ID）を入力として受け取り、tarareba-bffにリクエストを投げる。tarareba-bffは、tarareba-frontednからリクエストを受け取り、tarareba-competition-historyにリクエストを投げる。コンテスト情報を頂戴！！tarareba-competition-historyは、ユーザーのコンテスト情報を渡す。（https://atcoder.jp/users/monkukui/history っぽいやつ）tarareba-bffは、tarareba-competition-historyからコンテスト情報を受け取り、パフォーマンス列をtarareba-algorithmsに渡す。レートを最大化してくれ！tarareba-algorithmsは、レートを最大化するアルゴリズムを走らせる。DP かもしれないし、貪欲法かもしれない。tarareba-bffは、tarareba-algorithmsから復元つきのレート最大化情報を受け取り、よしなに形式をまとめて、tarareba-frontendに渡す。tarareba-frontendは、tarareba-bffからレスポンスを受け取り、WEB ページに表示させる。
マイクロサービスアーキテクチャの特徴として、
- 責務がそれぞれ独立しているので、開発・テストが閉じた状態でできる
- 変化に対応しやすい。アルゴリズムを変更したければ、
tarareba-algorithmsだけを修正すればよい
などが挙げられます。
もし、tarareba-algorithms と tarareba-competition-history を独立に処理できるなら、
並行処理（concurrent）ができます。今回は、
tarareba-competition-history からコンテスト情報を取得し、それを tarareba-algorithms に渡す必要があるので、並行処理ができません。
（そもそも、独立じゃないのにマイクロサービスにして分離しているのは、破綻している気がしてきました。）