非同期処理に疲れた方に、ReactQueryの処方箋
この記事について 本記事は、下記のReactQuery公式ドキュメントの内容をベースに、自分なりに噛み砕いてまとめたものになります。 ReactQuery公式ドキュメント サンプルコードの一部は公式サイトから引用しています。 前置き 【呼称について】 ReactQueryはSolidやVue、Svelteへの対応を進めており、現在の正式な名称はTanStackQueryになっています。 ReactQueryの方が耳馴染みのある方も多いため、この記事では、ReactQueryと呼ぶことにします。 【内部実装のイメージについて】 以下、「内部実装のイメージ」となっているアコーディオンの箇所は、ReactQueryの内部実装が実際にそうなっているということではなく、 「こういうふうなコードをイメージすると理解しやすそう」という意図で書いています。 基本的には読み飛ばしていただいても大丈夫な箇所で
Golang GenericsでREST APIを作る - Nature Engineering Blog
Go 1.18が出てしばらく経ちました。みなさんGenerics使っていますか？ @maaashです。 これは Nature Engineering Blog祭 の2日目の記事です。 祭り 最初は歓喜し、mapやfilter的なfor文を少しずつgithub.com/samber/loに切り替えたり、 internalなsliceパッケージを作ってみたり。 ですが心のどこかで欲求不満が蓄積されていくのを感じていました。 使い尽くしていないのでその真価が理解できていなくて物足りないような、 こんなに面白いおもちゃが与えられたのに遊び尽くしていないような感覚です。 Genericsを使ったコードを書きたい！と思いながら日々の業務でREST APIを書いていると、、 あれ、これはかの When To Use Genericsの結論にある: If you find yourself writing
Storybook First な開発のススメ
Storybook first な開発とは Storybook での呼び出され方を意識しながらアプリケーションコードを書くことをそのように呼んでいます。 道具に設計がひきづられるのはアンチパターンと言われそうな気もするのですが、コンポーネントのカタログを整備していくことは、コンポーネントが良い感じに再利用可能な形で分離できるということでもあり、やっていくとむしろ正道に近づいていくと思います。 Storybook First のコンポーネント設計や型定義をすると、パーツに限らず Storybook でカバーできる範囲が広がり、ページそのもののサンドボックスを作れます。 そして API がない状態でもデータを使って開発ができたり、特定のスナップショットの再現やタイムトラベルに近いことも可能になるというメリットがあります。 つまり、ただのコンポーネントカタログとしてではなく、開発のためのサンドボ
Contexts and structs - The Go Programming Language
Jean de Klerk, Matt T. Proud 24 February 2021 Introduction In many Go APIs, especially modern ones, the first argument to functions and methods is often context.Context. Context provides a means of transmitting deadlines, caller cancellations, and other request-scoped values across API boundaries and between processes. It is often used when a library interacts — directly or transitively — with rem
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 リクエストの問題は、サーバーのリソースを消費することであり、サーバーに送信されるリクエストの数が多い場合はお金がかかります。このため、特に
SWR vs React Query - fsubal
（※ この記事は API およびそこから導かれる設計のしやすさ観点での比較をしています。実際にキャッシュが有効に効いたか、などについてはまた別の機会に ）
Next.js + esa.io + VercelでJAMStackな爆速ブログを構築する - パンダのプログラミングブログ
追記: 本記事がesa.ioの公式Twitterに取り上げられました！ esaに書いた記事をNext.jsで公開する Next.jsのバージョン9.3から、ビルド時に外部ソースからデータを取得するgetStaticPropsというAPIが公開されました。 ブログは静的なコンテンツです。ブログの内容はユーザーに応じて動的に変わるということはありません。そして、getStaticPropsは静的なページを構築するために最適なAPIです。 そこで、esaにmarkdownで書いた記事をNext.jsで表示するサイトを構築しました。 実際にサイトにアクセスして記事を開いてみてください。爆速で遷移するのが体験できます。Lighthouseの成績もバツグンです。（blog-starterをベースに利用したため、コンテンツはそのレポジトリの内容を踏襲しています） デモサイトのコードはGitHubにアップ
Integrate with the OS sharing UI with the Web Share API | Articles | web.dev
Integrate with the OS sharing UI with the Web Share API Stay organized with collections Save and categorize content based on your preferences. Web apps can use the same system-provided share capabilities as platform-specific apps. With the Web Share API, web apps are able to use the same system-provided share capabilities as platform-specific apps. The Web Share API makes it possible for web apps
Slack Events APIの再送仕様と回避方法まとめ(Serverless on AWS) | DevelopersIO
SlackのEvents API(Event Subscription)で盛大にドハマりしてしまったので、Events APIの再送の仕様をまとめて、本来のベストプラクティスに沿った実装と妥当な落とし所をご紹介します。 どうも、もこ@札幌オフィスです。 最近Slackを利用したBotの開発をする機会がありまして、SlackのEvents API(Event Subscription)で盛大にドハマりしてしまったので、Events APIの再送の仕様をまとめて、本来のベストプラクティスに沿った実装と妥当な落とし所をご紹介します。 Slack Events APIとは？ 従来のポーリング型のAPIとは違い、あらかじめ受信するURLとイベント(メッセージの送信、リアクションの追加など)を指定してあげる事で、ワークスペース上でイベントが発生した際にSlackがWebHookしてくれる物となります。
Logging Best Practices: The 13 You Should Know
Log Analytics Logging Best Practices: The 13 You Should Know When you search for things on the internet, sometimes you find treasures like this post on logging, e.g. creating meaningful logs. This post is authored by Brice Figureau (found on Twitter as @_masterzen_). His blog clearly shows he understands the multiple aspects of DevOps and is worth a visit. Our thanks to Brice for letting us adapt
Nuxt.js(Vue.js)とGoでSPA + API(レイヤードアーキテクチャ)でチャットアプリを実装してみた - Qiita
├── interface │ └── controller // サーバへの入力と出力を扱う責務。 ├── application // 作業の調整を行う責務。 ├── domain │ ├── model // ビジネスの概念とビジネスロジック(正直今回はそんなにビジネスロジックない...) │ ├── service // EntityでもValue Objectでもないドメイン層のロジック。 │ └── repository // infra/dbへのポート。 ├── infra // 技術に関すること。 │ ├── db // DBの技術に関すること。 │ ├── logger // Logの技術に関すること。 │ └── router // Routingの技術に関すること。 ├── middleware // リクエスト毎に差し込む処理をまとめたミドルウェア ├── util
トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトー
Logback 使い方メモ - Qiita
説明 依存関係には、とりあえず logback-classic を追加すれば動かせる。 推移的な依存関係の解決で、 logback-core や slf4j-api などが付いてくる。 Logback を使う場合、 API はログファサードである SLF4J を使用する。 設定ファイル（logback.xml）が存在しない場合、デフォルトでコンソールにログが出力される。 ロガーの取得には、 LoggerFactory#getLogger() を使う。 引数にはロガーを特定するための名前を渡す。 普通は、ロガーを使うクラスの Class オブジェクトを渡す。 すると、クラスの FQCN を名前にしたロガーを取得できる。 Logger インターフェースの使い方 ログレベル package sample.logback; import org.slf4j.Logger; import org.s
APIのエラーハンドリングを見直そう - WebPay Engineering Blog
ここ数ヶ月にわたって、WebPayはAPIのエラーにまつわる変更を少しずつ行ってきました。 それに付随してドキュメントも拡張しましたが、変更の背景について十分に説明できていない部分がありました。 この記事では、最近のエラーに関連した変更の背景を紹介し、今後どのようにエラーをハンドルすべきか説明します。 記事の内容は執筆時点のものであり、今後同じようにエラーやAPIの変更を行うことがあります。 変更があっても記事の内容はその時点の内容を保持し、ウェブサイトのドキュメントのみ更新します。 必ずウェブサイトのドキュメントを合わせて参照し、手元で動作確認を行ってください。 エラーはなぜ起きるのか WebPayのAPIは、リクエストされた操作ができなかったときにエラーを返すように設計しています。 可能なかぎりエラーにならないような設計、実装を心がけていますが、エラーは絶対に避けられません。 例えば、
RailsでAPIをつくるときのエラー処理 - Qiita
例外を利用して実装すると便利な場合が多い この投稿では、HTTP経由でJSONを返すようなWeb APIをRailsを利用して実装するとき、エラーレスポンスを返す場合の処理をどう実装するとやりやすいのか、というニッチな話題に触れる。APIでエラーを返したいとき、即ち400以上のステータスコードと共にレスポンスを返したいような場合、どう実装するのが良いか。もしリクエストの処理中にエラーが検出された場合、それ以降の処理を行わずに直ちに中断してエラーレスポンスを返したいという場合が多いため、例外を利用して実装すると便利な場合が多い。 例外を利用しない方が良い場合もある 1つのリクエストに複数の問題が含まれている場合、先に見つけた問題だけを報告するようなエラーレスポンスを返すのか、それとも問題を抱えながらも進めるところまで処理を進めて報告可能な情報を全て含むようなエラーレスポンスを返すのか、という
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様