Home

You interface with goliath by writing one of the following three:

• Goliath::API classes define the endpoint of a route. Each must be named for its file (eg. foo_muncher.rb must define FooMuncher < Goliath::API), and must define a response method. If you need to route to multiple endpoints the recommended way is to run one goliath process for each endpoint and handle the routing upstream (via apache, nginx, haproxy etc).
  • See the code for many examples.
  • How to perform Asynchronous-Processing of HTTP, MySQL and more.
  • HTTP Streaming endpoints

• Middlewares decorate the response with before, around or after actions (eg validating an API key, logging a call, wrapping a JSON-P callback). They follow the familiar Rack middleware paradigm of initialize and call (returning [status,headers,body]). PLEASE NOTE however an important difference in how you delegate down the chain — the Writing your own middleware section explains more, and see the middleware examples

• Plugins add code that share the reactor but are outside the response flow of any particular HTTP request. For example, you might use an EventMachine periodic time to send a heartbeat log message or metrics to your graphite server. For an example that periodically records the reactor latency, see the plugin examples

Goliath comes with built-in support for Configuration and Testing.

The timeline of events leading to a response can be hard to puzzle out. Help complete these notes on Goliath server’s Timeline.

See the Server page for information on running Goliath.