Skip to main content

· 2 min read
Shimba, Koji

ActivityEdge.nodeSeriesWorkEdge.node というフィールド (以下 .node と表記します) があるんですが、実装を間違っていたようで、すでに存在するフィールドを上書きするようなことをしてしまっていました。

それが原因でGraphQL APIの実装で使用している graphql というライブラリの アップデートが難しい状態になっているため、これらを非推奨とし、代わりに ActivityEdge.itemSeriesWorkEdge.item というフィールド (以下 .item と表記します) を用意しました。 これらは現状の .node と同じ値を返すようにしています。

もし .node を使用している場合は、単純に .item に書き換えるだけで問題ないはずです。

.node は1ヶ月後の11月5日以降に上書きをしていないときの値を返すようにします。 もしこれらのフィールドを使っている場合は、お手数ですがそれまでに書き換えをお願いします。

GraphQL APIのスキーマを整理したいAnnictをよろしくお願いします。

· 2 min read
Shimba, Koji

古くなったものなどを更新しました。

セットアップドキュメントで使用しているGraphQLクライアントをInsomniaにしました

今までセットアップドキュメントでは GraphiQL.appというクライアントを使ってAPIの使い方を紹介していましたが、 あまり更新されていないようなので、今もアクティブに開発されているInsomniaを使うようにしました。 個人的にもInsomniaを使ってAPIの開発をしています。

リファレンスの見た目を更新しました

今までGraphQLDocsというツールを使ってGraphQL APIリファレンスを公開してきました。

しかし最近このツールのメンテナンスが終了したようなので、GraphQL-Markdownという別のツールを使って公開することにしました。

リファレンスのトップページのURLは変わらず https://developers.annict.com/docs/graphql-api/beta/reference/ ですが、内部のURLはちょっと変わってしまっています。ご了承ください。

ツールの入れ替えにより継続性を維持しようとするAnnictをよろしくお願いします。

· 9 min read
Shimba, Koji

今朝メンテナンスを行い、annict.comapi.annict.com が動いているサーバに手を入れました。 主な目的は以前フォーラムに書いたお知らせにあるサーバ費の節約でしたが、結果的にサイトのパフォーマンスが上がった気がします。 せっかくなので記念として今回何をしたのかを記録しておこうと思います。

AWSのアカウントとS3バケットを整理しました

Annictに表示されている画像などはAmazon S3にアップロードされています。 このS3バケットはAnnictを公開したときくらいからずっと使っているもので、 Annict関係のS3バケット以外にも雑多なものがこのAWSアカウント配下で管理されており、散らかっていました。

そのため今回の対応でAWS Organizationsを使ってAnnictの本番/ステージング環境ごとにAWSアカウントを新たに作り、その中に新たなS3バケットやIAMポリシーなどを作るようにしました。 また、S3バケットなどはTerraformを使って作るようにしました。

Annictに関してはTerraform化されたAWSアカウントの中にあるものだけで動くようになりましたが、散らかったAWSアカウントにはまだ色々残っているので、少しずつきれいにしていこうと思います。

imgixからimgproxyに移行しました

imgixはめちゃくちゃ便利で仕事でも使わせてもらっているんですが、個人で使うには料金が高いという問題がありました。 なので今回からimgproxyというOSSな画像変換サーバを使うことにしました。 雰囲気で使えるくらい作り込まれていてとても良いです。

Cloudflareを導入しました

今朝のメンテナンスの前にしれっと導入しました

上に書いたimgproxyはimgixと違いCDNとしての機能は無いので、Cloudflareを経由して配信するようにしました。

あとDNSレコードをPointDNSで管理していたんですが、それをやめてCloudflareに用意されているDNSサービスを利用するようにしました。 別のドメインも管理しているのでまだPointDNSは使い続けていますが、整理を続けたら費用が浮きそうです。

Railsを6.1から7.0にアップデートしました

費用削減とは特に関係ないですが、Railsのバージョンを上げました。 まだ上げただけの状態なので、7から使える便利機能をこれから使ってみたいです。 Relation#load_async が気になってます。

webpackからPropshaftに移行しました

PropshaftはRails 7から使えるものなので、バージョンを上げただけでもありませんでした。

jsbundling-railscssbundling-railsを使ってJSやCSSをビルドするようにしました。 ビルド処理が速くなってとても良いです。

PostgreSQLを11から14にアップデートしました

