Golf Application Framework Features
The Golf framework provides:
- Simple, flexible clientside MVC: Golf apps are divided into models, views, and controller. This is standard practice nowadays, and is probably familiar to anyone reading this. A full description of the Golf implementation can be found here.
- Built on jQuery: The Golf framework integrates tightly with jQuery. This provides a solid, cross-browser foundation for DOM manipulation and AJAX. JQuery is simple, light, and fast, and it is very reliable.
- CSS rules in one component do not ever affect elements outside of the component, or any nested components. Neither do CSS class names.
- The jQuery object
$ is similarly encapsulated, so that doing something like
- Resources, such as images, for example, are also private. Components can be packaged with their own resources as a modular unit, and inserted into any page. They will look and behave identically anywhere. (Global resources are also possible when desired.)
- Component public methods: You can define public methods in your component constructor to provide a public API. This allows structured access to the component from other components or code. For example, a component could have a
showResults method that would be called by a parent component, thus allowing the parent to cause updates in the child without direct manipulation of the child’s DOM.
- “Back-Button” And Deep Linking Support: Golf provides built-in support for dynamic history and deep-linking. This means that your app never reloads the page, but the back button still works and you can have a multiple entry points. Users can copy the URL in their browser’s address bar and send it to their friends or twitter it, and others can follow that link to enter the app at exactly that point. Your app can contain hyperlinks that are portable and can be copied and pasted into an email, for instance. Of course, this feature works equally well in proxy mode, which is important when dealing with search engine spiders. Links that appear in search engine results will always lead to the right place.
- Plugins, Mixins, And Libraries: Golf apps can load global jQuery plugins and library scripts, as expected. But Golf also provides a flexible, yet powerful subset of CommonJS functionality that allows the use of component mixins and local namespace loading of libraries.
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:
- Open source: The Golf server is open source software. The source code is available and you can pretty much do whatever you want with it.
- No dependencies: The Golf server is distributed as a single jar file with no dependencies other than the Java Runtime Environment, version 1.5+.
- Local dev server: You can run Golf on the command line to start a local dev server while you’re developing your app. Changes to your app source code are updated in the server instantly, so you don’t need to restart anything to see the effect of your modification.
- Deployment options: Golf has a number of options for deploying your app to a production server, and we’re working on adding more. Deployment is taken care of by the Golf jar file itself, using command line options. You do not need Apache Ant or Maven, etc. However, Golf can be used from within those tools, if you wish. The current deployment options are:
- War file: Package your app as a war file that can be deployed to a servlet container.
- War file + AWS: Package app as a war file (as above) but upload static resources to Amazon’s CloudFront CDN. This means that JS-enabled clients load only a single HTML skeleton page for JS detection purposes (4K or so, uncompressed). After that the whole clientside app is loaded from the CDN.
- Fine-grained control over JS support: Golf apps are easily configured to restrict certain user agents from access in non-JS mode, or to force either JS or non-JS mode, and more.
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.