Confirmed users
1,927
edits
(→Notes) |
|||
| Line 29: | Line 29: | ||
= Notes = | = Notes = | ||
== Server Architecture == | |||
For most apps, a growing consensus is that [http://webpy.org web.py] provides most required functionality for relatively simple web tools. More complex applications might benefit from a heavier framework like [http://www.djangoproject.com Django], which will not be covered here (yet). | |||
The standard described here will be client-side apps, that is, applications that have static HTML, CSS, and JS which use server-side REST APIs to update content. See [http://metamarketsgroup.com/blog/node-js-and-the-javascript-age/] for a short summary. | |||
The proposed layout is that the index file and other basic content resides at the root, with REST APIs being in a api/ directory. For example, the app 'toolfoo' might be found at http://server/toolfoo/ and its APIs at http://server/toolfoo/api/. Keeping a consistent approach will allow other applications to easily find and hook into our REST APIs should the need arise. | |||
To keep scalability in mind, static content should be hosted by the main web server (nginx) and all dynamic calls passed through WSGI, FastCGI, or another gateway to the server-side app. Example nginx config, assuming static files are in the project's html/ directory and the application is being served on port 7890 (note that the order is important, to ensure the /api/ patch is matched first): | |||
location /toolfoo/api/ { | |||
rewrite /toolfoo/api/(.*) /$1 break; | |||
proxy_pass http://127.0.0.1:7890; | |||
proxy_redirect off; | |||
proxy_set_header Host $host; | |||
proxy_set_header X-Real-IP $remote_addr; | |||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; | |||
} | |||
location ~ ^/toolfoo/(.*)$ { | |||
alias /path/to/toolfoo/html/$1; | |||
} | |||
For rapid development, we can use web.py itself with its built-in development web server to serve both the REST API and the static files. However, out of the box, web.py wants all static files in a static/ subdirectory, so we will need to hack around that. The advantage, however, of having the APIs be in a subdirectory off the application root means that everything is agnostic as to the absolute path on the server. All AJAX calls should be to the relative path "api/", so it doesn't matter if the full path is http://localhost:7890/ during development and http://server/toolfoo/ when deployed. | |||