ruby-grape / ruby-grape/grape

Interest in type-checked grape?

Open
#2,343 4 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

discuss! feature request
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:

  1. either move 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
  2. 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_json instead of my_obj when the endpoint is supposed to return an instance of my_obj.class
  3. Bring grape-entity along for the ride - add typing to its DSL
  4. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.