Grape vs. Poncho
Grape vs. Poncho
Join the DZone community and get the full member experience.Join For Free
Continue to drive demand for API management solutions that address the entire API life cycle and bridge the gap to microservices adoption.
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.
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 Daniel Doubrovkine . See the original article here.
Opinions expressed by DZone contributors are their own.