Routing requests in Autodafé

Autodafé - node.js framework, start to read in this article: habrahabr.ru/blogs/nodejs/135089

The main part of the article will be devoted to the redirection of requests to autodafe, the formation of URLs, etc. But first, I would like to highlight the general principles of the application with connected clients, in order to make it clearer which part of the workflow we will discuss.

Where does the dust come from

Let's start with a diagram showing the connection of clients to the application:
')


On the diagram you can see several users who use different devices and different browsers, which in turn connect to the application using different protocols. (At the moment, you can only connect to autodafe via http and websockets)

In the application, each connection corresponds to one Client. Client is created for each http request and websockets connection. Clients with the same session ID belong to the same Session instance. Usually one session per application corresponds to one browser.

Well, for logical completion, the “users” component is shown in the diagram, which allows you to bind different sessions that have passed special authorization to one UserIdentity object. Thus, in an application, each UserIdentity object is associated with one real user.

Where does the money go

So we come to the topic of this article: writing routing. Each Client, upon receiving a request, forms it in a special form and sends it to Router. And he, in turn, using the routing table (Route map in the diagram) redirects the request to the desired action of the desired controller.

Thus: each request for any protocol is redirected using the table described in one place

Routing table

In the routing table you can specify:

• by itself, redirecting requests to the action of a specific controller
• parameters for human-readable URLs
• methods and protocols for which these actions are available
• redirection depending on the host from which the request came, to which port it came, etc.

The routing table serves not only to parse the incoming request, but also to form a URL on the server, which allows you to flexibly change the appearance of the URL, making edits in one place.

Controllers are ordinary classes. Actions are methods. No query will work if it is not listed in the routing table. In this way, non-action methods of the controller are protected from being invoked.

For the following examples, you can take the Hello World application described in this article. Now there is only one rule in the router.rules section of the configuration file:

router : { rules : { '' : 'site.index' } } 

The keys of the rules section correspond to the part of the url of the address that comes after the host name and to the request parameters, so for the url of the address www.example.com/messages/unread?user_id=5 this part is equal to messages / unread.

Values ​​rules - this is the path to the action that must be performed for this request in the form of 'controller. Action'

 router : { rules : { '' : 'site.index', 'messages/unread' : 'dialogs.show_unread_messages' } } 

Creating a URL

In the controller code, to create the required URL, use the create_url method:

 this.create_url( 'dialogs.show_unread_messages' ); //  '/messages/unread' 

Often, links should be inserted into the view; dust is now used as a templating engine; a special function url is written for it:

 <a href="{#url}dialogs.show_unread_messages{/url}"> </a> 

Parameter passing

Creating a link inside the controller:

 this.create_url( 'dialogs.show_unread_messages', { user_id : 5 } ); //  '/messages/unread?user_id=5' 

In the view:

 <a href='{#url user_id="5"}dialogs.show_unread_messages{/url}'> </a> 

Putting parameters in the way

The bottom line: convert / messages / unread? User_id = 5 to / messages / unread / user / 5

Rules section:

 rules : { '/messages/unread/user/<user_id:\\d+>' : 'dialogs.dialogs.show_unread_messages' } 

As you can see, we simply define the name of the parameter and the regular expression to which it should match. Neither the controller nor the view changes should be done.

Filter requests

Some actions need to be performed, for example, only if they came through a POST request or via WebSockets. This can be specified directly in the table.

 rules : { //       POST 'update_message' : 'dialogs.update_message | post' } 

Instead of post, there can be get, delete, and ws. The latter restricts the call only to actions received via WebSockets

Methods can be grouped by comma:

 rules : { //       POST 'delete_message' : 'dialogs.delete_message | post, delete' } 

Spaces are not taken into account, so you can easily align everything into a beautiful view.

Filter queries by domain name and port

 rules : { 'hostname:m.domain.com port:3000 /' : 'mobile.index' } 

In more detail, this topic will be disclosed in the upcoming documentation site.

Thanks for attention.

PS:

Github source code: autodafe
Follow the framework on twitter @node_autodafe

If you want to take part in the development or in any way to help in the development of the framework - write in a personal or jifeon at gmail.com