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
240
クライアントを作ってみてわかったこと
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
130
mocopiを簡易ジェスチャー認識音楽プレイヤーに使ってみた
gpsnmeajp
0
140
分散型SNS nostr 仕組み解説
gpsnmeajp
2
1.6k
AT Protocol (BlueSky Social)仕様解説 ~ W3C DID仕様を添えて ~
gpsnmeajp
3
3.1k
Nostr概説
gpsnmeajp
0
770
Other Decks in Programming
See All in Programming
Scalable Customer Journey Orchestration (CJO)
lewuathe
0
420
Next.js App Router
quramy
12
1.9k
単体テストを書かない技術 #phpcon_odawara
o0h
PRO
27
8.5k
PostmanでAPIの動作確認が楽になった話
h455h1
0
180
新宿ダンジョンを可視化してみた
satoshi7190
3
400
From Spring Boot 2 to Spring Boot 3 with Java 21 and Jakarta EE
ivargrimstad
0
670
AWS CDKコントリビュートTIPS / aws-cdk-contribution-tips
gotok365
4
410
Azure OpenAI Serviceのプロンプトエンジニアリング入門
tomokusaba
3
900
DMMプラットフォームがTiDB Cloudを採用した背景
pospome
9
4.3k
スキーマ駆動開発による品質とスピードの両立 - 私達は何故、スキーマを書くのか
kentaroutakeda
0
180
Behind VS Code Extensions for JavaScript / TypeScript Linnting and Formatting
unvalley
6
1.3k
Implementing Design Systems in Swift
seyfoyun
2
480
Featured
See All Featured
Music & Morning Musume
bryan
41
5.6k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
188
16k
For a Future-Friendly Web
brad_frost
172
9k
The Art of Programming - Codeland 2020
erikaheidi
43
12k
Optimising Largest Contentful Paint
csswizardry
13
2.4k
Raft: Consensus for Rubyists
vanstee
133
6.3k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
245
20k
Large-scale JavaScript Application Architecture
addyosmani
504
110k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.1k
Typedesign – Prime Four
hannesfritz
36
2.1k
Building Applications with DynamoDB
mza
88
5.6k
From Idea to $5000 a Month in 5 Months
shpigford
378
45k
Transcript
クライアントを作って みてわかったこと Nostr勉強会 #3
あれ、前に作ってませんでしたっけ
基本構成 クライアント リレー REQ EVENT 要求すると、それまでのイベントと、以降のイベントが ぞろぞろと飛んでくる これだけなら簡単
得られるデータは色々足りない 投稿者の公開鍵(=プロフィール) 返信先 返信相手の公開鍵 → 逐次、得られた情報に対する追加情報を取りに行く必要がある
ごちゃごちゃ クライアント リレー Kind 1REQ EVENT Kind 0REQ Kind 1REQ
Kind 7REQ
いろんなリレーから五月雨に クライアント REQ EVENT 要求すると、それまでのイベントと、以降のイベントがぞろぞろと飛んでくる。 気ままに。あるいは飛んでこないかも。時間かかるかも。 指定してないやつ返してくるリレーすらいる。 リレー リレー リレー
EOSE 数値カウントがゆっく り上昇したり、投稿や 名前が少し経ってから 読み込まれる理由
結局どうかというと • つまりこう、HTTPリクエスト投げたらきれいに応答が返ってくるのとは 違う処理を書くことになります。 (ある意味、パイプラインを自前で実装するのに近い。) • さらにリレーごとに購読数には制限があります。 • WebSocketが切れてることもあります。 •
購読しっぱなしのものと、単発で取得したら終わりのものとを 混ざらないようにする必要があります。 • すべてのリレーから返ってくるのを待つと遅すぎます。
• どのリレーに何をリクエストしたか • 帰ってきてるものは適切か (フィルタ外、すでに登録解除したものでないか) • タイムアウトの管理 • お片付け(購読解除) •
キャッシュ • 再接続時の再購読処理 • 一番最初に帰ってきたリレーの結果が正しいとは限らないが、 全部のリレーの回答を待つと遅い。(重要度別に処理を分ける必要) 管理すること
• とにかくUIを非同期にしておく戦略が必要そう • リアルタイム性を重視するのか、 レスポンス性を重視するのか、 安全性を重視するのか、シチュエーションに 合わせた取得方法の選定が必要そう (ミスると → フォロー吹っ飛び)
• 通信が安定しない環境(モバイル等)ではよりしんどさが増す → 旧来のWebサービスみたいに、責任持って安定して 応答するサーバーを設置してそこで処理したくなる… さらには
クロスプラットフォームクライアント Nemesia for nostr 開発中 (完成時期未定)