Search code examples
clojureringimmutant

Multiple ring sites on one immutant?


Immutant allows applications to respond to web requests via Ring handlers. Each application can dynamically register any number of handlers, each with a unique context path. This allows you to have multiple Ring webapps that share the same deployment lifecycle.

So it says I can have multiple Ring apps on one immutant but can I/should I have two separate websites running on one immutant: site1.com and site2.com?

This context path is considered the top-level context path - you have the option to bind a handler to a sub-context path that will be nested within the top-level path. The full context is stripped from the url's path before the request is processed, and the context and remaining path info are made available as part of the request map via the :context and :path-info keys, respectively.

It sounds like I can have an app running on site1.com/context1 and site1.com/context2 but not so much two separate domains.

The reason I'm asking is because immutant takes up a lot of my server resources so much so I'm not sure if I can run two immutants. The correct question might be how do I improve performance on my immutant? (I'm not any good with servers/deployment.)

Source: http://immutant.org/documentation/0.1.0/web.html


Solution

  • The answer is complicated by the fact that there are currently two major Immutant version branches: 1.x and 2.x. 1.x requires far more resources than 2.x, but 2.x hasn't been officially released yet (though incremental releases are available).

    Both versions support mounting Ring apps at various combinations of virtual host, e.g. site1.com, and context path, e.g. /context1. In Immutant 1.x, the :virtual-host setting is in your deployment descriptor, as is the :context-path for the entire project. This is somewhat confusing, since you can also specify a :context-path when starting your Ring handler. The one passed to immutant.web/start is resolved relative to the one set in the deployment descriptor, which is why it's referred to as a "sub context path" in the docs.

    In 2.x, things are simpler, because there is no deployment descriptor. Everything is passed as an option to immutant.web/run.