タグ

asyncとapiに関するslay-tのブックマーク (9)

  • JSの非同期処理を理解するために必要だった知識と学習ロードマップ

    はじめに JavaScript の非同期処理を学習してみて「ある程度自信を持って理解できたと言える」状態に到達したので、その感想とまとめの学習ロードマップとその中でどのような知識が必要になるかを紹介したいと思います。 あるいは、自分が実際に学習してきた道筋に基づいているのでショートカットとして参考にしてもらったり、使えるリソースなどの情報が共有できると思います。もしくは「JavaScript 初心者が非同期処理を理解できるようになるまでの道筋」というストーリーで1つのサンプルとして見ていただけるといいかもしれません。 ChangeLog 大きな変更のみをトラッキングしています。 2022-11-16 の内容を反映させた追記・修正を追加 2022-05-21 構成を修正 「V8 エンジンから考える」の項目を追加 2022-04-30 「イベントループの共通性質」の項目を追加 「ロードマップ

    JSの非同期処理を理解するために必要だった知識と学習ロードマップ
  • jest における MSW の活用事例

    MSW を使った jest のテストについて、引数などの検査が面倒という記事を拝見したので、もし同様にアプローチを模索されている方がいらっしゃれば参考に、と思い記事にしました。筆者は普段以下の様に、server.use内にjest.fnを仕込みテストしています。例えば API が2回呼ばれたことを検証する場合、次の様になります。 const server = setupMockServer(...handlers); describe("API call の検証", () => { const mockFn = jest.fn(); beforeEach(() => { server.use( rest.get("/path/to/api", async (req, res, ctx) => { mockFn(); // <- here return res(ctx.json({}));

    jest における MSW の活用事例
  • Promise のキャンセルについて - Qiita

    [ English version ] JavaScript と Node.js についてのこの徹底した投稿では、Promises のキャンセルの歴史、なぜNode.jsに関係があるのか、そして async/await APIで使おうとしたときに注意すべきことについて学ぶことができます。 この投稿は、JavaScript の Promise API をよく理解していて、 Node.js の経験がある方のためのものです。 歴史 2014 年に Promise API がブラウザに導入されて以来、人々は Promise で他に何ができるかを調べていました。ブラウザに最初に登場した関連APIは、HTTP リクエストのための fetch() でした。 HTTP リクエストの問題は、サーバーのリソースを消費することであり、サーバーに送信されるリクエストの数が多い場合はお金がかかります。このため、特に

    Promise のキャンセルについて - Qiita
  • ソケットAPIが遅すぎる?新たなio_uringを試す!

    新しいAPIが作られるたびに、私たちは、古いAPIを置き換えるだけで高速化という夢をみます。何度夢破れても、高速なAPIが追加されたと聞けば、試さずにはいられませんよね! 今回は、Linuxカーネル5.1で追加されたio_uringを使って、Rustのasyncランタイムを実装し、gRPCサーバのベンチマークを実行してみました。 io_uringとはio_uringは、ファイルシステムとネットワークの非同期I/Oのために開発されました。同期よりも非同期のほうがおしゃれ、そういう雰囲気ありますよね!クラウドネイティブも、非同期にAPIを介して、なんかやってるやつですよね。 io_uringのインターフェイスは、高い性能を目指し、1)アプリケーションとカーネル間でのメモリコピーを避ける、2)複数のI/O要求を一度にカーネルに伝えることができる、という工夫がされています。 下図のように、アプリケ

    ソケットAPIが遅すぎる?新たなio_uringを試す!
  • Async Clipboard APIでJavaScriptからクリップボードを操作する

    JavaScriptからのクリップボードの操作は、長いあいだ開発者たちに切望されていました。かつてはFlashを使って実現するハックなどがありましたが、各ブラウザがexecCommandによるクリップボード操作を実装したことで、現在は落ち着きつつあります。 ただ、APIが綺麗に整備されているとは言いにくく、あまり現代的ではありません。そこで、スマートかつ現代的にクリップボードを扱うことができる、Async Clipboard APIの実装が進みつつあります。 Async Clipboard APIはその名の通り非同期でクリップボードを扱うAPIです。Async Clipboard APIはPromiseを返すので、直感的に扱えるようになっています。 従来のAPIでも、execCommandを用いることによってクリップボードを操作することができました。しかし、バグが多くブラウザ間の整合性が取

    Async Clipboard APIでJavaScriptからクリップボードを操作する
  • Async Clipboard API

    Safari 13.1 adds support for the async Clipboard API. This API allows you, as web developers, to write and read data to and from the system clipboard, and offers several advantages over the current state of the art for reading and writing clipboard data via DataTransfer. Let’s take a look at how this new API works. The API The Clipboard API introduces two new objects: Clipboard, which is accessibl

  • JavaScriptでデッドロックを作ってみた

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? いきなりですが、皆さんは排他制御をご存知でしょうか。排他制御は並列コンピューティングにおける概念であり、複数のプロセスが資源を共有して使用する際に、複数のプロセスが同時に資源を使用している状況(競合)が発生しないように制御する手法です。(この分野にはあまり詳しくないのでまさかり等は歓迎します)。 排他制御の一手法としてロックが知られています。この手法では、ある資源を使用するためにはまずその資源のロックを取得する必要があります。そして、資源を使い終わったらロックを解放します。あるプロセスがロックを取得している間は、別のプロセスは同じロック

    JavaScriptでデッドロックを作ってみた
  • Nuxt.jsでポートフォリオサイトを作製する - Qiita

    フロントエンドについての学習のため、Nuxt.jsでポートフォリオサイトを作製してみました。 fmatzy.github.io GitHub Pagesで (お金をかけずに) ホスティングしつつ、多少動的なこともしてみました。Vue.js、Nuxt.jsについてほぼ知識のないところから作製したのでかなり荒削りです。 fmatzy/fmatzy.github.io-dev 工夫した点は以下の通りです。 GitHubのリポジトリとQiitaの投稿をそれぞれAPIで取得して表示した。 トップページはMarkdown形式で書くようにした。 Nuxt.jsで静的なページを生成してGitHub Pagesでホスティングした。 GitHubのリポジトリとQiitaの投稿をそれぞれAPIで取得 せっかくSPAのフレームワークを使用するので、なにかのAPIを叩いて動的にコンテンツを生成することにしました。

    Nuxt.jsでポートフォリオサイトを作製する - Qiita
  • ngx_mruby v2のHTTPクライアントをv1よりも最大90倍高速にした - 人間とウェブの未来

    写真のような感じでRubyKaigi2018で登壇し、RubyKaigiを経て、ようやくngx_mrubyのv2をリリースしました。基的にv1と互換性がありますので、今後はv2を開発していくことになります。 github.com ngx_mruby v2の目玉機能としては、Rubyスクリプトからノンブロッキングのsleepとhttp[s]クライアントを使えるようになったことです。実装的には、nginxのsub requestという機能をうまく使って、ノンブロッキングのhttp[s]クライアントを汎用的なsub_requestメソッドとして実現しています。 では、エントリではそのノンブロッキングhttpクライアントがどの程度高速処理可能になったかを実験してみましょう。また最後には、RubyKaigi2018の感想も述べます。 実験 proxyサーバのblockingとnon-blocki

    ngx_mruby v2のHTTPクライアントをv1よりも最大90倍高速にした - 人間とウェブの未来
  • 1