禁欲的なWeb：GoとJSのプロトタイプフリーマーケット

みなさん、こんにちは。最新のWebアプリケーションの可能性についての私の考えの結果を共有したいと思います。 例として、コミック用の掲示板の設計を検討してください。 ある意味では、問題の製品は、オタクとシンパサイザーの聴衆向けに設計されており、インターフェイスで自由を示すことができます。 それどころか、技術コンポーネントでは、細部への注意が必要です。

実際、漫画では何もわかりませんが、フリーマーケット、特にゼロで人気のあったフォーラム形式は大好きです。 したがって、次の結論が流れる仮定（おそらく誤り）は1つにすぎません。アプリケーションとの対話の主なタイプは表示であり、2番目のタイプはアナウンスとディスカッションの投稿です。

私たちの目標は、シンプルなアプリケーションを作成することです。 技術的ノウハウ ただし、現代の現実と一致する余分なホイッスル。 私が達成したい主な要件は次のとおりです。

1. サーバー側：

   
   
   
   
   
   
   

   a）クライアントへのユーザーデータの保存、検証、送信の機能を実行する
   
   b）上記の操作は、許容量のリソース（時間を含む）を消費します
   
   c）アプリケーションとデータが一般的な攻撃ベクトルから保護されている
   
   d）サードパーティのクライアントとサーバー間対話のためのシンプルなAPI
   
   e）クロスプラットフォームで簡単な展開

   
   
   
   
   
   
   

2. クライアント側：

   
   
   
   
   
   
   

   a）コンテンツの作成と使用に必要な機能を提供します
   
   b）インターフェイスは、通常の使用、アクションへの最小パス、画面ごとの最大データ量に便利です。
   
   c）サーバーとの通信外で、この状況ですべての可能な機能が利用可能
   
   d）インターフェイスは、再起動して待機することなく、状態とコンテンツの現在のバージョンを表示します
   
   d）アプリケーションを再起動しても、その状態には影響しません
   
   f）可能であれば、DOM要素とJSコードを再利用します
   
   g）実行時にサードパーティのライブラリとフレームワークを使用しません
   
   h）レイアウトは、アクセシビリティ、パーサーなどのセマンティックです。
   
   i）メインコンテンツのナビゲーションには、URLとキーボードを使用してアクセスできます

   
   
   
   
   
   
   

私の意見では、論理的な要件、および最新のアプリケーションは、ある程度これらの条件を満たしています。 私たちに何が起こるか見てみましょう（投稿の最後にあるソースとデモへのリンク）。

サーバー

サーバーの言語はgolangです。 優れた標準ライブラリとドキュメントを備えたシンプルで高速な言語...少し面倒です。 最初の選択はエリキシル/アーランにかかっていましたが、私は（比較的）ゴーを知っていたので、それを複雑にしないことに決めました（そして必要なパッケージはゴーのためだけでした）。

go-communityでのWebフレームワークの使用は推奨されません（ 当然 、認める価値があります）。妥協案を選択してlabstack / echoマイクロフレームワークを使用することで、ルーチンの量を減らし、パフォーマンスがあまり低下しないように思えます。

データベースとしてtidwall / buntdbを使用します。 第一に、組み込みソリューションはより便利でオーバーヘッドのコストを削減し、第二に、インメモリ+キー/値- おしゃれでスタイリッシュ 高速でキャッシュ不要。 JSONでデータを保存および提供し、変更時にのみ検証します。

第2世代のi3では、組み込みロガーは0.5〜10ミリ秒のさまざまな要求の実行時間を表示します。 同じマシンでwrkを実行しても、目的には十分な結果が得られます。

