Integrate Serializers or Presenters

[vanstee]

Right now overriding the built in as_json method for each model is kind of a pain and should really be split out into a separate class. Integration with active_model_serializers would be ideal but providing a simple way to use any presenter gem would be really useful.

This would also take care of limiting or adding custom attributes, embedding other model representations, and including hypermedia type links to related resources. It would also probably be nice to put these kind of things in the standard "out of the box" representations.

[ilatif]

Hi @vanstee

Your project is awesome and I really like the idea. I have been working in Ruby on Rails since last 02 years and now I decided to give back to Open Source and your Project seems an awesome place to get started.

Your Project is simple but don't you think adding "active_model_serializers" will be a overkill. I think we should stay simple and straight-forward. What about giving End-User the ability to add attributes to the "request" that he only wants to get received i.e id, name when he calls "/people.json?attributes=id,name". I think one simple way of doing this is to add a custom method to each model which will return the "attr_accessible" fields of that model in json or his preferred format and the developer that is consuming the WebServices exposed through your Gem will receive the parameters that he is allowed to access and we can also provide some Abbreviations against each Parameter such as "name => na" etc. so that "request" don't become overpopulated with parameter names. This is the way I have seen most of the WebServices such as SeoMoz and SemRush etc working.

I would love to contribute to your project and would love to discuss with you when you have free time. :-)

Thanks.

[vanstee]

@ilatif Thanks man. Yeah feel free to contribute. I'm always open to reviewing pull requests and such.

For the active_model_serializers bit, the main idea here was to support them if the user decides to use them. I think keeping serialization separate from the models is a major plus. Also I kinda want people to be able to drop models from other projects into a hovercraft project (or even mount a rack app inside the project they already have) so I kinda want to stay away from adding too much built in functionality that messes with active record or anything.

So the main idea is to try and support active_model_serializers (and rabl, jbuilder and all the others) as a normal rails app would, not really to add our own methods of serialization.

Scoping out attributes is an interesting idea but I think the problem is actually bigger than that. Right now the routes are not extensible and that's a big problem. I was thinking about allowing people to pass in a custom routes module that has routes defined for each model they want (see Hovercraft::Routes). So if they wanted the attribute scoping like you described they could just implement it on their own. Seems like a more global solution. Thoughts?

[ilatif]

@vanstee Thanks man for your reply and motivating me to contribute.

Yeah! you are right regarding supporting active_model_serializers and that would be awesome if we achieve the goals that you outlined in your previous comment (drop models from other projects, mount another rack app). But if user don't want to support active_model_serializers to keep it's app simple then I think there must be some built-in simple mechanism to support Serialization of Models because I think it would be better if we provide hovercraft as a drop-in replacement for serving their ActiveRecord Models. Some Programmers are just too lazy and we have to support them too. ;-)

Yeah, I agree with you that Hovercraft::Routes are not extensible and I think if we make them extensible then most of our issues related to Serialization etc. will be solved.

I wrote down my previous comment in the context of a Lazy Programmer who don't want to do anything on it's own and wants to use our Gem as a drop-in replacement to serve his Models as WebServices without doing any extra stuff and he is also not willing to provide Developers with any Documentation, so in this case we need to make our Gem a good boy so that it handles all of the necessary stuff for the Developers using the App that is powered by our Gem. I hope you understand my point. :-)

What about having Subdomain based routes so for example if User wants to expose models under say 'shop' directory as http://shop.domain.com/model.json :-)

I think we first need to work on making Routes Extensible.

Please! let me know your thoughts and if I' am wrong at some place then please! accept my appolozise in advance. :-)

Thanks.

Imran Latif.

[vanstee]

RE: built-in simple mechanism to support Serialization of Models

I think overriding as_json in the model would be sufficient for the lazy.

RE: Lazy Programmer

Sorry, still not sure I entirely understand the argument here.

Subdomains would fit under the "custom Hovercraft::Routes" option.

[ilatif]

@vanstee Yeah! you are right regarding overriding as_json method in the model for the Lazy Programmers.

Regarding Subdomains, I was saying that we should provide some defaults to the Developer and yeah he can override it with "custom Hovercraft::Routes" option. So, what you think about having a directory within /models, should we server it with subdomain or without subdomain by-default.

Sorry! for getting you confused regarding Lazy Programmer Stuff. I was saying the for example a Developer creates some models and uploaded to some VPS and exposed them to outside world by using our Gem to perform "CRUD" operation in a "REST" way and then he asks his fellow Programmers to use the API he just authored using our Gem. But he haven't provided any useful information about Models, their Column Names, DataTypes etc. So, what should the fellow Programmers do in this case. Off-course they can just open-up the Database using their favorite method as they are all working on same Database. But don't you think it would be nice if our Gem handles this thing and the developers who are about to use APIs exposed our Gem can used some method calls provided by our Gem to get clear information about routes, information about database, tables, columns etc. If I' am still confusing you, no worries and forget about this stuff. :-)

Thanks.

Imran Latif.

[vanstee]

Yeah I think making this truly RESTful, including hypermedia urls and OPTIONS routes would solve those issues as well.

[ilatif]

@vanstee Thanks for your reply.

Yeah, you are right regarding hypermedia urls and HEAD routes. :-)

I was thinking that I should start with adding a "search" REST method in the Gem so that User can query the WebServices to search on some criteria. I was thinking that if Developer includes a class method "search" in the model then we will use that method and if there is no such method then we will use our own custom method to search through the Models.

Please! let me know your thoughts on this and I' am really Sorry! if I' am bothering you.

Thanks.

Imran Latif.