全然アップデートしていなかったんですが、このタイミングでジャンプしました。 サイトのパフォーマンスの向上に結構な影響を与えてくれている気がします。(たぶん)

HerokuからVultr + Dokkuに移行しました

間違いなくパフォーマンスに良い影響を与えてくれたのはこれだと思います。(たぶん)

東京のサーバで動くようになったので、Herokuのレイテンシ問題が解消しました。 そして今回の対応の目的であるサーバ費用の削減にも繋がりました。

今朝のメンテナンス後の時点ではLinodeのVPSを借りて動かしていたんですが、 メールサーバのポートが閉じられていることに気づき、 サポートに問い合わせても反応が薄かったので、途中でVultrのVPSに切り替えました。 ステージング環境では特に何もしなくてもメールが送れていたので油断していました…。

Dokkuが便利

Herokuのデプロイ環境はとても良く、そんなぬるま湯に浸かりすぎていたので、VPSで今からCapistranoとかを使って頑張るのはちょっとな…と思い、 VPSなどの中でHerokuっぽいことをできるようにしてくれるDokkuを使い始めました。 これがめちゃくちゃ良くできています。この記事で一番伝えたいことはこれかもしれません。

アプリを作り、アドオン的なポジションであるサービスを作ってアプリと連携させるということができるようになっていて、構成がVPSの中でHerokuっぽくなります。 PostgreSQLとかRedisとかはサービスとして作られ、アプリと連携することになります。 データベースのバックアップをS3のバケットにシュッと送れるようになっていたり、 Vectorを使ってログを外部に転送しやすくしてくれていたりなど、 運用のときにやりたいことを手厚くカバーしてくれています。

特に良かったのがHerokuishです。 Herokuが提供してくれているBuildpacksはデプロイするときに良い感じのことをしてくれて便利なんですが、 Herokuishを使うことでHerokuで使っているBuildpacksを使うことができます。 AnnictはHerokuで動かしているとき以下のBuildpacksを使っていたんですが、Vultr + Dokkuに移行してからも使い続けています。 なのでRailsを動かすために自分でDockerfileを書いたりはしていません。

おかげで移行が楽にできて良かったです。

開発者の方も開発だけでなくGitHub IssuesSlack上での利用者からの質問などに素早く対応されていてすごいです。

Thank you Dokku!

ということで今回の諸々の対応により無事いくらかサーバ費用が削減できたので、浮いたお金でDokkuのスポンサーになりました。 Dokkuの開発を長く続けるための一助になれば良いなと思います。

コストが下がってパフォーマンスが上がったAnnictをよろしくお願いします。

· 2 min read
Shimba, Koji

ライブラリページや「記録する」ページに表示されているようなデータを取得することができるようになりました。

以下のクエリは、2021年秋アニメの中で自分が 見てる見たい にしている、

  • 作品情報
  • 視聴ステータス
  • 次の未視聴エピソード
  • 次の未視聴エピソードに紐付く放送予定
  • メモ

を取得します。

query {
viewer {
libraryEntries(
states: [WATCHING, WANNA_WATCH],
seasons: ["2021-autumn"]
) {
nodes {
work {
title
}
status {
state
}
nextEpisode {
number
}
nextProgram {
channel {
name
}
startedAt
}
note
}
}
}
}

このクエリを実行すると以下のようなレスポンスが返ってきます。

{
"data": {
"viewer": {
"libraryEntries": {
"nodes": [
{
"work": {
"title": "無職転生 ~異世界行ったら本気だす~ 第2部"
},
"status": {
"state": "WATCHING"
},
"nextEpisode": {
"number": 12
},
"nextProgram": {
"channel": {
"name": "TOKYO MX"
},
"startedAt": "2021-10-03T15:00:00Z"
},
"note": "おもしろい"
}
]
}
}
}
}

APIの詳細はGraphQL APIリファレンスをご参照ください。

ライブラリの情報が取得しやすくなったAnnictをよろしくお願いします。

· 2 min read
Shimba, Koji

久しぶりの更新です。

今まで docs.annict.com という主にREST APIについて書かれたドキュメントページと、 developers.annict.jp という主にGraphQL APIについて書かれたドキュメントページが二つ存在して微妙だったので、 developers.annict.com というドメインでAnnict Developersを作り直し、REST APIとGraphQL APIのドキュメントを集約するようにしました。