➜ comico git:(master) wrk -t2 -c500 -d60s http://localhost:9001/pub/mtimes Running 1m test @ http://localhost:9001/pub/mtimes 2 threads and 500 connections Thread Stats Avg Stdev Max +/- Stdev Latency 20.74ms 16.68ms 236.16ms 72.69% Req/Sec 13.19k 627.43 15.62k 73.58% 1575522 requests in 1.00m, 449.26MB read Requests/sec: 26231.85 Transfer/sec: 7.48MB
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 ➜ comico git:(master) wrk -t2 -c500 -d60s http://localhost:9001/pub/goods Running 1m test @ http://localhost:9001/pub/goods 2 threads and 500 connections Thread Stats Avg Stdev Max +/- Stdev Latency 61.79ms 65.96ms 643.73ms 86.48% Req/Sec 5.26k 705.24 7.88k 70.31% 628215 requests in 1.00m, 8.44GB read Requests/sec: 10454.44 Transfer/sec: 143.89MB
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロジェクト構造

comico / modelパッケージは3つのファイルに分かれています。

model.go-データ型と一般的な機能の説明が含まれます。作成/更新（buntdbはこれらの操作を区別せず、レコードの存在を手動で確認します）、検証、削除、1つのレコードの取得、リストの取得。

rules.go-特定のタイプおよびロギング機能の検証ルールが含まれています。

files.go-画像を操作します。

Mtimesタイプは、データベース内の残りのタイプの最後の変更に関するデータを格納し、どのデータが変更されたかをクライアントに伝えます。

comico / bdパッケージには、データベースとやり取りするための一般化された関数が含まれています：作成、削除、選択など。Buntdbは、ファイルへのすべての変更をテキスト形式で保存します（この場合、1秒に1回）。 dbファイルは編集されず、トランザクションが成功した場合の変更が最後に追加されます。 データの整合性に違反する私の試みはすべて失敗しました。最悪の場合、最後の1秒の変更は失われます。

実装では、各タイプは個別のファイル内の個別のデータベースに対応します（メモリに排他的に保存され、再起動時にゼロにリセットされるログを除く）。 これは主に、バックアップと管理の便利さ、小さなプラス-1つのタイプのデータのみへのブロックアクセスを編集するためのオープントランザクションによるものです。

このパッケージは、たとえばSQLなどの別のデータベースを使用して、同様のパッケージに簡単に置き換えることができます。 これを行うには、次の機能を実装するだけで十分です。

 func Delete(db byte, key string) error func Exist(db byte, key string) bool func Insert(db byte, key, val string) error func ReadAll(db byte, pattern string) (str string, err error) func ReadOne(db byte, key string) (str string, err error) func Renew(db byte, key string) (err error, newId string)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

comico / cnstパッケージには、すべてのパッケージに必要な定数（データ型、アクション型、ユーザー型）が含まれています。 さらに、このパッケージには、サーバーが外部の世界に応答するための人間が読めるすべてのメッセージが含まれています。

comico / serverパッケージにはルーティング情報が含まれています。 また、数行（Echo開発者のおかげ）、JWTを使用した承認、CORS、CSPヘッダー、ロガー、静的配布、gzip、ACME自動証明書などが構成されています。

APIエントリポイント

URL	データ	説明
get / pub /（商品|投稿|ユーザー| cmnts |ファイル）	-	関連するお知らせ、投稿、ユーザー、コメント、ファイルの配列を取得する
get / pub / mtimes	-	各データ型の最終変更時刻を取得する
投稿/パブ/ログイン	{id *：ログイン、pass *：パスワード}	JWTトークンとその期間を返します
投稿/パブ/パス	{id *、pass *}	データが正しい場合、新しいユーザーを作成します
put / api / pass	{id *、pass *}	パスワード更新
投稿| put / api / goods	{id *、auth *、title *、type *、price *、text *、images：[]、Table：{key：value}}	広告を作成/更新
投稿| put / api / posts	{id *、auth *、title *、type *、text *}	フォーラム投稿の作成/更新
投稿| put / api / users	{id *、タイトル、タイプ、ステータス、スクライブ：[]、無視：[]、テーブル：{キー：値}}	ユーザーの作成/更新
投稿/ API / cmnts	{id *、auth *、owner *、type *、to、text *}	コメント作成
delete / api /（商品|投稿|ユーザー| cmnts）/ [id]	-	IDを持つエントリを削除します
get / api / activity	-	現在のユーザーの受信コメントの最終読み取り時間を更新します
get / api /（購読|無視）/ [タグ]	-	サブスクリプションのリストにユーザータグを追加または削除します（存在する場合）/無視
投稿/ API /アップロード/（商品|ユーザー）	マルチパート（名前、ファイル）	写真広告/ユーザーアバターをアップロードします

