Ur/Web: A Simple Model for Programming the Web

Adam Chlipala

POPL '15: Proceedings of the 42nd Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages

2021/6/22 yama

Author

¡ Adam Chlipala

¡ MIT Computer Science and Artificial Intelligence Laboratory (CSAIL)

¡ Associate Professor of Computer Science

1

1.Introduction

¡ World Wide Web¡ 静的ドキュメントの配信システムから徐々に進化

¡ 今日では非常に人気のあるプラットフォーム

¡ HTML, CSS, JavaScriptに加えJSON, SQLといった様々な言語の複雑な相互埋め込み

→人気のWeb開発ツールにも数多くの矛盾2

1.Introduction

¡ 様々な解決策¡ Linksプロジェクト: tierless programmingの開拓

¡ 静的に型付けされた1つの関数型言語内で動的Webアプリケーションのすべての部分を組み合わせるようなプログラム

¡ Web Toolkit, Closure Tool (Google)

¡ LINQ (Microsoft)3

1.Introduction

¡ Ur/Web: モダンなWebアプリケーションのプログラミングのための単純モデル

¡ 関数型プログラミング言語であるUrの拡張

¡ カプセル化(encapsulation)と同時実行性(concurrency)の2つが要

¡ 実際に収益性の高い商用サイトでの利用例も

4

Ur/Web���

1. プログラムの一部が適当な言語に自動的にコンパイルされる

2. すべてのオブジェクトは強く型指定されている

3. サーバ内で唯一永続的な状態を持つDBにはSQLインタフェースを通じてアクセスする

4. サーバは型指定された関数のセットを公開しており、クライアントはRPCができる 5

Ur/Web���

5. クライアントのHTMLページには他のページへのリンクが含まれている場合があり、たどると強制的に新しいページを生成・表示する

6. HTMLページにはクライアントで実行されるUr/Webコードが埋め込まれている場合がある

7. すべてのRPCはアトミックに実行されるように見える

8. サーバコードは型指定されたメッセージパッシングチャネルを割り当てる場合がある 6

2.A Tutorial Introduction to Ur/Web

¡ 例: マルチユーザチャットアプリケーション¡ サイトの訪問者はチャットルームを選択

¡ チャットルームの訪問者は誰でもログに任意の行のテキストを追加可能

¡ 他のユーザもログを最新の状態に保つことが必要

¡ ここでは簡単な20世紀のアプリのスタイルからスタート7

2.1 HTML and SQL

¡ モダンなWebアプリは様々な言語やプロトコルを使用

¡ Ur/Webはほとんどを統合プログラミングモデルに秘匿

¡ HTMLとSQLだけは明示的に公開¡ HTML: Webページの構造をツリーとして記述するために必要

¡ SQL:サーバ上の永続的な関係データベースにアクセスするために必要8

2.1 HTML and SQL

9

2.1 HTML and SQL

1. すべてのチャットルームを一覧表示(main)

2. 部屋が選択されたらチャットルームの現在のメッセージログを表示(chat)

3. メッセージが加えられたらタイムスタンプと共にメッセージテーブルに新しい行を挿入(say)

10

2.1 HTML and SQL

¡ この例では一部が既にカプセル化¡ say関数はchat関数内でのみアクセス可

¡ 実際のWebプラットフォームで動くようにアプリをコンパイルするにはリモートで呼び出し可能な関数を公開することが必要¡ URLの使用

¡ /chat/NN (chatへのリンク)¡ /say/NN (sayへのリンク)

11

2.1 HTML and SQL

¡ Ur/WebのHTMLとSQLのエンコードにおける長所と短所1. 代数的データ型の使用

¡ プログラマにとって理解しやすい(+)¡ よりXMLスキーマの制約が強い方が良いことも(-)

2. SQLの明示的な埋め込み¡ DBに渡されるコードを正確に制御可能(+)¡ プログラマにとって面倒、ライブラリ関数の定義の重複(-) 12

2.1.1 Adding More Encapsulation

¡ 先ほどのチャットアプリにさらなるカプセル化を適用

¡ データ構造であるDBテーブルをカプセル化¡ 以前の言語設計では許可されていなかった

¡ Ur/Webのモジュールシステムを利用

13

2.1.1 Adding More Encapsulation

¡ すべてのDBアクセスをカプセル化¡ 他のプログラムモジュールからはIDがint型だということはわからない

¡ Roomの実装はほとんど図1と同じ¡ 簡単な実装を追加しただけ

¡ model-view-controller 14

2.2 Client-Side GUI Scripting

¡ チャットアプリの新しいバージョンをさらに2つ作成

¡ 変更はRoomモジュールの実装に限定¡ main関数のコードは同じものを使用

15

2.2.1 Reactive GUIs

¡ クライアント側のスクリプトを利用¡ ユーザの操作毎に完全に新しいページをロードする必要なし

¡ アプリの応答性の向上

¡ スクリプトは言語自体で実行¡ 必要に応じてJavaScriptにコンパイル

¡ 型シグネチャ(type signature)の利用 16

2.2.1 Reactive GUIs

17

2.2.1 Reactive GUIs

¡ tはHeadとTailの2つのフィールドのレコードを保有¡ HeadとTailは別の型

¡ エントリが追加されるたびにログの末尾のみをレンダリング

¡ ログ全体は再レンダリングされない

¡ renderは擬似タグ<dyn>で再帰関数render’の呼び出し18

2.2.2 Remote Procedure Call

¡ 遠隔手続き呼び出し(RPC)¡ アプリからサーバに接続し更新された情報を受信

