AIエージェント時代のエンジニアになろう #jawsug #jawsdays2025 / 20250301 Agentic AI Engineering

はじめに どうもしょーやです。 Twitter(X)やってるのでよかったらフォローしてください 今回は最近話題になっていたHTMXを使って簡単なチャットアプリを作っていこうと思います! チャットを作る上でwebsocketを用いたリアルタイムな通信が必要なわけですが、あまり日本語でHTMXのwebsocketを実装している記事が見つからなく💦 公式ドキュメントと睨めっこしながら手探りで作ったのでご指摘や改善案など大歓迎です! HTMXとは 以下公式ドキュメントの内容をdeeplで和訳したものです。 htmxは、属性を使用して、AJAX、CSSトランジション、WebSocket、およびサーバー送信イベントにHTMLで直接アクセスできるため、ハイパーテキストのシンプルさとパワーで最新のユーザーインターフェイスを構築できます。 HTMXは既存のHTMLの記法を拡張したもので、JSを書かずともA
WebSocketを双方向通信のために使うプロトコルでしょ、という感じのうっすら理解で誤魔化していた[1]のですが、IoTアプリケーションぽいものを作ることがあって、理解を深めるためにあらためて学びました、という投稿です。 今回はWebSocketでエコーするサーバーを、TCPライブラリだけを用いてRustで実装していきます。コードは以下です。 WebSocketとは RFC 6455で定義された、主に双方向でやり取りするために用いられる通信プロトコルです。 WebSocketが直接用いるプロトコルはTCPですが、ハンドシェイクはHTTP(S)によって行われます。WebSocketを使うプロトコルとして、MQTT over WebSocketやSTOMPなどがあります。 最近のWebアプリケーションではごく普通に用いられてます。企業サイトなどでよく見る問い合わせ用のチャットフォームなどは、
注意:今回の記事はあくまで初心者向けにWebSocketの概要を理解してもらうために執筆されている。そのため、一部正確性を欠く可能性がある。詳細にWebSocketについて学びたいならMicrosoftの解説記事やWebSocket Protocolを確認してほしい。 はじめに 今回の記事ではWebSocketを解説する。 対象とする読者 WebSocketについてわからないひと WebSocketとは? WebSocketは双方向のHTTPプロトコルで、クライアントとサーバの通信で成立する。HTTPとは異なり、ws://あるいはwss://から始まる。WebSocketはHTTPとは違って、クライアントとサーバ間の接続はどちらか一方が切断されると終了する。WebSocketが動く仕組みはHTTPのそれとは異なり、ステータスコード101がプロトコルの切り替えを示す。 WebSocketが動
以前websocketを使ったプロダクトと関ったことがキッカケで少し気になったので調べてみた。 websocketの用途等はいろんな記事でわかりやすい説明されているので省略。 大まかな流れは以下の図に示す通りだと思われる。 クライアントからprotocol切り替え依頼(http GET upgrade) サーバ承認(protocol切り替え) websocket protocolを使った通信開始 パケットの調査 以下のような単純なサーバとクライアントを実行とキャプチャして内容を確認した。 クライアントはHi!を送り、受信後にサーバはYo!を返す。 これを三回繰り返す。 ほぼこの例文の通り。 双方向のメリットを引き出せてないが一旦無視。 server package main import ( "context" "fmt" "log" "net/http" "time" "nhooyr.i
こんにちはSREの黒田です。 これは第2回 Nature Engineering Blog 祭9日目のエントリです。 昨日はCorporate ITのマロニーによる GASを使って社内のSaaSアカウントを可視化しよう - Nature Engineering Blog でした。 昨日に続いて今日のお話も、話題の新製品Remo nanoやMatterとは関係ありません。 TL;DR WebSocketで大量に永続接続されているALBのSSL証明書を更新すると、接続がばっこんばっこん切られて大変なので、ALBを二台用意して緩やかに接続を移行するようにしたら、大変平和になって僕もみんなもハッピーになった。 背景 そもそもNatureではどこに何のためにWebSocketを使ってるの?って話から始めると長いので、詳しくはこちらを見ていただければと思います (結構前の資料なので今とは違う部分も色々
WebSocketのツラミ 中継サービスの対応がないと切れる ルーターによっては長時間アクセスがないと切れる 切れたら繋ぎなおすのはクライアントの実装次第 セキュアにつなぐためにはサーバーもクライアントも新バージョンのサポートが必要 接続数が膨れず、安定して接続を維持するのには結構ノウハウが求められる 単純に切れたら即繋ぐでは中継やサーバーに問題が発生することもある そこでEventSourceですよ メジャーブラウザでサポート・互換性も高い プロトコル仕様がただのHTTPロングポール+アルファ なのでほとんどの接続経路で中継トラブルが少ない JSのEventSource実装がセッション維持を頑張ってくれる サーバーから切断されたら再接続をしようとする 特にGoなら標準機能でさっくりサーバーが書ける クライアント実装 let es = new EventSource("/sse"); es
概要 この記事はRustその2 Advent Calendar 2019の16日目です。17日に若干時間はみ出ていますが気にせずいきましょう() 誰? Rustは今年の夏ぐらいから興味持ってちょこちょこやってる morifuji です。actix-webちょこっと触ったりとかスクレイピングで遊んだりぐらいしかないです。実務未経験の初心者です。(下記のスライドはこの前のLTで発表した内容です) speakerdeck.com やりたいこと ブラウザーのgetDisplay というAPIを最近ちょこちょこ見て、WebRTCと組み合わせたらオモシロソウダナーと思ったので、Rustで気軽にWebSocketサーバを作ってみようかと思ったのでした。 NodejsのSocket.ioがとても有名ですが、Rustにも ws-rsというライブラリがあったので勉強がてらに使ってみました。 やりたいこととし
現在開発中のシステムにリアルタイムな処理があり、そこで socket.io を使おうかなと思ってて、そういう折にタイムリーにもこの辺りの記事がタイムラインで出てきたのでメモ代わりに自分の意見を残しておく。 blog.jxck.io qiita.com socket.io が提供してくれているもの 「ブラウザとサーバ間のプロトコル」という観点で見ると socket.io は WebSocket を基本として繋がらなかった時に XHR Long Polling や polling といった形式の代替手段を提供してくれるもの、という位置づけ。 一方で「ライブラリ」という観点で見ると socket.io はリアルタイムアプリケーションを作る際に必要になる処理をまとめて実装し、クライアントとサーバ間での EventEmitter として抽象化してくれているもの、という風になる。 もう少し噛み砕いて言
プライベートで開発しているプロダクト用の技術調査。 とりあえず簡単に、受け取ったメッセージをそのまま返すサーバを実装した。 github.com docker-compose up して client/index.html をブラウザで開くと、開発者コンソールから「Message from server echo {"msg":"hello world!"}」の出力が確認できる。 Golang の実装部分は下記の Qiita 記事をそのまま参考にしたので、解説はそちらを参照のこと。 Go 言語で Websocket を使ったアプリケーションをつくる 余談 *-test ってリポジトリ名がなんだか微妙な感じがした。 practice とか、 training とかがいいのかな? 2018-06-09 追記 あまりよく確認していなかったが trevex/golem は長らく更新のないプロジェク
こんにちは。私はSergey Kamardin(セルゲイ・カマルディン)です。Mail.Ru(ロシアの電子メールサービス会社)で開発者をしています。 この記事では、どのように私がGoを使って高負荷対応のWebSocketサーバを開発したかについて説明したいと思っています。 パフォーマンス最適化のアイデアやテクニックを通じて、WebSocketの知識はあるもののGoについてはほとんど知らないという方のお役に立てれば幸いです。 1. はじめに まずは開発に至った経緯について、どうして私たちがこのサーバを必要としたのかを説明しておきましょう。 Mail.Ruには多くのステートフルなシステムがあります。ユーザのeメール保存もその1つです。システム内、およびシステムイベントの状態変更を追跡する方法にはいくつかの種類がありますが、それらは主に状態変更に関するシステム通知、または周期的なシステムのポーリ
WebSocketの扱うサービスでは、長時間のコネクション、再接続処理、プロキシ、ロードバランサなど、インフラの面で多くの問題を抱えがちです。弊社のサービス「pixiv」の9周年企画でも、この問題に直面しました。 実際にそこで構築したインフラの事例をもとに、本運用に使えるWebSocketサーバの構成について、pixivインフラ部の南川からご紹介します。 * 9周年企画 “黒歴史”をロケットで宇宙に飛ばす pixiv黒歴史 そもそも WebSocket とは? WebSocketはTCP上で動く双方向通信のための通信規格です。 Webページの読み込みで行われているような、クライアントがサーバにデータを要求し、サーバはクライアントにレスポンスを返すというHTTPの通信ルールとは違います。サーバと長時間コネクションを確立し、Socketのようにデータのやり取りを行います。そして、コネクションを
Webアプリにリアルタイムの双方向通信が必要な場合、WebSocketを選ぶのは自然なことだと思います。では、どのツールでWebSocketサーバを構築すべきでしょうか。パフォーマンスは重要ですが、開発のプロセスも見過ごしてはなりません。パフォーマンスを基準にするだけでなく、開発のしやすさも考慮に入れるべきでしょう。今回の大合戦では、Clojure、C++、Elixir、Go、NodeJS、Rubyのそれぞれの言語によって慣用的な手法で実装されたシンプルなWebSocketサーバを比較したいと思います。 テスト内容 サーバに実装するのは、 echo と broadcast の2つのメッセージのみを扱う非常に単純なプロトコルです。echoは送信クライアントに返され、ブロードキャストは全ての接続クライアントに送信されます。そしてブロードキャストが完了すると、結果メッセージが送信者に返されます。
Intro 「Socket.IO 使ったほうがいいですか?」 という主旨の質問をもらった。 これは、WebSocket が繋がらない環境に向けて、フォールバック機能を有する Socket.IO にしておいた方が良いのかという意味である。 WebSocket が出てきた当初と比べて、Web を取り巻く状況は変わったが、変わってないところもある。 念のためと Socket.IO を使うのもよいが、「本当に必要なのか」を問うのは重要である。 Rails も ActionCable で WebSocket に対応し、ユーザも増えるかもしれないことも踏まえ、 ここで、もう一度現状について、把握している範囲で解説しておく。 "繋がらない" とは 最初に、なぜ 繋がらない ことがあるのかを、きちんと把握したい。 まず WebSocket の有史全体をみれば、繋がらないとして語られていた現象は、大きく三つ
※ (2016/9/19 追記) Nginx 使った対応方法も記載しているので、あわせて参考にして下さい。 昨今のサービスにおいて、暗号化はもはや必須の流れである。 GoogleやFacebookなど主要なサービスはずいぶん前からHTTPS通信を標準としているし、HTTPS化対応しているサイトはSEO的にも優遇されるようになる という方針が出ていたりする。 前記事でSocket.IO + Redis PubSubを用いたリアルタイムメッセージ配信の仕組みをまとめたが、このままWebSocketを利用すると当然インターネット上を平文のテキストが流れてしまう。 また、チャット機能を呼び出す親元のWebページがHTTPSで提供されているものであれば、Mixed Content でブラウザによっては暗号化されていないWebSocket通信をブロックされることもあるだろう。 後からSSL/TLS対応
本連載「Socket.IOで始めるWebSocket超入門」では、WebSocketを扱うことができるNode.jsのライブラリ「Socket.IO」を使って、サンプルアプリケーションを構築していきます。 具体的には、チャットを題材とし、送受信されるメッセージ内容が即時反映されるリアルタイムかつ双方向なWebアプリケーションの構築を目標とします。さらに構築の中で、Socket.IOの各種ライブラリの使い方について解説することで、Socket.IOを使ったWebSocketの実践方法を体系的に学びます。 いまさら聞けないWebSocketとは WebSocketはリアルタイムWeb技術の一種であり、リアルタイムかつ双方向な通信を実現するプロトコルです。WebSocket通信では、コネクション確立時にHTTPからWebSocketへプロトコルを切り替えます。1度コネクションが確立されると、「w
WebSocketは、HTTPとはプロトコルが異なるため、nginxでリバースプロキシさせた場合に、xhr-pollingしか通さず、Websocketでエラーが発生してしまいます。 HTTP/1.1では、HTTP/1.1以外のプロトコルに切り替えるUpgradeヘッダがありますが、Nginxデフォルトの設定では、Upgradeヘッダが付与されていないため、Upgaradeヘッダに付与する必要があります。 ※ Nginx1.1ぐらいまでは、UpgaradeヘッダがWebSocketのには対応していないようです。 server { listen 80; server_name localhost; root /usr/share/nginx/html; #charset koi8-r; #access_log /var/log/nginx/host.access.log main; prox
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました チャットや通知など、Webブラウザなどとリアルタイムでコミュニケーションしたいと考える場面はたくさんあります。しかし多くのクライアントとリアルタイム通信するための基盤を作るのはとても大変です。 そこで使ってみたいのがCentrifugoです。Goで作られたWebSocketを使ったリアルタイムタイムメッセージングサーバです。 Centrifugoの使い方 まずシステムにログインします。 ダッシュボードです。ノードは一つ動作しています。 メッセージを飛ばします。メッセージはJSON形式で送信します。 受信側ではJSONフォーマットで受け取ります。 元々はCentrifugeという名前で、それをGoで書き換えることでCentrifugoとなったようです。ライブラリはPython/PHP
CTOの椎名アマドです。 昨日弊社Pairyは1億円調達の発表を行ないました! 色々な方から嬉しいメッセージなどが届いて嬉しい限りです。 ちなみにエンジニア採用を本格的に行なってるので、興味ある人は http://timers-inc.com を見てみてください! さて、今回はリアルタイム通信に関してです。 前々から我々は Pairy にwebsocket使ったリアルタイム通信を導入したいねと言っていて、最近やっと導入に成功しました。 Ratchet と ZeroMQ という2つのライブラリの組み合わせによって、比較的簡単に実装できてます。 設計の概要 設計はざっくりと: 1. ネイティブアプリAが投稿などのアクションを行ない、webサーバーにリクエスト送信 2. webサーバーがDBサーバーに書き込み 3. webサーバーがsocketサーバーにメッセージをZeroMQ経由で送信 4.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く