Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
クライアントを作ってみてわかったこと
Search
Segment
August 04, 2023
Programming
0
310
クライアントを作ってみてわかったこと
Nostr勉強会 #3
https://428lab.connpass.com/event/290514/
Segment
August 04, 2023
Tweet
Share
More Decks by Segment
See All by Segment
Nostr(ノスター)を始めよう
gpsnmeajp
0
340
mocopiを簡易ジェスチャー認識音楽プレイヤーに使ってみた
gpsnmeajp
0
250
分散型SNS nostr 仕組み解説
gpsnmeajp
2
2.4k
AT Protocol (BlueSky Social)仕様解説 ~ W3C DID仕様を添えて ~
gpsnmeajp
3
3.8k
Nostr概説
gpsnmeajp
0
1.1k
Other Decks in Programming
See All in Programming
20250628_非エンジニアがバイブコーディングしてみた
ponponmikankan
0
610
Railsアプリケーションと パフォーマンスチューニング ー 秒間5万リクエストの モバイルオーダーシステムを支える事例 ー Rubyセミナー 大阪
falcon8823
4
1k
AWS CDKの推しポイント 〜CloudFormationと比較してみた〜
akihisaikeda
3
320
来たるべき 8.0 に備えて React 19 新機能と React Router 固有機能の取捨選択とすり合わせを考える
oukayuka
2
880
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
1.8k
システム成長を止めない!本番無停止テーブル移行の全貌
sakawe_ee
1
160
datadog dash 2025 LLM observability for reliability and stability
ivry_presentationmaterials
0
420
What Spring Developers Should Know About Jakarta EE
ivargrimstad
0
380
Quand Symfony, ApiPlatform, OpenAI et LangChain s'allient pour exploiter vos PDF : de la théorie à la production…
ahmedbhs123
0
120
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
660
LINEヤフー データグループ紹介
lycorp_recruit_jp
0
1.7k
すべてのコンテキストを、 ユーザー価値に変える
applism118
2
1.1k
Featured
See All Featured
The Pragmatic Product Professional
lauravandoore
35
6.7k
The Straight Up "How To Draw Better" Workshop
denniskardys
234
140k
Speed Design
sergeychernyshev
32
1k
A designer walks into a library…
pauljervisheath
207
24k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
VelocityConf: Rendering Performance Case Studies
addyosmani
331
24k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.8k
Why Our Code Smells
bkeepers
PRO
337
57k
A better future with KSS
kneath
239
17k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
KATA
mclloyd
30
14k
Transcript
クライアントを作って みてわかったこと Nostr勉強会 #3
あれ、前に作ってませんでしたっけ
基本構成 クライアント リレー REQ EVENT 要求すると、それまでのイベントと、以降のイベントが ぞろぞろと飛んでくる これだけなら簡単
得られるデータは色々足りない 投稿者の公開鍵(=プロフィール) 返信先 返信相手の公開鍵 → 逐次、得られた情報に対する追加情報を取りに行く必要がある
ごちゃごちゃ クライアント リレー Kind 1REQ EVENT Kind 0REQ Kind 1REQ
Kind 7REQ
いろんなリレーから五月雨に クライアント REQ EVENT 要求すると、それまでのイベントと、以降のイベントがぞろぞろと飛んでくる。 気ままに。あるいは飛んでこないかも。時間かかるかも。 指定してないやつ返してくるリレーすらいる。 リレー リレー リレー
EOSE 数値カウントがゆっく り上昇したり、投稿や 名前が少し経ってから 読み込まれる理由
結局どうかというと • つまりこう、HTTPリクエスト投げたらきれいに応答が返ってくるのとは 違う処理を書くことになります。 (ある意味、パイプラインを自前で実装するのに近い。) • さらにリレーごとに購読数には制限があります。 • WebSocketが切れてることもあります。 •
購読しっぱなしのものと、単発で取得したら終わりのものとを 混ざらないようにする必要があります。 • すべてのリレーから返ってくるのを待つと遅すぎます。
• どのリレーに何をリクエストしたか • 帰ってきてるものは適切か (フィルタ外、すでに登録解除したものでないか) • タイムアウトの管理 • お片付け(購読解除) •
キャッシュ • 再接続時の再購読処理 • 一番最初に帰ってきたリレーの結果が正しいとは限らないが、 全部のリレーの回答を待つと遅い。(重要度別に処理を分ける必要) 管理すること
• とにかくUIを非同期にしておく戦略が必要そう • リアルタイム性を重視するのか、 レスポンス性を重視するのか、 安全性を重視するのか、シチュエーションに 合わせた取得方法の選定が必要そう (ミスると → フォロー吹っ飛び)
• 通信が安定しない環境(モバイル等)ではよりしんどさが増す → 旧来のWebサービスみたいに、責任持って安定して 応答するサーバーを設置してそこで処理したくなる… さらには
クロスプラットフォームクライアント Nemesia for nostr 開発中 (完成時期未定)