¡ クライアント側のコードは関数への呼び出しをラップ

¡ すべてのRPCは他の呼び出しと同様にアトミックに実行

19

2.2.2 Remote Procedure Call

20

2.2.2 Remote Procedure Call

¡ ユーザが入力するテキストボックスは擬似タグ<ctextbox>

¡ ユーザがメッセージ送信のボタンをクリック

→onclick属性でRPC作成

→メッセージテキストと認識している最後のタイムスタンプを送信

→そのタイムスタンプより新しいすべてのメッセージのリストを受信

→タイムスタンプを更新 21

2.3 Message-Passing from Server to Client

¡ WebブラウザではクライアントはHTTPリクエストでサーバに接続するのが普通

¡ チャットアプリなどでは逆方向の通信が役立つ場合も

¡ クライアントが新しいメッセージを投稿したことはサーバだけが把握

¡ サーバが同じチャットルーム内のすべてのクライアントに通知

22

2.3 Message-Passing from Server to Client

¡ ロングポーリング(long polling)¡ クライアントは接続を開き、サーバの応答を任意の期間待機

¡ サーバは通知する新しいイベントが発生するまで接続をすべて開いたままに

¡ メッセージの順序の一貫性を維持するためにアトミシティが重要¡ 同時に複数のRPCがある場合

23

2.3 Message-Passing from Server to Client

24

2.3 Message-Passing from Server to Client

¡ クライアントの同期を常に維持する例

¡ 変更点¡ subscriberテーブルを追加

¡ クライアント側のタイムスタンプ追跡を削除

¡ 新しいメッセージが投稿される度に部屋のすべてのクライアントに通知

¡ Logを初期化する前にspawnで新しいスレッドを作成 25

2.3 Message-Passing from Server to Client

¡ 現在のスレッドが終了するかブロック操作がされた場合のみ別のスレッドに移行

¡ プログラムのモジュール性において相性が良い

¡ LogモジュールがRoomでのチャネルの使用を中断することはない

¡ ロングポーリングでは同時に複数の接続をアクティブにできない

26

3.1 Atomic Execution of Database Operations

¡ Ur/Webのアトミックな実行はDBのトランザクションに触発されたもの

¡ PostgreSQLはアトミックなトランザクションをサポート(9.1以降)¡ Ur/WebはPostgreSQLで使うことを推奨

¡ Ur/Webはserializationに失敗しても自動的にロールバックを実行

27

3.2 Message Routing with Channels

¡ クライアントへのメッセージ送信¡ すべての操作が完了したトランザクションのコミットポイントでアトミックに実行

¡ クライアントが接続されている場合直接送信

¡ クライアントが接続されていない場合サーバ側のバッファに追加

¡ バッファが空でないときに接続されると送信28

3.3 Implementing Functional-Reactive GUIs

¡ データソースはデータの値とDOMノードのセットとして表現¡ DOM: Document Object Model

¡ ソースが変更される度すべてのノードを再計算

¡ ノードの古いHTMLコンテンツの割り当てを解除することが必要

29

4. Evaluation

¡ 実用的なプログラミングツールとしてのUr/Webの実装の有効性¡ パフォーマンス

¡ プログラマの生産性

30

4.1 Microbenchmarks

¡ TechEmpower Web Framework Benchmarksを使用¡ 60種類のフレームワーク、70種類の構成

¡ データベースへの書き込みが多い場合あまり良くない結果

¡ トランザクションに関連して高いコストを支払うことが必要

¡ それ以外ではかなり良い結果¡ レイテンシ: 2.1ミリ秒 (1位)

¡ スループット: 約110,000リクエスト/秒 (4位)31

4.2 Deployed Applications

¡ BazQux Reader¡ 有料サブスクリプション登録者約2500人

¡ Bitparking Namecoin Exchange

¡ 同様の他サービスに比べセキュリティ面が充実

¡ Bitcoin Merge Mining Pool¡ 2013年のピーク時には世界のビットコインマイニングの10%を記録 32

4.2 Deployed Applications

33

4.2 Deployed Applications

¡ Ur/Webを採用する最大の利点¡ クライアント側のGUIをコーディングするための単純モデルであること

¡ Ur/Webに対して言及された問題点

¡ コンパイラのパフォーマンスについて

¡ エラーメッセージとコンパイラのパフォーマンスの改善34

5. Related Work

¡ MAWL: Webアプリの初期のプログラミング言語

¡ PLT Scheme Web Server: 型システムのないプラットフォーム

¡ Seaside: 強いカプセル化を保証(サーバ側のみ)

¡ Web cells: Webページの抽象化を提供

¡ Links: 強い静的チェックを行う先駆者

¡ Hop: 統合Webプログラミング言語 35

5. Related Work

¡ Ocsigen: OCamlベースのプラットフォーム

¡ Opa language: MongoDBを利用したWebアプリ用言語

¡ Capsules system: Javaで強いカプセル化

¡ Caja: JavaScriptのサブセット

¡ Flapjax: JavaScriptライブラリ

¡ Meteor: JavaScriptフレームワーク 36

5. Related Work

¡ Angular.js, Backbone, Ractive, React: 一般的なJavaScriptフレームワーク

¡ TouchDevelop: 初心者向けの最近のWeb言語設計

¡ GHC Haskell: トランザクションの抽象化を提供

37

6. Conclusion

¡ Ur/Webについて紹介¡ Webアプリのプログラミング言語

¡ カプセル化(encapsulation)と同時実行性(concurrency)

¡ 本格的なアプリケーションにも使用例あり

¡ 今後もプログラマの役に立つ言語でありたい38