Project

jagger

0.0
No commit activity in last 3 years
No release in over 3 years
Jagger an frontman for your applications. It serves dynamically generated assets via sprockets pipeline, static files and all the templates. All that makes your life much easier.'
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
 Dependencies

Development

>= 0
>= 0

Runtime

 Project Readme

Jagger is your frontman!

Mick Jagger

Jagger is a frontman for your frontend application. Mixing frontend and backend in one Rails applicaiton sucks, let's say it stright! We have bunch of unrelated things mixed together, why? With Jagger you gonna rock your frontend application management!

Philosophy

Backend and frontend of web application are in fact two different applications, ususaly utilizing different languages and tools. The main point of Jagger's philosophy is to split backend and frontend into separated applications.

Frontend - ususally a JavaScript (eg. Backbone) application with set of templates and GUI integration tests.

Backend - an app written with Sinatra, Rails or whatever else, which provices an unified API required by the Frontend app.

Controversy

Are you insane? I have to write two apps instead of one, and everytime I change something in the backend then I have to adjust frontend one?

Um... Well, you do the same every single day. You change something in your Rails model, then you going to the view and editing it, then you going to the (Java|Coffee)Script part and keep adjusting to the changes you made in the model.

The biggest advantages of this layout:

  • Frontend people can work on frontend without dealing with overwhelming backend code.
  • Backend people may don't give a shit about frontend stuff.
  • Application has unified API which can be reused further by other views (iPhone or Android app, external consumers, etc.)
  • Frontend may be written totally without thinking about the databases and other delivery methods. It can focus only on the look and feel by accessing all the data from mocks.
  • It's briliant for the designers, thus they don't need to install all the development stuff (usually, you have to install it for them).
  • After all, you can serve everything as one application anyway...

This layout also have disadvantages:

  • It has no server side generated views - so it is not well suitable for the applications which tend to be crawlable eg. by Googlebot.
  • It requires good communication in your team in case of defining and maintaining the API. Hmm, if you improve your communication thanks to this then it may be considered as an advantage.
  • It forces you to think different and abstract... some people don't like this :P

Installation

Like always, via rubygems:

$ gem install jagger

Or by adding dependency to your gemfile:

gem 'jagger'

Usage

Jagger comes with set of conventions to make your life easier. Here's the frontend app directory structure:

+ your_frontend/
|-- lib/                - External, static JavaScript libraries (eg. jQuery).
|-+ src/                - Dynamic sources.
| |-- styles/           - Your CSS, SASS, LESS or God knows what styles.
| |-- sprites/          - Source images for your sprites.
| |-+ main/             - Your application's (Java|Coffee)Script files.
| | |-- app.js
| |-- test/             - Your GUI test files (i.a. QUnit, Selenium).
|-- static/             - Static images, javascripts, fonts, etc.
|-+ templates/          - All the template files.
| |-- index.erb
|-- config.ru           - Rack configuration.

You can set ther up a Gemfile with jagger listed as a dependency and add this code to config.ru

# *snip*

run Jagger::Builder.new

If you want to mount it within your backend application, no problem! You can do it this way:

# *snip*

map '/api' do
  run MyBackendApp.new
end

map '/' do
  run Jagger::Builder.new
end

You can serve your frontend app simply like any other rack app using thin, rackup or whatever you want.