Why use the CB ajax proxy?

A recent message reminded me that I've been wanting to ask the group
about CB and it's ajax proxy. I've looked at it and I do a fair amount
of ajax work on my front ends but I just can't seem to grasp the logic
of why you would use the proxy. I call my events regularly from jQuery
and such, specifying a url like /index.cfm/customers/listJSON and just
send back my list of customers as a JSON object. Alternatively, I
sometimes just pass a dataformat variable and return the data in
whatever supported format the requester asks for it in.

So what advantages do you gain using the CB proxy? It seems to
actually break the MVC model by replicating your controller code to
the proxy area and/or having the proxy directly talk to your model
(which seems like a bad idea to me). I like the controller layer and
it seems like part of the job of the controller layer is to figure out
how to get the data together and back to the requester in the format
it wants.

Obviously people like the proxy, so I assume that there are reasons
why. I just don't seem to "get" it and would like to hear how/why
people use it.



Typically, I use it to run framework events (so I am still sticking with
MVC), but can control the URL's exposed via ajax and run all my ajax
calls through one place. Then I can deny access to the event if the
call did not come through my proxy. Also for security so you don't have
to have access="remote" on your functions in the case where you want to
call a cfc directly.

I would love to hear other reasoning's, but those are mine.

Curt Gratz
Computer Know How
Coldbox Alliance Partner

I usually setup a route where /api/{anything else} goes to a special Event Handler.

But, I like having the normal interceptor chain fire off. When you hit the proxy, you bypass a lot of ‘normal’ ColdBox work.

Seems to me like remote access is remote access, if you can call a
handler (through an ajax proxy or regular GET request) you can still
get at the same data. I tried working with the proxy but really didn't
like having my control logic in two different places (the handlers and
the proxy). And when you are talking about accessing a cfc directly,
you mean in your model, right, not your handler? If so, I could see
that except that I never allow access to my model directly. In MVC
your Controller layer is your proxy to the model. It just seems like
the CB ajax proxy is another controller that is duplicating existing
controllers...that's the part I don't get.

Cheers and thanks for helping me try to understand.


I like this setup. I presume that your API event handler does your
authetication/error handling/special ajax secret sauce and then uses
RunEvent to call the requested event and then proxies the results
back? That's the sort of setup I've envisioned for a project that has
more of an api-based interface.


Aaron and Judah,

That is similar to what I do, but I use my “api” proxy to call all of my events in their respective handlers so that for instance my user functionality stays within my user handler and if needed, I can reuse that event for non-ajaxy type calls. Mostly 6 of one, half-dozen of another I guess.


My API handler mostly performs ‘runEvent’ for any existing actions. I just elected not to use the Proxy.

I can’t think of a reason not to use the proxy, other than, I don’t think the proxy can be the first request on a ColdBox site (I may be wrong about that).

That was actually what I was trying to say Curt. I've looked at making
a handler that proxies calls to other handlers as needed. I guess that
is sort of what the CB proxy does but the documentation I've seen
seems to be invoking the model directly from the proxy which would
bypass the normal controllers and, thus, making it its own control.
Same functionality as a controller but in, now, two different places.

Still, I feel like I'm missing something and I'll eventually have one
of those "ah ha" moments and totally get why I should use the CB proxy
funcationality for ajax calls. I mean, everything else in CB has been
awesome when I finally figured out how to use it (like autowiring and
model dependency injection).


While I am sure there are other reasons, a big reason I could see, is that a lot of processing is skipped via the proxy–which helps make these service calls as light as possible.

It’s just another door to your application. There is no right/wrong way. But, if speed is important, or you don’t want the interceptor chain firing, use the Proxy.