Why not ActiveResource ?

[Nellboy]

Hi All

I just have a quick question re. why there is no mention of
ActiveResource in this book. Surely as a Rails Library for sharing
data between applications RESTfully, it is worth some consideration/
debate?

cheers!

Paul

[Tony Amoyal]

Thanks for bring this up.  I would like to hear more about it.

I also want to mention I am refactoring my monolithic app into services and I have to say that while this book is great, I really would have appreciated a more built out sample. Architecture is very interesting to me and if anyone wants to chat sometime about how they are implementing their service oriented design I would love to converse.  And if anyone has any built out samples I would love to see them.

Do you think there is room for an open source user authentication service?  It seems that Authlogic and Devise are not well suited for a service oriented design and I am working on something now.  Not sure if I should open source.

--
You received this message because you are subscribed to the Google Groups "Service Oriented Design With Ruby" group.
To post to this group, send email to service-oriented...@googlegroups.com.
To unsubscribe from this group, send email to service-oriented-desig...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/service-oriented-design-with-ruby?hl=en.

--
Tony C. Amoyal
www.tonyamoyal.com
www.frontierstrategygroup.com
www.dailysongfix.com
www.betterhumanrace.com

www.gymshuffle.com

www.gigandtell.com

(240) 417-3112
corga...@gmail.com
@tonyamoyal

"When the power of love overcomes the love of power, the world will know peace."
- Jimi Hendrix

[Paul Dix]

I suppose I could have written something about ActiveResource, but it
mostly would have been about why I don't like it. The main issue I
have with it is that I don't think it results in good API design. It
tries to do things automatically and magically and you end up with
APIs that are way too chatty. They require too many remote calls to
get back the data you'd need to fulfill requests. At the time of
writing it also didn't support associations.

Also, unless things have changed, ActiveResource uses a crappy single
threaded Net::HTTP connection. In a real world scenario you'd want to
use either asynchronous calls or a connection pool operating in
multiple threads to send simultaneous requests. That just isn't
possible if you're using ActiveResource.

I guess I just wouldn't ever use ActiveResource on a project so I
thought it would be wrong to provide coverage for a tool I just
wouldn't use. Maybe I'm being too harsh?

Paul

[Paul Nelligan]

Hi Guys

Tony, you might want to check out this blog post,  I believe it covers a lot of what you're referring to,  source code is also available,  and Gautam (the author) has been very helpful in replying to questions:

http://blog.joshsoftware.com/2010/12/16/multiple-applications-with-devise-omniauth-and-single-sign-on/

Paul,  thanks for the informative reply.  I've been browsing your book,  but haven't quite covered it extensively yet,  so excuse me if what I'm about to say is incorrect.  I implemented a basic CRUD service using JSON in Rails,  with the views contained in one application,  and the models contained in another,  but feel that the problem with this is that I don't have the advantage of being able to share resources across applications.  I can share parameters but not the objects themselves.  So,  instead of using 'form_for @resource',  I'm building forms with 'form_tag',  POSTting/PUTting the parameters across to the service application, and getting a response code.  My issue with this is to do with validations.  If I'm updating the database with invalid data,  and it fails due to validation error,  it still returns a code of 200,  and then I can't figure out a way of sending the object back to the client application with errors.  Also,  I feel it's a disadvantage to work with parameters and not resource based objects in this respect,  since it tightly couples both applications and addition/removal of parameters can get sticky. ActiveResource for me provides a more efficient way to work with this problem. Or perhaps i'm missing something ?

thanks again

Paul

[Andy Waite]

I wrote this post a few months ago after reading Paul's book:

Using ActiveResource to build a layered Rails app
http://andywaite.com/2010/12/22/activeresource-layered-rails-app

You'll see that I ran into a number of issues with using
ActiveResource. My opinion is that it's fine for the occasional call
to a web service, but it seems lacking for designing a large layered
app. I really would like to see a good framework for this kind of
design.

Andy

[Paul Dix]

So the best way to share a service across multiple applications is to
create a client library in the form of a gem. If it happens to be a
model that you want to hook up to the Rails form helpers you just need
to make sure that it conforms to the ActiveModel spec. I covered that
a bit in one of the chapters on writing client libraries.

Having said that, I don't think there's a big gain to turning just
basic CRUD stuff into services. The best things to turn into services
are things that have complex behavior behind them. Take something like
a recommendations system (like Amazon's suggested or Netflix or
whatever). The logic to create something like that goes way beyond
simple CRUD. You have to train models, optimize for real-time lookups,
experiment with new models, etc. Or I could take another example from
a feed reader. The logic to get new feeds, update feeds, and parse can
be quite complex. It's good to hide all that logic behind a service in
a code base all its own.

