Refactor Rack dependency

[dspaeth-faber]

Grape is in many parts depentend from Rack. Like this post show's Racks future is uncertain. In my point of view grape should plan ahead and decouple from Rack as much as possible.

[dblock]

The big question is, of course, what is the future middleware stack that will replace Rack.

[dspaeth-faber]

That's right. Which Rack dependencies has grape?

• Middleware
• Request
• Environment
• Rack::Mount::RouteSet
• ...

How can you seperate Grape Logic from this? What should Grape do?

I think it should build an Handler. You but in Headers, Query-Params, Body and get Out a Status, Headers, a Body.

Some thing like this (as first thought)

[taybin]

I think it's a bit premature to refactor Rack out before knowing what to replace it with. You'll still have to refactor everything again depending on what the replacing library is. Much better to wait until you know what the new API is. Otherwise you'll potentially have a huge design mismatch.

[dm1try]

@taybin , totally agree.

[dspaeth-faber]

@taybin & @dm1try sorry, I have to disagree. Decoupling is one foundamendal design pattern. That grape is tightly coupled with Rack you can best see when you try to test your API. You can't test a single route in isolation. You always have to do an integration test with rack mocked out via rack/test

With this in place you also hurting a "soft rule"

don't mock what you don't own

In theory you always have to do a full integration test with some thing like capypara and poltergeist or webdriver if you want to test a route or you don't find errors like #563.

But doing always integration tests because you can't do unit tests slows down your tests and make it obvious that design and coupling can be improved.

In my point of view it would be good when grape starts decoupling. HTTP is only a transportation mechanism. If you decouble you can grape for instance also use with rabbitmq. You only have to drop in the right adapter.

When you define an interface for your transportation mechanism it isn't a so important what replaces Rack you "only" have to create an adapter to the "next Rack".

Maybe you did read "Practicak Object-Oriented Design in Ruby" from Sandi Metz. She can explain better then I what I mean.

[dblock]

I think we should leave the OOP theory alone and focus on actual code changes in PRs, or we'll be arguing about it forever. Do I have OOP opinions? You bet :)

I would really like to see Grape on top of something like RabbitMQ. I have no idea what that looks like, but I think that would be a very interesting direction to explore!

[rubystar]

@dspaeth-faber +1. rack is something that many other gems depend on. In my rails3 app, i am using omniauth which needs rack ~> 1.0. So grape ~> 0.3.2 is the latest version that i can use for that reason. Not sure how hard it is, but decoupling grape from rack sounds like a reasonably good idea.

or At least, we should go with the basic rack version, and have the additional rack features implemented in a separate grape name spaced gem.

[dspaeth-faber]

@dblock & rabbitmq. What I can imagine is RPC style rabbitmq communication.
Every client sends it's request to a topic exchange. The path of an url is the routing key. To hit
rabbitmq convention / are replaced by .. Query params will be pushed to a special header or you create a body with some conventions what seperates the needed parts.
The client provides an anomymous queue for replies. The server binds it's queue(s) to the
exchange. You can choose and ceate for every route a queue and bind to the exchange with the full routing key or you create a small dispatcher which binds with wildscard routing keys and calls the route depending on the received routing key. Results or send back directly to the anonymous queue. Thats all.

[dspaeth-faber]

Just to keep it up to date, one spike for a new Rack https://github.com/tenderlove/the_metal

[kuon]

I think we should wait for the successor of rack and HTTP 2.

[dblock]

I like the progress http://hanamirb.org has been making, would love to compare, benchmark and potentially support both Rack and Hanami.

[ch1c0t]

@dblock I thought Hanami is a Rack-based framework. Does it provide an alternative low-level abstraction as well?

upd: found https://github.com/hanami/router

[dblock]

You're right @ch1c0t, I meant https://github.com/hanami/router. I should have posted this into #1072, which has now been done.

[namusyaka]

AFAIK, hanami router has depended on http_router, and it's thread unsafe.

So I've implemented new router by using the Mustermann gem.
https://github.com/namusyaka/pendragon

This has been merged into Padrino Framework.

[dblock]

@namusyaka 👍 you should give it a try in Grape - replacing the legacy unmaintained libraries with faster newer better implementations is high on my list.

[namusyaka]

Yeah, I'm going to replace the router.

[dblock]

We replaced the router in #1276. It's a step forward!