-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Rack dependency #734
Comments
The big question is, of course, what is the future middleware stack that will replace Rack. |
That's right. Which Rack dependencies has grape?
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) |
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. |
@taybin , totally agree. |
@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 With this in place you also hurting a "soft rule"
In theory you always have to do a full integration test with some thing like 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. |
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! |
@dspaeth-faber +1. rack is something that many other gems depend on. In my rails3 app, i am using omniauth which needs 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. |
@dblock & rabbitmq. What I can imagine is RPC style rabbitmq communication. |
Just to keep it up to date, one spike for a new Rack https://github.com/tenderlove/the_metal |
I think we should wait for the successor of rack and HTTP 2. |
I like the progress http://hanamirb.org has been making, would love to compare, benchmark and potentially support both Rack and Hanami. |
@dblock I thought Hanami is a Rack-based framework. Does it provide an alternative low-level abstraction as well? |
You're right @ch1c0t, I meant https://github.com/hanami/router. I should have posted this into #1072, which has now been done. |
AFAIK, hanami router has depended on http_router, and it's thread unsafe. So I've implemented new router by using the Mustermann gem. This has been merged into Padrino Framework. |
@namusyaka 👍 you should give it a try in Grape - replacing the legacy unmaintained libraries with faster newer better implementations is high on my list. |
Yeah, I'm going to replace the router. |
We replaced the router in #1276. It's a step forward! |
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.
The text was updated successfully, but these errors were encountered: