2

I need to generate api endpoints for certain database views we have in our postgres database dynamically, as we may add / delete views we don't want to update the code every time we do this.

for this i have a generic controller which handles all requests and I create model class on the fly based on which view needs to be accessed.

when a request is sent to the generic_api#index based on the end_point passed i create certain model classes on the fly and query them.

routes.rb
namespace 'api' do
    namespace 'v2' do
      get '*end_point', to: 'generic_api#index'
    end
  end

const = ClassFactory.class_object(end_point.classify, result)
      Octopus.using(result['shrad'].to_sym) do
        result = const.ransack(params[:q]).result.page(params[:page]).per(10000)
        render json: result.to_json
      end

The api itself is working as expected, however i am not sure what's a good way to generate documentation for the API since i only have one controller. we were earlier using the apipie gem but the documentation seems to be tightly coupled with controllers for each end point.

Any help on how to generate api documentation when I have a single controller handling multiple end point requests would be great, Thanks.

opensource-developer
  • 2,826
  • 4
  • 38
  • 88
  • I would at least limit the route to valid `end_point` names, for example with a [path constraint](https://guides.rubyonrails.org/routing.html#segment-constraints) – spickermann Mar 21 '22 at 17:00
  • You could always make individual controllers and then just inherit all the functionality from the same place so they don't actually contain much logic within them. Might be easier than spending hours trying to solve this problem of API doc generation. – max pleaner Mar 22 '22 at 00:04
  • Hi @maxpleaner, the end points are generated dynamically and we don't want to make code changes every time a end point is added / removed – opensource-developer Mar 22 '22 at 09:07
  • How do you then expect to automatically generate documentation for something that may not even exist when the documentation is generated? – max Mar 22 '22 at 14:44
  • You might just have completely unrealistic expectations - most documentation tools are based on generating documentation based on your code. In this case you have flipped this and you're generating code from the views in your database schema and handling everything though a god class controller - I don't think I have ever heard of a tool that covers that and you might have to either create such a tool or resort to manual API documentation. – max Mar 22 '22 at 14:52
  • thanks @max, you are correct, i think i need to create something manually. I was thinking to may be generate the controllers for documentation purpose on the fly like i am creating `AR Models` but i don't think that would work with the documentation tools – opensource-developer Mar 22 '22 at 14:55
  • If adding views is still a developer concern I would seriously consider using code generators instead of going nuts with metaprogramming. While "we don't want to add code when we add views" might make sense now it will make a lot less sense down the road when you need to maintain it. Debugging a god class catch-all that magically creates models sounds like pure nightmare fuel. – max Mar 22 '22 at 15:05
  • @max, can you please point me to some links where i can read more about code generators please? – opensource-developer Mar 22 '22 at 15:08
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/243190/discussion-between-opensource-developer-and-max). – opensource-developer Mar 22 '22 at 15:12
  • 1
    https://guides.rubyonrails.org/generators.html – max Mar 22 '22 at 15:52
  • 2
    Documentation generators have a hard time with metaprogramming, in general. Metaprogramming is a powerful tool but should be used cautiously because it can make the code difficult to understand and inflexible. Also, having a single endpoint create controller classes dynamically just sounds way overcomplicated. Rather than going with a metaprogramming-first approach, maybe just try writing it in a more typical way and then seeing how much you can metaprogram without breaking things. A lot of metaprogramming can be avoided with good use of inheritance and mixins, too. – max pleaner Mar 22 '22 at 17:29
  • @max you want to convert your comment to an answer may be? I decided to go the `rails generator` way, might also be useful for anyone stumbling on the post – opensource-developer Mar 23 '22 at 12:51
  • @opensource-developer That's ok. Feel free to make your own answer, you can accept it in 2 days – max pleaner Mar 23 '22 at 17:43

0 Answers0