*-必須フィールド

api-認証が必要、pub-いいえ

上記と一致しないget要求では、サーバーはディレクトリ内のファイルを静的に検索します（たとえば、/ img / *-images、/ index.html-client）。

すべてのAPIポイントは、成功した場合は200の応答コード、エラーが発生した場合は400または404、必要な場合は短いメッセージを返します。

アクセス権は簡単です。エントリの作成は承認されたユーザーが利用でき、作成者とモデレーターは編集でき、管理者はモデレーターを編集して任命できます。

APIには最も単純なアンチバンダルが装備されています：アクションはユーザーIDとIPとともに記録され、頻繁にアクセスする場合は、少し待つように求めるエラーが返されます（パスワードの推測に役立ちます）。

お客様

リアクティブWeb'aのコンセプトが好きです。最新のサイト/アプリケーションのほとんどは、このコンセプトのフレームワーク内で、または完全に静的に行われるべきだと思います。 一方、メガバイトのJSコードを使用した単純なサイトは意気消沈するしかありません。 私の意見では、この（そしてそれだけではない）問題はSvelteによって解決できる。 このフレームワーク（またはリアクティブインターフェイスを構築するための言語）は、必要な機能においてVueに劣りませんが、否定できない利点があります-コンポーネントはバニラJSにコンパイルされ、バンドルのサイズと仮想マシン（bundle.min.js.gz）の負荷の両方を削減しますフリーマーケットは控えめで、今日の基準では24KBです）。 詳細は公式文書に記載されています 。

フリーマーケットのクライアントパートとしてSvelteJSフリーマーケットを選択します。リッチハリスとプロジェクトのさらなる発展に最善を尽くします。

PS私は誰かを怒らせたくない。 各スペシャリストと各プロジェクトには独自のツールがあると確信しています。

顧客/データ

URL

ナビゲーションに使用します。 複数ページのドキュメントをシミュレートするのではなく、代わりに、クエリパラメータでハッシュページを使用します。 遷移の場合、jsなしで通常の<a>を使用できます。

セクションはデータタイプに対応します： /＃goods 、 /＃posts 、 /＃users 。

パラメーター：？Id = record_id 、？Page = page_number 、？Search = search_query 。

いくつかの例：

• /＃posts？id = 1542309643＆page = 999＆search = {auth：anon} - 投稿セクション、投稿id- 1542309643 、コメントページ-999 、検索クエリ- {auth：anon}
• /＃goods？page = 2＆search = siddhartha-セクションgoods 、セクションpage- 2 、検索クエリ-siddhartha
• /＃goods？search = wer {key：value} t-セクションgoods 、検索クエリ-広告のヘッダーまたはテキストのワート部分文字列と、広告の表部分のキープロパティの部分文字列値の検索で構成されます
• /＃goods？search = {model：100、display：256} -ここでは類推によってすべてが明確になっていると思います

