-
-
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
Interest in type-checked grape? #2343
Comments
I think it's a great idea, and I think you're on the right track for All that said, I would definitely POC the work by brute-forcing it in a fork first ;) |
I would love to see this happen |
Only tangentially related to the ask in the first post, but if anyone is interested in using Grape in a Sorbet-typechecked project, you'll probably find the grape_sorbet gem helpful. For now the gem is mostly focused on making it possible to use Grape without having to opt out of typechecking entirely with In theory, it should be possible to achieve something close to what the first post suggests by defining Sorbet typed structs to hold parameters and augmenting Grape's |
Whoa! Thank you for your contributions to the space @olivier-thatch. I'll have to check this out. |
Heyo,
So I've been using grape extensively for the past few years, and with RBS and steep/sorbet progressing, I wondered what the interest would be in adding type-checking to grape.
In a sense, the params parsing brings maybe 30% of the benefits of types to a grape API, and provides a solid target for generating OpenAPI/Swagger. My thought would be to implement something like the following:
params
definition into RBS, or infer types from the existing DSL, preferably the latter, with the result that you get type checking/hinting/completion in your api endpoint method, e.g.params.username -> String
my_obj.to_json
instead ofmy_obj
when the endpoint is supposed to return an instance ofmy_obj.class
grape-entity
along for the ride - add typing to its DSLThis is obviously a fairly complex task, so my first question is, is this something people would find useful? It would eliminate a whole category of tests and bugs involved in ensuring backend talks to frontend properly, but it would also add a non-trivial amount of friction.
My second question is, where does this belong? I think monkey-patching/extending grape, grape-entity, and grape-swagger in a new gem should be possible, but I could also see an argument for forking grape and adding this functionality directly, or for trying to make it a first-class, opt-in feature of mainline grape.
Thanks for your thoughts!
The text was updated successfully, but these errors were encountered: