Enterprise Integration Zone is brought to you in partnership with:

Daniel Doubrovkine (aka dB.) is one of the tallest engineers at Art.sy. He founded and exited a successful Swiss start-up in the 90s, worked for Microsoft Corp. in Redmond, specializing in security and authentication, dabbled in large scale social networking and ran a big team that developed an expensive Enterprise product in NYC. After turning open-source cheerleader a few years ago in the worlds of C++, Java and .NET, he converted himself to Ruby and has been slowly unlearning everything he learned in the last 15 years of software practice. Daniel has posted 46 posts at DZone. You can read more from them at their website. View Full User Profile

Grape vs. Poncho

04.11.2013
| 4358 views |
  • submit to reddit
There’re a number of excellent micro-frameworks to author RESTful APIs in Ruby. Let’s take a look at the newcomer, Poncho, from the Stripe team, brought up on the Grape mailing list. For those that don’t know me, I’m the maintainer of Grape and use it very heavily at Artsy. I’ll do my best not to be biased.

With Poncho you start by declaring resources that inherit from Poncho::Resource. A resource is a prescriptive way of declaring what parameters to expect and what results to render from the API. In many ways resources are similar to Grape’s entities, except that the latter are no longer part of Grape and you can use roar, rabl or any other framework to render results - you choose. Poncho resources include parameter validation, which makes sense. Personally, language matters, so I would not call values that can be assigned to the resource parameters, but maybe fields or attributes.

You then declare a Poncho::JSONMethod, which inherits from Poncho::Method, which is a piece of middleware. The former is equivalent to a Grape formatter, and the latter is equivalent to the Grape endpoint Rack middleware. You have to override the invoke method and implement your business logic.

How does all this come together?

    # poncho
    get "/users", & UsersListMethod

    # grape
    get "/users" do
       ...
    end

Grape could easily support the Poncho syntax with a few lines of code. Internally it creates a Proc from the body of the block.

I think that Poncho is in the very early days of development and has made some choices that Grape already made a year or two ago and decided undo more recently. Poncho hasn’t dealt with more complicated problems like versioning or content-negotiation, yet. Once it does, poncho contributors will find that infrastructure begins to bloat and will likely split it the same way we split grape and grape-entity. My current view is that the API DSL layer should be providing functionality closer to the HTTP protocol and a separate entities-like library should deal with data representation. That’s because I have strong opinions that a modern API should be a Hypermedia one, but I would not want to impose this on anyone, which is incidentally a similar philosophy that lead to Webmachine (check out my earlier Grape vs. Webmachine post).

That said, none of the above is difficult to accomplish.

I would certainly have preferred if Stripe chose Grape as the API DSL and implemented their style of data presenters if they felt strongly about that. But we all want our own micro frameworks, don’t we?
Published at DZone with permission of its author, Daniel Doubrovkine. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: