Express の middleware を組み合わせて middleware を作る方法 - Qiita
Node.js の Express では middleware を組み合わせてアプリを作っていきます。 Express が公式リポジトリで出している middleware だけでも大量にありますね。 https://github.com/expressjs body-parser とか cookie-parser とかは使った事がある人が多いのではないでしょうか。 さて、開発規模が大きくなってくると、ライブラリ・自作含めていろいろな middleware を組み合わせることになります。 これをできるだけ簡潔に書きたいよね？というのが動機です。 問題点 var express = require("express"); // 各種ライブラリ var Amiddleware = require("A"); var Bmiddleware = require("B"); // ... var a
OWIN — Open Web Interface for .NET
About OWIN defines a standard interface between .NET web servers and web applications. The goal of the OWIN interface is to decouple server and application, encourage the development of simple modules for .NET web development, and, by being an open standard, stimulate the open source ecosystem of .NET web development tools. Getting Started These projects provide documentation and resources to help
次世代の Rack や WSGI を考えてみる - Qiita
Rack や WSGI の代わりになる仕様を考えてみました (ライブラリ (rack.rb や wsgiref.py) のほうではなく、プロトコル仕様のほうです)。自分のアイデアを書き連ねただけなので、まとまってないかもしれませんがご了承ください。 なお本稿は、今後何度か改訂すると思います。ご意見があればご自由にコメントしてください。 【対象読者】Rack や WSGI に興味のある人 【必要な知識】Rack や WSGI の基礎知識 Rack と WSGI の概要 Ruby の Rack や Python の WSGI は、HTTP のリクエストとレスポンスを抽象化した仕様です。 たとえば Rack では: 引数として、リクエストを表す Hash オブジェクトを受け取り、 戻り値として、レスポンスのステータスコードとヘッダーとボディを返します。 class RackApp def cal
KoaでWeb開発: Koaの検証を通じてミドルウェアの概念を理解する - Qiita
はじめに 動機 やっすいサーバでしかしパフォーマンスは出て、しかも大量のリクエストが来ても大丈夫なサービスを立ち上げたい。。。 そんなわがまま放題な欲求を満たすためにはやはりnode.jsで動作するアプリケーションがいいんじゃないのか、と思ったのです。 しかし、非同期とか超苦手だし・・・と思っていたところに、このKoaというフレームワークが来たわけです。 これまで、何回にもわたって、ES2015の話題を出してきたのは、ひとえにこいつを使うためでした。 ミドルウェア？ しかし、Koaの説明の中で、頻繁に「ミドルウェア」というキーワードが出てきます。 自分のこれまでの認識だと、「DB」とか「Apache」とかのを表しているのかと思いましたが、どうも違いそうだと。。。 で、検索してもミドルウェアという言葉の意味がわかっている前提で述べられているものばかり。。。 こいつを自分の中で理解できないかぎ
Express + Node.jsで基本を理解した次の一歩 - ディレクトリ構成をルーティング・ミドルウェアを理解して考えてみる - Qiita
Express + Node.jsで基本を理解した次の一歩 - ディレクトリ構成をルーティング・ミドルウェアを理解して考えてみるNode.jsExpress Expressを利用したアプリはその構成要素をサーバーサイドの処理、3rd Partyのライブラリ群、UIを構成するテンプレート、静的ファイルなど幾つかの種類にコンポーネントを分類できます。 これらを見通しよく、容易に拡張できるような構成にするためには整頓されたディレクトリ構成を組むことが重要で、多くの人がこのベストプラクティスについて思い悩んでいるのではないかと思います。今回はこのディレクトリ構成のベストプラクティス、というより、どのようなパターンでも共通する基本の考え方についてまとめてみようと思います。 様々な議論があるところですが、共通して言えるのは自分で一から考えるよりも、なんらかのジェネレーターが生成する構成をベースにすべき
README – Plug v1.0.3
Plug is: A specification for composable modules between web applications Connection adapters for different web servers in the Erlang VM Documentation for Plug is available online . Hello world defmodule MyPlug do import Plug.Conn def init(options) do # initialize options options end def call(conn, _opts) do conn |> put_resp_content_type("text/plain") |> send_resp(200, "Hello world") end end The sn
Koa(1.x)のmiddlewareの仕組みを調べた - Qiita
この記事は Node.js Advent Calendar 2015 9日目の記事です。(大遅刻) 注意 この記事で扱うのはKoaのv1.1.2です。なお、今後のバージョンアップで書き方やAPI、そしてコードが大きく変わる可能性があるのでご注意ください。現時点でv2.xはアルファ版ですが、coがサポートされないようになり手動で追加する必要がある、などの違いがあります。 Koaとは Expressive middleware for node.js using generators WebアプリのサーバーサイドがES6 Generatorを使っていい感じに書けるという話ですね。 特徴 リポジトリのREADMEよりサンプルコードを引用 簡潔に書ける 簡潔に書けます。 var koa = require('koa'); var app = koa(); // logger app.use(fun
ミドルウェアを使ってビューの探索パスを変更する - Qiita
Laravel5のインストール直後に設置されているビューを見たところ、もともとレスポンシブな感じではあるけど、PCとモバイルで表示要素が大きく違う画面はビューファイルが同じだとツライわ−ってことがあると思うんです。 なので、ミドルウェアを使ってビューファイルの探索パスを変更する方法を調べてみました。 パッケージのインストール ググると、なんだか良さげなパッケージがあったのでこれを使いたいと思います。 https://github.com/jenssegers/Laravel-Agent READMEに従ってcomposerでインストールした後、config/app.phpの'providers'と'aliases'に追記します。
Laravel5のミドルウェアの使い方 - Qiita
Laravel5のミドルウェアについてちょっと調べてみました。 http://readouble.com/laravel/5/0/0/ja/middleware.html 例えば、職場の偉い人が「WEBサイトの訪問者に挨拶したい」とか言ってきたとします。 要件としては大体こんな感じです。 WEBサイト上のすべての画面で挨拶したい。 ちなみに時間帯によって挨拶の文言を変えたい。 ミドルウェアはこういう「常に何かやりたい」ってケースで使えば良さそうです。 それでは、上記要件を満たすミドルウェアを作ってみます。 ミドルウェアの作成 まず、artisanコマンドでミドルウェアを作成します。 <?php namespace App\Http\Middleware; use Closure; use Config; use Illuminate\Contracts\View\Factory as Vi
Message-oriented middleware - Wikipedia
This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages) This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Message-oriented middleware" – news · newspapers
Cowboy 現代のWeb - ハードリカーエンジニア
Webの始まりから今日までのさまざまなWeb技術を見てみることによって、次に何がくるのかの予測を得てみましょう Cowboyは、この記事を書いている時点で仕様として実現例のないHTTP/2.0以外のすべてのテクノロジーと互換性を持っています。 先史時代のWeb HTTPは最初はHTMLページを提供するためだけに作成され、HTMLページを取得するためのGETメソッドのみを持っていました。 この最初のバージョンは文書化され、HTTP/0.9と呼ばれています。 HTTP/1.0はGET、HEAD、POSTメソッドを定義し、POSTリクエストを使用してデータを送信することができました。 HTTP1.0は非常に簡単な方法で実装されたものです TCP接続が最初にサーバと確立されます。 次に要求が送信されます。 そしてサーバは応答を送り返し、接続を終えます。 こういえば十分ですが、HTTP1.0はあまり
Cowboy の User Guide 目次 - ハードリカーエンジニア
ElixirにてWebアプリケーションを開発しようとするとCowboyにたどり着くことになります。 そこでCowboyのユーザガイドを翻訳することによって、これからCowboyを使用される方がつまづくことないようにと思い、翻訳を行いたいと思います。 翻訳許可をくださり、また掲載許可もくださった Nine Nines社とLoic Hoguin様ありがとうございました。 翻訳ですが素人翻訳ですので間違いが多々あるかもしれません。 解説が間違っていた場合には、コメントか@hayabusa333にご連絡くださると嬉しいです。 翻訳元のドキュメントは以下となります。 Cowboy User Guide Cowboy ユーザガイド Cowboyユーザガイドは現代のWeb技術とWebアプリケーションを記述するためにCowboyを最大限に活用するための地図です。 Cowboy紹介 はじめに 現代のWeb
Cowboy はじめに - ハードリカーエンジニア
はじめに CowboyはErlangで書かれた小さな高速モジュラーHTTPサーバです。 CowboyはSPDY、Websocket、RESTやそれらから派生した通信形式を含む完全なHTTPスタックを提供することを目的としています。 Cowboyは現在、HTTP/1.0、HTTP/1.1、Websocket(全ての実装とドラフト+標準)、WebmachineベースのRESTをサポートしています。 Cowboyは高品質なプロジェクトです。 Cowboyは小さなコードベースであり、非常に効率的で(遅延およびメモリ使用量の両方において)、簡単に他のアプリケーションに埋め込むことができます。 Cowboyは綺麗なErlangのコードです。 Cowboyは数百のテストをパスしており、そのコードはダイアライザーに完全に準拠しています。 また十分に文書化され、関数のリファレンスとユーザガイドの両方を備えて
Koa用のミドルウェアをwebsocketにも対応させたい - Qiita
はじめに koaはp-baleine@githubさんの記事やLightSpeedCさんの記事で魅力を感じて触っています。 でもnode.jsといえばやっぱりsocket.ioを使った双方向通信ですね。 どうやって実現するか。 そこでググってみるとtakyamさんのブログにドンピシャな投稿がありました。 さっそくtakayamさんのコードを拝見すると、やっぱりsocket.ioの部分はごちゃごちゃしてしまうのは仕方がなさそうですね。 せっかくkoaのhttpのミドルウェア部分はすっきりしているのにと。。。 そこで今回はsocket.io部分もミドルウェアっぽく記述出来るモジュールを作成しました。 公開しているので試してみてください。 npmを使う場合はnpm install cocotte-mixin-wsです。 Koaのミドルウェア とっても単純に記述するとhttp部分のミドルェアは次の
Using Express middleware
Using middleware Express is a routing and middleware web framework that has minimal functionality of its own: An Express application is essentially a series of middleware function calls. Middleware functions are functions that have access to the request object (req), the response object (res), and the next middleware function in the application’s request-response cycle. The next middleware functio
Migrating Express.js 3.x to 4.x: Middleware, Route and Other Changes – webapplog [tech blog]
webapplog [tech blog] Book author Azat Mardan writes about apps, startups and technology Express.js 4 is the latest (as of May 2014) version of the most popular mature and robust Node.js framework for web apps, services and APIs. There are some breaking changes going from 3.x to 4.x, so here’s a brief migration guide: Replacing Unbundled Middleware in Express.js 4 Removing Deprecated Methods from
ExpressのMiddlewareを自作してみる - Qiita
http://expressjs.com/guide/using-middleware.html expressのmiddlewareに興味がわいたので自作してみます。ですのでまず上記サイトを読むことにしました。 結論 app.use(function (req, res, next) {}) もしくは app.use router か app.use routers 以下は上記サイトを自分なりに解釈した駄文になります。 Middlewareとは request, response, next を受け取るfunction どんなコードでもいい requestとresponseを変更してよい リクエストを終了してもいい nextを呼びリクエストを続行してもいい リクエストを終了しない場合はnextを必ず呼ぶこと オプションでmiddlewareの対象となるパスを指定できる アプリケーションレ
逆引きメモ：expressの使い方 - Qiita
expressの使い方を逆引き形式でまとめてみた。参考にしたのは2014年2月20日時点（express 3.4.8時点）の公式ドキュメントおよびソースコード、サンプルなど。 公式ドキュメント ソースコード サンプル ルーティングを設定する ルーティングを設定するには（i.e. パスとコントローラ関数をマッピングするには）app.get(path, func)やapp.post(path, func)など各HTTP Verbに対応した関数を使う ルーティング設定は書かれた順番に評価され、リクエストとpathの一致したものが適用される pathは文字列または正規表現を指定可能 funcのシグネチャはfunction(req, res[, next]) nextはコールバック関数 引数無しnext()で呼び出すと、次に一致するルーティング設定に処理が移る 引数有りnext(object)で呼び
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Yoke micro-framework
GitHub - expressjs/multer: Node.js middleware for handling `multipart/form-data`.