実装における解析とURL生成の機能は次のようになります。

 window.addEventListener('hashchange', function() { const hash = location.hash.slice(1).split('?'), result = {} if (!!hash[1]) hash[1].split('&').forEach(str => { str = str.split('=') if (!!str[0] && !!str[1]) result[decodeURI(str[0]).toLowerCase()] = decodeURI(str[1]).toLowerCase() }) result.type = hash[0] || 'goods' store.set({ hash: result }) }) function goto({ type, id, page, search }) { const { hash } = store.get(), args = arguments[0], query = [] new Array('id', 'page', 'search').forEach(key => { const value = args[key] !== undefined ? args[key] : hash[key] || null if (value !== null) query.push(key + '=' + value) }) location.hash = (type || hash.type || 'goods') + (!!query.length ? '?' + query.join('&') : '') }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

API

サーバーとデータを交換するには、フェッチAPIを使用します。 更新されたレコードを短い間隔でダウンロードするには、 / pub / mtimesにリクエストを行います。いずれかのタイプの最終変更時刻がローカルのものと異なる場合、このタイプのリストをロードします。 はい、SSEまたはWebSocketsを介した更新の通知と増分ロードを実装することができましたが、この場合は通知なしで実行できます。 私たちは何を得ました：

 async function GET(type) { const response = await fetch(location.origin + '/pub/' + type) .catch(() => ({ ok: false })) if (type === 'mtimes') store.set({ online: response.ok }) return response.ok ? await response.json() : [] } async function checkUpdate(type, mtimes, updates = {}) { const local = store.get()._mtimes, net = mtimes || await GET('mtimes') if (!net[type] || local[type] === net[type]) return const value = updates['_' + type] = await GET(type) local[type] = net[type]; updates._mtimes = local if (!!value && !!value.sort) store.set(updates) } async function checkUpdates() { setTimeout(() => checkUpdates(), 30000) const mtimes = await store.GET('mtimes') new Array('users', 'goods', 'posts', 'cmnts', 'files') .forEach(type => checkUpdate(type, mtimes)) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フィルタリングとページネーションには、ナビゲーションデータに基づいて計算されたSvelteプロパティを使用します。 計算された値の方向は次のとおりです： items （サーバーからのレコードの配列）=> ignoreItems （現在のユーザーの無視リストに基づいてフィルターされたレコード）=> scribedItems （このモードが有効になっている場合、サブスクリプションのリストによってレコードをフィルターします）=> curItemおよびcurItems （現在のレコードを計算します）セクションに応じて）=> filtersItems （検索クエリに応じてレコードをフィルタリングします。レコードが1つしかない場合-コメントをフィルタリングします）=> maxPage （ページあたり12レコード/コメントに基づいてページ数を計算します）=> pagedItem （最終配列を返します 現在のページ番号に基づいた投稿/コメント）。

コメントと画像（ commentsと_images ）は個別に計算され、タイプと所有者レコードごとにグループ化されます。

計算は自動的に行われ、関連するデータが変更された場合にのみ、中間データは常にメモリ内にあります。 これに関して、不愉快な結論を出します-大量の情報および/または頻繁な更新のために、大量のリソースを費やすことができます。

キャッシュ

オフラインアプリケーションを作成するという決定に従って、レコードの保存とlocalStorageの状態のいくつかの側面、CacheStorageのイメージファイルを実装します。 localStorageの操作は非常に簡単です。「_」プレフィックスを持つプロパティは、変更時に再起動時に自動的に保存および復元されることに同意します。 次に、ソリューションは次のようになります。

 store.on('state', ({ changed, current }) => { Object.keys(changed).forEach(prop => { if (!prop.indexOf('_')) localStorage.setItem(prop, JSON.stringify(current[prop])) }) }) function loadState(state = {}) { for (let i = 0; i < localStorage.length; i++) { const prop = localStorage.key(i) const value = JSON.parse(localStorage.getItem(prop) || 'null') if (!!value && !prop.indexOf('_')) state[prop] = value } store.set(state) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ファイルはもう少し複雑です。 まず、サーバーから送られてくるすべての実際のファイルのリスト（作成時間を含む）を使用します。 このリストを更新するとき、古い値と比較し、新しいファイルをCacheStorageに入れ、そこから古いファイルを削除します。

 async function cacheImages(newFiles) { const oldFiles = JSON.parse(localStorage.getItem('_files') || '[]') const cache = await caches.open('comico') oldFiles.forEach(file => { if (!~newFiles.indexOf(file)) { const [ id, type ] = file.split(':') cache.delete(`/img/${type}_${id}_sm.jpg`) }}) newFiles.forEach(file => { if (!~oldFiles.indexOf(file)) { const [ id, type ] = file.split(':'), src = `/img/${type}_${id}_sm.jpg` cache.add(new Request(src, { cache: 'no-cache' })) }}) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、サーバーに接続せずにファイルがCacheStorageから取得されるように、フェッチの動作を再定義する必要があります。 これを行うには、ServiceWorkerを使用する必要があります。 同時に、他のファイルがキャッシュされるように設定して、サーバーとの通信以外で機能するようにします。

 const CACHE = 'comico', FILES = [ '/', '/bundle.css', '/bundle.js' ] self.addEventListener('install', (e) => { e.waitUntil(caches.open(CACHE).then(cache => cache.addAll(FILES)) .then(() => self.skipWaiting())) }) self.addEventListener('fetch', (e) => { const r = e.request if (r.method !== 'GET' || !!~r.url.indexOf('/pub/') || !!~r.url.indexOf('/api/')) return if (!!~r.url.lastIndexOf('_sm.jpg') && e.request.cache !== 'no-cache') return e.respondWith(fromCache(r)) e.respondWith(toCache(r)) }) async function fromCache(request) { return await (await caches.open(CACHE)).match(request) || new Response(null, { status: 404 }) } async function toCache(request) { const response = await fetch(request).catch(() => fromCache(request)) if (!!response && response.ok) (await caches.open(CACHE)).put(request, response.clone()) return response }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それは少し不器用に見えますが、その機能を実行します。

クライアント/インターフェース

コンポーネント構造：

index.html | main.js

== header.html-ロゴ、ステータスバー、メインメニュー、下部ナビゲーションメニュー、コメント送信フォームが含まれています

== aside.html-すべてのモーダルコンポーネントのコンテナです

==== goodForm.html-広告を追加および編集するためのフォーム

==== userForm.html-現在のユーザーのフォームを編集

====== tableForm.html-表形式のデータを入力するためのフォームのフラグメント

==== postForm.html-フォーラム投稿のフォーム

==== login.html-ログイン/登録フォーム

==== activity.html-現在のユーザー宛のコメントを表示します

==== goodImage.html-メインおよび追加の写真広告を表示

== main.html-メインコンテンツのコンテナ

==== goods.html-リストまたは単一の発表カード

==== users.html-ユーザーも同じ

==== posts.html-明らかだと思う

==== cmnts.html-現在の投稿に対するコメントのリスト

====== cmntsPager.html-コメントのページネーション

• 各コンポーネントでは、htmlタグの数を最小限に抑えます。
• クラスは状態のインジケータとしてのみ使用します。
• ストアと同様の関数を使用します（svelteストアのプロパティとメソッドは、接頭辞「$」をコンポーネントに追加することにより、コンポーネントから直接使用できます）。
• ほとんどの関数は、ユーザーイベントまたは特定のプロパティの変更を予期し、状態データを操作し、作業結果を状態に保存して終了します。 したがって、コードの小さな一貫性と拡張性が実現されます。
• トランジションと他のUIイベントの見かけの速度については、可能な限り、バックグラウンドで発生するデータと、現在の計算結果を使用するインターフェイスに関連付けられたアクションでの操作を分離し、必要に応じて再構築し、残りはフレームワークによって親切に実行されます。
• 入力するフォームのデータは、入力を失うことを防ぐために、入力ごとにlocalStorageに保存されます。
• すべてのコンポーネントで、不変モードを使用します。このモードでは、フィールドの変更に関係なく、新しいリンクが受信された場合にのみプロパティオブジェクトが変更されたと見なされます。したがって、コード量がわずかに増加するにもかかわらず、アプリケーションを少し高速化します。

顧客/管理

キーボードを使用して制御するには、次の組み合わせを使用します。

Alt + s / Alt + a-レコードのページを前後に切り替えます。1つのレコードがコメントのページを切り替えます。

Alt + w / Alt + q-次/前のレコード（存在する場合）に移動し、リストモード、単一レコードおよび画像ビューで動作します

Alt + x / Alt + z-ページを上下にスクロールします。 画像表示モードでは、画像を周期的に前後に切り替えます

エスケープ -開いている場合はモーダルウィンドウを閉じ、単一のエントリが開いている場合はリストに戻り、リストモードで検索クエリをキャンセルします

Alt + c-現在のモードに応じて、検索またはコメントフィールドにフォーカスします

Alt + v-単一の広告の写真表示モードを有効/無効にします

Alt + r-承認されたユーザーの受信コメントのリストを開く/閉じる

Alt + t-明るいテーマと暗いテーマを切り替えます

Alt + g-広告のリスト

Alt + u-ユーザー

Alt + P-フォーラム

多くのブラウザでは、これらの組み合わせがブラウザ自体によって使用されていることを知っていますが、私のクロムでは、もっと便利なものを思い付くことができませんでした。 私はあなたの提案に喜んでいるでしょう。

キーボードに加えて、もちろんブラウザコンソールを使用できます。 たとえば、 store.goBack（） 、 store.nextPage（） 、 store.prevPage（） 、 store.nextItem（） 、 store.prevItem（） 、 store.search（stringValue） 、 store.checkUpdate（ 'goods' || 'ユーザー '||'投稿 '||'ファイル '||' cmnts '） -名前が意味することを行います。 store.get（）。commentsおよびstore.get（）._ images-グループ化されたファイルとコメントを返します。 store.get（）.ignoredItemsおよびstore.get（）。scribedItemsは、無視して追跡するレコードのリストです。 すべての中間データおよび計算データの完全なリストは、 store.get（）から入手できます。 誰もこれを真剣に必要とする人はいないと思いますが、たとえば、ユーザーごとにエントリをフィルタリングし、コンソールから削除すると非常に便利なように思えます。

おわりに

ここで、プロジェクトの知り合いを終了できます;ソースコードで詳細を確認できます。 その結果、ほとんどのバリデータ、セキュリティ、速度、可用性などのチェッカーで、かなり高速でコンパクトなアプリケーションが得られました。ターゲットを絞った最適化なしで良い結果を示しています。

プロトタイプで使用されるアプリケーションを編成するアプローチがどの程度正当化されるか、落とし穴は何か、根本的に異なる方法で何を実装するのか、コミュニティの意見を知りたいと思います。

ソースコード、サンプルのインストール手順、およびデモはこちら （どうぞ 破壊する 刑法の枠組みでテストするため）。

追記。 結論としては少し商業的です。 そのようなレベルで、お金のためにプログラミングを始めることは本当に可能ですか？ そうでない場合、まず第一に何を探すべきか、もしそうなら、彼らは今、似たようなスタックで面白い作品を探している場所を教えてください。 ありがとう

追記。 お金と仕事についてもう少し。 このアイデアはいかがですか：給与について興味深いプロジェクトに取り組む準備ができていると仮定しますが、支払いが市場を大幅に下回っている場合、雇用主の競争相手であるタスクとその支払いに関するデータは公開されます（可用性とパフォーマンスの品質を評価するためのコードが望ましい）より高い場合、タスクを実行するために多くのお金を提供することができます-多くのパフォーマーは、低価格でサービスを提供することができます。 状況によっては、このようなスキームは、市場（IT）をより最適かつ公正にバランスさせるのでしょうか？