アクセス数が増えても、API 使用回数は増えません
kula は kintone のレコード情報をもとに記事を作成しますが、ウェブサイトにユーザーが訪問する度に紐づけた kintone にアクセスしているわけではありません。
サイトの訪問者が閲覧するのは、kintone のデータをもとに予め生成された静的な HTML であり、この HTML を定期的に更新することで、記事の最新化を行っています。
この更新のタイミングで、紐づけた kintone にアクセスし、最新の情報を使って記事が再生成されます。
つまり、API 使用回数に影響するのは kula へのアクセス数ではなく、この更新頻度が影響するということになります。
再生成される間隔の最短は以下の通りです。
| ページ | 更新間隔 |
|---|---|
| 記事ページ | 1 時間 |
| 記事一覧ページ | 4 時間 |
| ユーザーページ | 8 時間 |
例えば、記事ページの作成後 1 時間の間に 1000 回アクセスがあったとしても、記事ページが更新されることはありません。kula から kintone へリクエストを送信する回数は 1 回のみです。
1 時間以降に初めてアクセスのあったタイミングでページが更新され、さらにそれ以降 1 時間は更新されません。
ページそのものが存在しない場合(アプリを初めて登録した場合)は最初に対象ページを表示したタイミングで記事の生成が実行されるため、新規作成時に限り API 使用回数が増える可能性があります。
また、キャッシュを保持する時間が異なるため、紐づけたアプリに新規でレコードを作成した場合、記事ページは作成直後から閲覧できますが、記事一覧ページは最大で 4 時間後に反映されることになります。
例外
ただこの仕様では、コンテンツ制作者が更新内容をすぐに確認することができません。
そのため、記事の著者とアクセスしているユーザーのアカウントが一致した場合に限り、即座に最新の情報を反映するようにしています。(正確には静的な HTML の提供 ➡ アカウントの照合 ➡ 最新化であるため、最初に表示される情報から最新の情報に置き換わるまで、少しタイムラグがあります。更新自体はリロード無しで自動的に実施されます。)
kula を利用していて最も頻繁に kintone とやり取りのあるのはこのケースである可能性が高いため、API の使用回数が上限に近づいた場合は、一度 kula からログアウトした上で操作していただくことで、API 利用回数を抑えることができます。
記事ページの生成以外に kintone にアクセスするケース
kula で生成した記事は検索エンジンにインデックスすることを前提としています。
そのため、記事の生成とは別に、kula のサイトマップや RSS フィードを生成するタイミングで、ご利用の kintone からデータを取得する場合があります。
こちらもキャッシュを利用しており、最短でも 1 日に 1 回更新するようになっています。
膨大な数のレコード数を持つアプリであったり、膨大なアプリ数を kula に登録するようなことがなければ、API 使用回数上限に達してしまうことはないかと思います。
今後の予定について
お気づきの方もいらっしゃるかもしれませんか、更新を検知する最適な手段は Webhook です。
実装予定の機能や、仕様上の都合としてキャッシュと再生成という仕組みを取っていますが、何日も更新されていない記事に対して、更新されていないか能動的に確認を繰り返すことは効率が良いとは言えません。
キャッシュと再生成の仕組みを止める予定はありませんが、可能であればそこに Webhook を取り入れ、よりリクエスト回数を最適化できるよう検討したいと思っています。