The best services are ones that encapsulate an iceberg of code and
business logic. The API may be small, but it's only the tip of the
berg. The real work goes on behind the scenes. Of course, sometimes
it's good to have services for things that are simple CRUD. The
example there would be a user management and authentication service
that multiple applications can use. I'm pretty sure 37signals switch
over to something like this last year for all their apps.

Hope that helps,
Paul

[Paul Nelligan]

Yes,  that definitely helps!

thanks

Paul

[Tony Amoyal]

Yes Paul Dix thank you for being so responsive.

What you said makes sense.  I think if multiple apps need the same CRUD interface then it would make sense to build a service, right?  Just for the sake of sharing data really.

[Nellboy]

Hi Paul

as an afterthought, given that the main problem with ActiveResource
is a crappy Net:HTTP connection, do you think it might be possible to
overload this connection using Typhoeus or some other multi-threaded
solution?

thanks again

Paul

On Feb 22, 11:32 pm, Tony Amoyal <corgan1...@gmail.com> wrote:
> Yes Paul Dix thank you for being so responsive.
>
> What you said makes sense.  I think if multiple apps need the same CRUD
> interface then it would make sense to build a service, right?  Just for the
> sake of sharing data really.
>
>
>
>
>
>
>
>
>
> On Tue, Feb 22, 2011 at 5:02 PM, Paul Nelligan <nell...@gmail.com> wrote:
> > Yes,  that definitely helps!
>
> > thanks
>
> > Paul
>

> >> On Tue, Feb 22, 2011 at 4:33 PM, Paul Nelligan <nell...@gmail.com> wrote:
> >> > Hi Guys
> >> > Tony, you might want to check out this blog post,  I believe it covers a
> >> lot
> >> > of what you're referring to,  source code is also available,  and Gautam
> >> > (the author) has been very helpful in replying to questions:
>

> >>http://blog.joshsoftware.com/2010/12/16/multiple-applications-with-de...

> >> > On Tue, Feb 22, 2011 at 9:03 PM, Paul Dix <p...@pauldix.net> wrote:
>
> >> >> I suppose I could have written something about ActiveResource, but it
> >> >> mostly would have been about why I don't like it. The main issue I
> >> >> have with it is that I don't think it results in good API design. It
> >> >> tries to do things automatically and magically and you end up with
> >> >> APIs that are way too chatty. They require too many remote calls to
> >> >> get back the data you'd need to fulfill requests. At the time of
> >> >> writing it also didn't support associations.
>
> >> >> Also, unless things have changed, ActiveResource uses a crappy single
> >> >> threaded Net::HTTP connection. In a real world scenario you'd want to
> >> >> use either asynchronous calls or a connection pool operating in
> >> >> multiple threads to send simultaneous requests. That just isn't
> >> >> possible if you're using ActiveResource.
>
> >> >> I guess I just wouldn't ever use ActiveResource on a project so I
> >> >> thought it would be wrong to provide coverage for a tool I just
> >> >> wouldn't use. Maybe I'm being too harsh?
>
> >> >> Paul
>

> >> >> On Tue, Feb 22, 2011 at 1:10 PM, Tony Amoyal <corgan1...@gmail.com>

> >> wrote:
> >> >> > Thanks for bring this up.  I would like to hear more about it.
> >> >> > I also want to mention I am refactoring my monolithic app into
> >> services
> >> >> > and
> >> >> > I have to say that while this book is great, I really would have
> >> >> > appreciated
> >> >> > a more built out sample. Architecture is very interesting to me and
> >> if
> >> >> > anyone wants to chat sometime about how they are implementing their
> >> >> > service
> >> >> > oriented design I would love to converse.  And if anyone has any
> >> built
> >> >> > out
> >> >> > samples I would love to see them.
> >> >> > Do you think there is room for an open source user authentication
> >> >> > service?
> >> >> >  It seems that Authlogic and Devise are not well suited for a service
> >> >> > oriented design and I am working on something now.  Not sure if I
> >> should
> >> >> > open source.
>

> >> >> > corgan1...@gmail.com

> <http://www.gymshuffle.com>www.gigandtell.com
> (240) 417-3112
> corgan1...@gmail.com <tonyamo...@gmail.com>

[Paul Dix]

I don't think it would be possible to do it with an async style
connection (like Typhoeus). Although maybe it could with the addition
of some fibers. I'm sure that it could be monkey patched to use a
multi-threaded solution. The best would be multi-threaded connection
pooling with keep-alives. However, that still doesn't solve the
problem of it leading to chatty and ill-conceived APIs.

Paul