今のところ内容はほぼ変わっていないですが、REST APIのドキュメントはページ構成をエンドポイントベースではなくリソースベースに変えています。 docs.annict.com のサイドバーのリンクがめちゃくちゃになっていたので、それを整理した形になります。 (ホスティングしていたサービスのアップデートによりめちゃくちゃになり、そのまま放置してしまっていた…)

なお旧ページは新しいAnnict Developersにリダイレクトされるようにしています。

ちなみにAnnict Developersを最初に公開したときはVuePressを使って作っていたのですが、 初期バージョンを使ったまま放置しちゃっていたのと、最近はVueよりReactを使うことが多くなったので、 Docusaurus で作り直しています。

ソースコードは github.com/kiraka/annict-developers で公開しているので、 変なところなどがありましたらPull Requestを送って頂けるとありがたいです。

生まれ変わったAnnict Developersをよろしくお願いします。

· 2 min read
Shimba, Koji

Workオブジェクトに seriesList というシリーズ情報が取得できるフィールドを追加しました。以下のようなクエリで作品に紐づくシリーズ情報が取得できます。

{
viewer {
works(state: WATCHED, first: 5, orderBy: {field: SEASON, direction: DESC}) {
nodes {
title
seriesList {
edges {
node {
name
works(orderBy: { field: SEASON, direction: DESC }) {
edges {
summary
node {
title
seasonYear
seasonName
}
}
}
}
}
}
}
}
}
}
{
"data": {
"viewer": {
"works": {
"nodes": [
{
"title": "劇場版 幼女戦記",
"seriesList": {
"edges": [
{
"node": {
"name": "幼女戦記",
"works": {
"edges": [
{
"summary": "劇場版",
"node": {
"title": "劇場版 幼女戦記",
"seasonYear": 2019,
"seasonName": "WINTER"
}
},
{
"summary": "TVシリーズ",
"node": {
"title": "幼女戦記",
"seasonYear": 2017,
"seasonName": "WINTER"
}
}
]
}
}
}
]
}
},
...

GraphQL APIの詳細はリファレンスからご参照ください。

じわじわとAPIから取得できるデータが増えているAnnictをよろしくお願いします。

· One min read
Shimba, Koji

なぜ今まで取得できなかったという感じですが、作品情報を取得するときに「しょぼいカレンダー」のタイトルID (TID) を返すようにしました。REST APIでは syobocal_tid で、GraphQL APIでは syobocalTid というプロパティ名で取得できます。

REST APIの詳細はAnnict Docsを、GraphQL APIの詳細はリファレンスからご参照ください。

しょぼいカレンダーと連携しやすくなった気がするAnnictをよろしくお願いします。

· One min read
Shimba, Koji

Annict APIに下記データが取得できるエンドポイントを追加しました。

  1. 人物 (Person)
  2. 団体 (Organization)
  3. シリーズ (Series)
  4. キャラクター (Character)
  5. キャスト (Cast)
  6. スタッフ (Staff)

REST APIとGraphQL APIどちらからもデータが取得できるようになっています。 REST APIの詳細はAnnict Docsを、GraphQL APIの詳細はGraphQL APIリファレンスからご参照ください。

色んなデータが取得できるようになったAnnictをよろしくお願いします。

· 2 min read
Shimba, Koji

Annict Developersというサイトを公開しました。主なコンテンツはGraphQL APIのドキュメントとこのブログになります。

今までは GitBook を使用して Annict Docs というドキュメントサイトを公開していました。 REST APIのドキュメントだけを公開していたときは良かったのですが、GraphQL APIのドキュメントを追加したときサイドバーの構成が中々見づらくなりました。また、GraphQL APIのリファレンスを手動で更新するという厳しい管理体制でした。

Annict DevelopersでもGraphQL APIリファレンスを公開していますが、今回から graphql-docs を使用してソースコードから自動生成するようにしました。まだフィールドの説明文が無かったりするので、これから少しずつ更新していきたいと思います。GraphQL APIのドキュメントをここで公開し始めたので、Annict DocsからはGraphQL APIのドキュメントを削除しています。

また、Annict Developersの公開に伴い開発者向けのTwitterアカウントも用意しました。 今後開発者向けの情報は↓のTwitterアカウントやこのブログでお知らせしようかと思います。

twitter.com/AnnictDevJP

Annict Developersは VuePress で作成しています。ソースコードは github.com/annict/developers-jp で公開しているので、ドキュメントなどに不備等あったときはプルリクエストを頂けるとありがたいです。

開発者向けの情報が取得しやすくなったような気がするAnnictをよろしくお願いします。