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
270
クライアントを作ってみてわかったこと
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
180
mocopiを簡易ジェスチャー認識音楽プレイヤーに使ってみた
gpsnmeajp
0
180
分散型SNS nostr 仕組み解説
gpsnmeajp
2
1.8k
AT Protocol (BlueSky Social)仕様解説 ~ W3C DID仕様を添えて ~
gpsnmeajp
3
3.3k
Nostr概説
gpsnmeajp
0
820
Other Decks in Programming
See All in Programming
なぜ宣言的 UI は壊れにくいのか / Why declarative UI is less fragile
uenitty
29
13k
MIERUNE BBQにおけるユーザー中心設計()
mierune
PRO
1
110
Folding Cheat Sheet #7
philipschwarz
PRO
0
150
Rust.Nagoya #1
codemountains
0
170
Mastering Developer Experience: A Roadmap for Success 【開発生産性Conference 2024】
findyinc
1
380
Javaの現状2024夏 / Java current status 2024 summer
kishida
4
1.4k
スクラムマスターって孤独じゃないですか?
yoshitaroyoyo
1
140
Advanced App Shrinking Techniques
cbeyls
2
150
Rustのweb開発を助ける 便利なツール紹介
yuki0418
1
190
SDCon2024: Enabling DevOps and Team Topologies thru architecture: architecting for fast flow
cer
PRO
0
780
AHC035解説
terryu16
0
710
【Go言語】golangci-lintの使い方
tomo1227
0
270
Featured
See All Featured
What the flash - Photography Introduction
edds
65
11k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
245
1.2M
Reflections from 52 weeks, 52 projects
jeffersonlam
346
19k
The Illustrated Children's Guide to Kubernetes
chrisshort
39
47k
Thoughts on Productivity
jonyablonski
64
4.1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
248
20k
[RailsConf 2023] Rails as a piece of cake
palkan
35
4.4k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
353
29k
Fontdeck: Realign not Redesign
paulrobertlloyd
79
5.1k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
26
2.1k
Mobile First: as difficult as doing things right
swwweet
219
8.8k
GraphQLとの向き合い方2022年版
quramy
36
13k
Transcript
クライアントを作って みてわかったこと Nostr勉強会 #3
あれ、前に作ってませんでしたっけ
基本構成 クライアント リレー REQ EVENT 要求すると、それまでのイベントと、以降のイベントが ぞろぞろと飛んでくる これだけなら簡単
得られるデータは色々足りない 投稿者の公開鍵(=プロフィール) 返信先 返信相手の公開鍵 → 逐次、得られた情報に対する追加情報を取りに行く必要がある
ごちゃごちゃ クライアント リレー Kind 1REQ EVENT Kind 0REQ Kind 1REQ
Kind 7REQ
いろんなリレーから五月雨に クライアント REQ EVENT 要求すると、それまでのイベントと、以降のイベントがぞろぞろと飛んでくる。 気ままに。あるいは飛んでこないかも。時間かかるかも。 指定してないやつ返してくるリレーすらいる。 リレー リレー リレー
EOSE 数値カウントがゆっく り上昇したり、投稿や 名前が少し経ってから 読み込まれる理由
結局どうかというと • つまりこう、HTTPリクエスト投げたらきれいに応答が返ってくるのとは 違う処理を書くことになります。 (ある意味、パイプラインを自前で実装するのに近い。) • さらにリレーごとに購読数には制限があります。 • WebSocketが切れてることもあります。 •
購読しっぱなしのものと、単発で取得したら終わりのものとを 混ざらないようにする必要があります。 • すべてのリレーから返ってくるのを待つと遅すぎます。
• どのリレーに何をリクエストしたか • 帰ってきてるものは適切か (フィルタ外、すでに登録解除したものでないか) • タイムアウトの管理 • お片付け(購読解除) •
キャッシュ • 再接続時の再購読処理 • 一番最初に帰ってきたリレーの結果が正しいとは限らないが、 全部のリレーの回答を待つと遅い。(重要度別に処理を分ける必要) 管理すること
• とにかくUIを非同期にしておく戦略が必要そう • リアルタイム性を重視するのか、 レスポンス性を重視するのか、 安全性を重視するのか、シチュエーションに 合わせた取得方法の選定が必要そう (ミスると → フォロー吹っ飛び)
• 通信が安定しない環境(モバイル等)ではよりしんどさが増す → 旧来のWebサービスみたいに、責任持って安定して 応答するサーバーを設置してそこで処理したくなる… さらには
クロスプラットフォームクライアント Nemesia for nostr 開発中 (完成時期未定)