ダッシュボード内でAPI requestをテストする
ダッシュボードから直接、ライブ requestを作成して送信できるようになりました。API keyを1つ選択し、Single、Proxy、Browserを切り替え、URL、header、bodyを入力したら、Cmd+Enterを押して実行します。responseパネルには、ステータス、タイミング、サイズが表示されるほか、コピーやダウンロードが可能なbody、header、rawビューも用意されています。
FourA の最新のアップデートと改善情報
ダッシュボードから直接、ライブ requestを作成して送信できるようになりました。API keyを1つ選択し、Single、Proxy、Browserを切り替え、URL、header、bodyを入力したら、Cmd+Enterを押して実行します。responseパネルには、ステータス、タイミング、サイズが表示されるほか、コピーやダウンロードが可能なbody、header、rawビューも用意されています。
既存の全30件のブログ投稿に対して、独自の Open Graph カードをロールアウトしました。Discord、LinkedIn、Slack、または Twitter で共有されたリンクには、一般的な favicon の代わりに、すっきりとしたブランドデザインのプレビューが表示されるようになりました。新しい投稿のカードは自動的に生成され、長いタイトルを単語の途中で切るのではなく、適切に折り返すテキストフィッティング機能が適用されます。
ブログ記事に埋め込まれたスクリーンショットや図が、ライト/ダークの切り替えに合わせて切り替わるようになりました。明るいページで暗い画像が不自然に目立ったり、暗いページで淡いスクリーンショットが背景に溶け込んで見えなくなったりすることはもうありません。
ブログの「Older」ボタンは、以前はページ1に戻るようになっていました。現在、ページネーションは番号付きナビゲーションとともに /blog/page/N/ の URL に配置され、古い投稿を実際に閲覧できるようになりました。Vladimir Petrov氏に感謝します。
ブラウザはすべてのリクエストをJavaScriptエンジン経由で実行するようになりました。これにより、CloudflareのチャレンジやJSを多用するページが期待どおりにレンダリングされます。
製品チップフィルター(Single、Proxy、Browser)が、Overview だけでなく Metrics と Activity でも機能するようになりました。いずれかのページで製品を選択すると、その選択が3つのページすべてに適用されます。1点だけ注意点として、同時実行数はまだ製品ごとに分類されていないため、製品フィルターが有効な間は Metrics の Concurrency スコープが無効になります。
サードパーティのウェブサイトを対象とする明示的な許容される利用条項を追加し、管轄権のセクションをより明確にしました(EU消費者向けの例外規定を維持した上で、ソフィアの裁判所を管轄とします)。大規模に当社をご利用いただいている場合は、今一度内容をご確認ください。
ホームページ上のダッシュボードプレビューが、小さな画面で窮屈に表示されていました。タイポグラフィとスペーシングを修正し、タッチ操作で実際に機能するツールチップを追加しました(ホバー専用のヒントはスマートフォンでは役に立たないためです)。
2026年に向けた明確なスタンスのもと、robots.txtを更新しました。検索エンジンやソーシャルプレビューアー(Facebook、LinkedIn、Twitter、Slack、Discordなど)のアクセスは明示的に歓迎します。一方、AI学習用のクローラーは許可していません。
Twitter、Slack、LinkedIn、またはDiscordでFourAのリンクを共有すると、以前は1つの共通カードにフォールバックされていました。現在は、すべての公開ページに、適切なタイトルとチップが表示された独自のプレビュー画像が用意されています。細かいディテールですが、誰かが共有するたびに必ず表示される部分です。
/jobs ページを公開し、2つの職種で募集を開始しました。 SaaSを繋ぎ合わせるのではなく、本物のシステムを構築することに興味がある方は、ぜひご覧ください。 私たちはすべてのレイヤーを自社で開発し、継続的にデリバリーを行い、OSSを第一級の存在として扱っています。
無効なexitは再試行されずピッカーから排除されるため、持続的な負荷の下でもresponse時間が維持されます。当社の負荷テストでは、p95は500ms未満に収まっています。
スマートピッカー、ラウンド2。以前は、新しい proxy を検出するたびに working pool が肥大化し、低速な proxy がローテーションに紛れ込んでいました。現在はこれらをオンザフライで除外するため、実行時間が10分であろうと10時間であろうと、response タイムは一定に保たれます。
proxyの選択は、従来はランダムでした。現在は、Proxy Finderが送信先ごとにどのproxyのパフォーマンスが良かったかを記憶し、それらを優先的に選択します。全体像を把握するため、初期のrequestでは依然としていくつかのサンプルを収集します。その後は、同じターゲットに繰り返しアクセスする際、response timeが安定し、slow tailの発生が減少するはずです。
ロールアウトのプロセスを改善しました。Single、Proxy Finder、またはBrowserの新しいバージョンをリリースする際、ロードバランサーは各新規インスタンスが実際に準備完了状態になるのを待ってから、トラフィックをルーティングします。リリース時間帯に発生していた可能性のある一時的な瞬断は解消されました。