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
350
mocopiを簡易ジェスチャー認識音楽プレイヤーに使ってみた
gpsnmeajp
0
260
分散型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
テストから始めるAgentic Coding 〜Claude Codeと共に行うTDD〜 / Agentic Coding starts with testing
rkaga
17
6.2k
MCPで実現できる、Webサービス利用体験について
syumai
7
2.2k
副作用と戦う PHP リファクタリング ─ ドメインイベントでビジネスロジックを解きほぐす
kajitack
3
480
型で語るカタ
irof
1
850
構文解析器入門
ydah
7
1.9k
リッチエディターを安全に開発・運用するために
unachang113
1
270
フロントエンドのパフォーマンスチューニング
koukimiura
6
2.3k
Jakarta EE Meets AI
ivargrimstad
0
390
AIに安心して任せるためにTypeScriptで一意な型を作ろう
arfes0e2b3c
0
270
AIのメモリー
watany
11
1.1k
The Evolution of Enterprise Java with Jakarta EE 11 and Beyond
ivargrimstad
0
540
状態遷移図を書こう / Sequence Chart vs State Diagram
orgachem
PRO
3
290
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
49
14k
A Modern Web Designer's Workflow
chriscoyier
695
190k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.8k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
283
13k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
Music & Morning Musume
bryan
46
6.7k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Being A Developer After 40
akosma
90
590k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Git: the NoSQL Database
bkeepers
PRO
431
65k
Transcript
クライアントを作って みてわかったこと Nostr勉強会 #3
あれ、前に作ってませんでしたっけ
基本構成 クライアント リレー REQ EVENT 要求すると、それまでのイベントと、以降のイベントが ぞろぞろと飛んでくる これだけなら簡単
得られるデータは色々足りない 投稿者の公開鍵(=プロフィール) 返信先 返信相手の公開鍵 → 逐次、得られた情報に対する追加情報を取りに行く必要がある
ごちゃごちゃ クライアント リレー Kind 1REQ EVENT Kind 0REQ Kind 1REQ
Kind 7REQ
いろんなリレーから五月雨に クライアント REQ EVENT 要求すると、それまでのイベントと、以降のイベントがぞろぞろと飛んでくる。 気ままに。あるいは飛んでこないかも。時間かかるかも。 指定してないやつ返してくるリレーすらいる。 リレー リレー リレー
EOSE 数値カウントがゆっく り上昇したり、投稿や 名前が少し経ってから 読み込まれる理由
結局どうかというと • つまりこう、HTTPリクエスト投げたらきれいに応答が返ってくるのとは 違う処理を書くことになります。 (ある意味、パイプラインを自前で実装するのに近い。) • さらにリレーごとに購読数には制限があります。 • WebSocketが切れてることもあります。 •
購読しっぱなしのものと、単発で取得したら終わりのものとを 混ざらないようにする必要があります。 • すべてのリレーから返ってくるのを待つと遅すぎます。
• どのリレーに何をリクエストしたか • 帰ってきてるものは適切か (フィルタ外、すでに登録解除したものでないか) • タイムアウトの管理 • お片付け(購読解除) •
キャッシュ • 再接続時の再購読処理 • 一番最初に帰ってきたリレーの結果が正しいとは限らないが、 全部のリレーの回答を待つと遅い。(重要度別に処理を分ける必要) 管理すること
• とにかくUIを非同期にしておく戦略が必要そう • リアルタイム性を重視するのか、 レスポンス性を重視するのか、 安全性を重視するのか、シチュエーションに 合わせた取得方法の選定が必要そう (ミスると → フォロー吹っ飛び)
• 通信が安定しない環境(モバイル等)ではよりしんどさが増す → 旧来のWebサービスみたいに、責任持って安定して 応答するサーバーを設置してそこで処理したくなる… さらには
クロスプラットフォームクライアント Nemesia for nostr 開発中 (完成時期未定)