Interest in type-checked grape?
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 10k
- Forks
- 1.2k
- Avg merge
- 14h 38m
- Merged PRs (30d)
- 92
Description
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:
- either move
paramsdefinition 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 - do essentially the same thing for endpoint method returns, although those are currently just "documented" for OpenAPI purposes, but basically you should get an error if you return
my_obj.to_jsoninstead ofmy_objwhen the endpoint is supposed to return an instance ofmy_obj.class - Bring
grape-entityalong for the ride - add typing to its DSL - once the above are complete, it should be possible to generate OpenAPI specs from the types themselves instead of from developer-provided doc strings/annotations, and use static analysis to ensure a given API conforms to the spec
This 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!
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files or tests are named. Start by reviewing the existing params DSL, endpoint return documentation, grape-entity, and grape-swagger integration points, then determine whether typing belongs in a new gem or Grape itself. Done would require an agreed scope and design for type inference, checking, and OpenAPI generation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100