The Golf Web Application Server home roadmap1.0 help rss

Overview

25 Dec 2009 - Micha Niskin

Golf is a web application server. It provides a way to build and deploy JavaScript driven webapps without sacrificing accessibility to JavaScript-disabled browsers (search engines, for example). By making dynamic content and behaviors fully accessible, Golf apps are designed from the ground up as clientside applications. As such, they are able to take full advantage of a powerful, rich JavaScript runtime environment. Golf both simplifies and adds power to the process of writing apps for the web.

JavaScript Proxying

The main thing that makes the Golf server different is what we call JavaScript Proxying. This capability allows you to write dynamic clientside applications that make heavy use of JavaScript (in the client—specifically not serverside JavaScript), but are still completely accessible to clients that do not have JavaScript (or don’t have it enabled). The Golf server transparently proxies requests from non-JS clients, rendering the page on the server in an embedded browser environment, and returning pure HTML and CSS to the client. We call it proxying because the JavaScript virtual machine actually exists in this simulated browser on the server and acts as a proxy, accepting events from the client and rendering the page for them. Proxy mode has support for most events, such as onclick, onsubmit, AJAX XHR, etc. There is no special code for you to write, and the proxying is done transparently.

With Javascript Proxying your app is a full clientside affair. No sessions to recreate the app’s state for each request. No serverside form handling. No agonizing over graceful degradation. No reloading the page—ever. It just automatically works.

Golf Application Framework Features

Golf provides a rich framework in which to devlop complex applications. The Golf clientside runtime environment was designed to simplify the app development process and be a robust, efficient architecture for creating apps from modular, encapsulated components. This allows you to divide work more easily between graphic designers, HTML/CSS designers, JavaScript frontend programmers, backend service programmers, and application architects. Because it is a modular system, many of these tasks can be done in parallel without the need for complex synchronization between the different areas.

The Golf framework provides:

Golf Server Features

Additionally, the Golf server has a number of features designed to make developing and deploying your apps easier. External dependencies are avoided. Configuration is kept to a minimum—it’s done in a simple way where necessary, and always with reasonable defaults. You will not find a single XML file anywhere near a Golf app. The Golf server will work well right out of the box, but can be optimized for production easily.

Specifically, the Golf server provides the following features:

Backend Persistence Options

The Golf server provides a framework in which to write powerful clientside apps. However, Golf is not a serverside programming framework. At this time there is no integrated persistence layer in Golf. However, Golf apps would naturally work well with some kind of JSON webservice backend, for example. A stripped-down, data-only webservice, RESTful, perhaps, would be a suitable choice there. The frontend Golf app would fetch data from the backend via AJAX, collate the response on the client, and present the information to the user.

This model would simplify the design and architecture of the backend app, and would facilitate offloading a good portion of the work of collating and organizing the data onto the client. This could result in a leaner backend and a nice separation of concerns between frontend app developers and backend ones.

Incidentally, this model provides a nice partitioning of authorization, placing it fully in the backend. Mistakes or bugs in the frontend code can not do any harm, because the security of the data is enforced by the backend—on the server. A frontend bug that causes it to try to fetch unauthorized data would result in only a failed XHR, not an exploit.

blog comments powered by Disqus
Fork me on GitHub