On 03/30/2012 10:25 AM, Scott Seago wrote:
On 03/29/2012 04:34 PM, Mo Morsi wrote:
>
> I'm intrigued by this idea and don't think its a bad idea to explore
> this further.
>
> I think alot of the question comes down to at what level is the API
> satisfied. Currently it's being done at the controller layer in an 'api'
> namespace, but going along w/ your example I think its best the push
> this and as much else down to the service layer.
>
> This way the service layer can be used outside the scope of the web
> interface in a locally consumable manner. Perhaps this layer can also be
> moved into its own gem so that the end user doesn't need to pull in
> rails to use Conductor.
>
> Makes sense? Would this approach work?
>
> -Mo
I think we're getting a bit far from the original proposal here. I
think there are two different issues here that we're combining --
which makes deciding how to proceed more difficult:
1) Lets re-join the controllers that currently separate UI and API (in
some cases they're combined in the same controllers/actions with
different response types, in some cases (notably for image-related
stuff) where the controllers are completely separate
2) additional discussion about whether API and UI are served by the
same controller actions or if we separate the layers where the API is
at a lower level and the UI controllers actually make API calls rather
than the current "in the same actions" approach
on 2), I would propose that we do _not_ want the separation as you
were discussing above. For one thing there's a lot of stuff you get in
Rails for free to manage coordination between managing activerecord
objects in controllers and views. If we have a UI that only talks to
the API rather than manipulating models directly in the UI
controllers, we'll have to do more work there. In addition, for ajax
methods from the UI, we often want to get json back (rather than
javascript or HTML chunks), which means that even in the UI we'll want
direct json (i.e. API) responses. To ensure consistency in the UI
between ajax calls and HTML calls (for non-javascript, etc.) we really
want those going throuh the same controller actions.
JSON support isn't intrinsically coupled to rails. We can easily
incorporate the json gem and leverage it in any class we would like to
convert instances of to / from json
Furthermore, associating datatypes together isn't intrinsically
dependent on Rails. Sure we get alot of help w/ activerecord, but the
trade off is that now our application is highly dependent on the db. If
we split the UI / API, we can still couple the interface layer to the
DB, persistently storing data we receive from the API, while allowing
others to make use of the common API operations w/ any other data store
of their choosing.
Additionally we can also leverage ActiveModel to take on some of the
workload, or if we insist on using AR as part of the API, we can even
use of that w/out pulling the rest of Rails in, thus reducing
Conductor's dependency stack and allowing individuals to use the API
locally (as opposed to remotely via the REST interface).
However, even with the above point, I _do_ agree with making the
controllers as thin as possible. There's definitely stuff in our
controllers that belongs in the models, and there's probably UI-only
stuff in our controllers that belongs in the views. Before talking
about taking big chunks of the infrastructure and pulling them into
separate gems -- we have to ask what the use case is. There's no point
in doing a lot of work to pull something out unless you have a need to
pull it out there. Lots of our code needs access to the ActiveRecord
models, so even pulling things out won't remove all rails dependencies.
This is all in the name of making Aeolus appealing to more users. When
presenting / promoting Aeolus, I've had individuals ask if Aeolus can be
used locally, eg w/out leveraging a remote transport mechanism (ideally
it would be written in C with bindings to other languages so that it can
be used anywhere but I digress). Giving the user the option to use the
interface either locally or remotely would make it alot easier to sell
the project in situations which the end-user doesn't have a dedicate
server or similar.
This could be mitigated though with a public installation (for demo
purposes or otherwise), but we've already established that the app needs
to be hardend to make that happen (in progress [1]).
One other point -- regarding the issue around UI needing a lot of
session info that the API does not (one of the justifications for
pulling stuff out into separate layers), I'm not sure there's really a
ton that we care about in the session other than login (and that's
handled with HTTP auth in the API anyway, except for ajax-UI actions,
in which case the session is available anyway). For the most part we
shouldn't be relying on a bunch of stuff in the session between clicks
in the UI if we can avoid it.
Agreed on this one, stuffing alot into the session is never optimal and
may present security vulnerabilities.
-Mo
[1]
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Hardening_the_app