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
360
mocopiを簡易ジェスチャー認識音楽プレイヤーに使ってみた
gpsnmeajp
0
260
分散型SNS nostr 仕組み解説
gpsnmeajp
2
2.5k
AT Protocol (BlueSky Social)仕様解説 ~ W3C DID仕様を添えて ~
gpsnmeajp
3
3.8k
Nostr概説
gpsnmeajp
0
1.1k
Other Decks in Programming
See All in Programming
Langfuseと歩む生成AI活用推進
licux
3
300
学習を成果に繋げるための個人開発の考え方 〜 「学習のための個人開発」のすすめ / personal project for leaning
panda_program
1
110
tool ディレクティブを導入してみた感想
sgash708
1
150
兎に角、コードレビュー
mitohato14
0
150
Understanding Ruby Grammar Through Conflicts
yui_knk
1
130
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
180
『リコリス・リコイル』に学ぶ!! 〜キャリア戦略における計画的偶発性理論と変わる勇気の重要性〜
wanko_it
1
600
MCPで実現するAIエージェント駆動のNext.jsアプリデバッグ手法
nyatinte
7
890
コーディングは技術者(エンジニア)の嗜みでして / Learning the System Development Mindset from Rock Lady
mackey0225
2
580
パスタの技術
yusukebe
1
400
SOCI Index Manifest v2が出たので調べてみた / Introduction to SOCI Index Manifest v2
tkikuc
1
110
オープンセミナー2025@広島「君はどこで動かすか?」アンケート結果
satoshi256kbyte
0
210
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
The Language of Interfaces
destraynor
160
25k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.8k
Facilitating Awesome Meetings
lara
55
6.5k
Code Review Best Practice
trishagee
70
19k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Optimizing for Happiness
mojombo
379
70k
Docker and Python
trallard
45
3.5k
Building Adaptive Systems
keathley
43
2.7k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.5k
Transcript
クライアントを作って みてわかったこと Nostr勉強会 #3
あれ、前に作ってませんでしたっけ
基本構成 クライアント リレー REQ EVENT 要求すると、それまでのイベントと、以降のイベントが ぞろぞろと飛んでくる これだけなら簡単
得られるデータは色々足りない 投稿者の公開鍵(=プロフィール) 返信先 返信相手の公開鍵 → 逐次、得られた情報に対する追加情報を取りに行く必要がある
ごちゃごちゃ クライアント リレー Kind 1REQ EVENT Kind 0REQ Kind 1REQ
Kind 7REQ
いろんなリレーから五月雨に クライアント REQ EVENT 要求すると、それまでのイベントと、以降のイベントがぞろぞろと飛んでくる。 気ままに。あるいは飛んでこないかも。時間かかるかも。 指定してないやつ返してくるリレーすらいる。 リレー リレー リレー
EOSE 数値カウントがゆっく り上昇したり、投稿や 名前が少し経ってから 読み込まれる理由
結局どうかというと • つまりこう、HTTPリクエスト投げたらきれいに応答が返ってくるのとは 違う処理を書くことになります。 (ある意味、パイプラインを自前で実装するのに近い。) • さらにリレーごとに購読数には制限があります。 • WebSocketが切れてることもあります。 •
購読しっぱなしのものと、単発で取得したら終わりのものとを 混ざらないようにする必要があります。 • すべてのリレーから返ってくるのを待つと遅すぎます。
• どのリレーに何をリクエストしたか • 帰ってきてるものは適切か (フィルタ外、すでに登録解除したものでないか) • タイムアウトの管理 • お片付け(購読解除) •
キャッシュ • 再接続時の再購読処理 • 一番最初に帰ってきたリレーの結果が正しいとは限らないが、 全部のリレーの回答を待つと遅い。(重要度別に処理を分ける必要) 管理すること
• とにかくUIを非同期にしておく戦略が必要そう • リアルタイム性を重視するのか、 レスポンス性を重視するのか、 安全性を重視するのか、シチュエーションに 合わせた取得方法の選定が必要そう (ミスると → フォロー吹っ飛び)
• 通信が安定しない環境(モバイル等)ではよりしんどさが増す → 旧来のWebサービスみたいに、責任持って安定して 応答するサーバーを設置してそこで処理したくなる… さらには
クロスプラットフォームクライアント Nemesia for nostr 開発中 (完成時期未定)