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
370
mocopiを簡易ジェスチャー認識音楽プレイヤーに使ってみた
gpsnmeajp
0
260
分散型SNS nostr 仕組み解説
gpsnmeajp
2
2.5k
AT Protocol (BlueSky Social)仕様解説 ~ W3C DID仕様を添えて ~
gpsnmeajp
3
3.9k
Nostr概説
gpsnmeajp
0
1.1k
Other Decks in Programming
See All in Programming
Range on Rails ―「多重範囲型」という新たな選択肢が、複雑ロジックを劇的にシンプルにしたワケ
rizap_tech
0
100
NixOS + Kubernetesで構築する自宅サーバーのすべて
ichi_h3
0
620
CSC305 Lecture 04
javiergs
PRO
0
270
(Extension DC 2025) Actor境界を越える技術
teamhimeh
1
250
Railsだからできる 例外業務に禍根を残さない 設定設計パターン
ei_ei_eiichi
0
460
XP, Testing and ninja testing ZOZ5
m_seki
3
620
SpecKitでどこまでできる? コストはどれくらい?
leveragestech
0
690
Domain-centric? Why Hexagonal, Onion, and Clean Architecture Are Answers to the Wrong Question
olivergierke
2
820
CSC305 Lecture 06
javiergs
PRO
0
220
クラシルを支える技術と組織
rakutek
0
200
複雑化したリポジトリをなんとかした話 pipenvからuvによるモノレポ構成への移行
satoshi256kbyte
1
1k
その面倒な作業、「Dart」にやらせませんか? Flutter開発者のための業務効率化
yordgenome03
1
120
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
For a Future-Friendly Web
brad_frost
180
9.9k
Producing Creativity
orderedlist
PRO
347
40k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.7k
Git: the NoSQL Database
bkeepers
PRO
431
66k
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
Designing Experiences People Love
moore
142
24k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.5k
Practical Orchestrator
shlominoach
190
11k
Side Projects
sachag
455
43k
Transcript
クライアントを作って みてわかったこと Nostr勉強会 #3
あれ、前に作ってませんでしたっけ
基本構成 クライアント リレー REQ EVENT 要求すると、それまでのイベントと、以降のイベントが ぞろぞろと飛んでくる これだけなら簡単
得られるデータは色々足りない 投稿者の公開鍵(=プロフィール) 返信先 返信相手の公開鍵 → 逐次、得られた情報に対する追加情報を取りに行く必要がある
ごちゃごちゃ クライアント リレー Kind 1REQ EVENT Kind 0REQ Kind 1REQ
Kind 7REQ
いろんなリレーから五月雨に クライアント REQ EVENT 要求すると、それまでのイベントと、以降のイベントがぞろぞろと飛んでくる。 気ままに。あるいは飛んでこないかも。時間かかるかも。 指定してないやつ返してくるリレーすらいる。 リレー リレー リレー
EOSE 数値カウントがゆっく り上昇したり、投稿や 名前が少し経ってから 読み込まれる理由
結局どうかというと • つまりこう、HTTPリクエスト投げたらきれいに応答が返ってくるのとは 違う処理を書くことになります。 (ある意味、パイプラインを自前で実装するのに近い。) • さらにリレーごとに購読数には制限があります。 • WebSocketが切れてることもあります。 •
購読しっぱなしのものと、単発で取得したら終わりのものとを 混ざらないようにする必要があります。 • すべてのリレーから返ってくるのを待つと遅すぎます。
• どのリレーに何をリクエストしたか • 帰ってきてるものは適切か (フィルタ外、すでに登録解除したものでないか) • タイムアウトの管理 • お片付け(購読解除) •
キャッシュ • 再接続時の再購読処理 • 一番最初に帰ってきたリレーの結果が正しいとは限らないが、 全部のリレーの回答を待つと遅い。(重要度別に処理を分ける必要) 管理すること
• とにかくUIを非同期にしておく戦略が必要そう • リアルタイム性を重視するのか、 レスポンス性を重視するのか、 安全性を重視するのか、シチュエーションに 合わせた取得方法の選定が必要そう (ミスると → フォロー吹っ飛び)
• 通信が安定しない環境(モバイル等)ではよりしんどさが増す → 旧来のWebサービスみたいに、責任持って安定して 応答するサーバーを設置してそこで処理したくなる… さらには
クロスプラットフォームクライアント Nemesia for nostr 開発中 (完成時期未定)