Swap out rabl for something a bit more manageable

[athal7]

Rabl is difficult to extend for stores looking to add more information (essentially have to bypass it by adding an attribute to a helper array, or replace the template entirely), is currently used with a caching strategy whereby we still load all of the records from the database on a warm cache, and can swallow errors. Other options that exist can make these issues less difficult, and we can maintain the same api contract as a first pass if we would like so that a major upgrade is not required.

[cbrunsdon]

The general consensus north of the 49 is Rabl was a great decision at the time but has not stood up well to customization or expansion.

Its tough to work with, extend and comprehend. We are for scrapping it's existing interface entirely.

My personal preference for going forward is:

1. Support the current api endpoints for a while longer exactly where they are
2. Start up a new API endpoint only for the frontend

• use AMS with the JSON::API adapter
• keep it light and tight for the frontend for easier security separation and auditing
• drop Spree::API::BaseController because its terrifying

We've been following this path in one of our stores to great success, which will soonish be in a shareable state.

[hhff]

Hey guys! Just wanted to chime in and say hi! I built Spree Ember and have been chatting with @BenMorganIO about working to support solidus too.

I originally built spree_ams, which inherits all logic from regular API controllers, but simply responds with AMS instead. It's a very simple gem, but I think it's worth checking out. I'd love to stay abrest of this and help out where possible :)

[hhff]

http://spree-ember.com that is

[BenMorganIO]

@hhff does have a gem that covers the frontend nicely. Its a great starting place IMHO.

There's also lots of discussion about this for Spree RFC #1: spree-contrib/rfcs#1.

[jarednorman]

Remember that AMS has global configuration, so if stores have AMS already and have it configured it differently that we configure if, this may present a non-trivial upgrade cost to those stores. This is the same reason we can't even consider using something like simple_form on the backend.

[BenMorganIO]

@jarednorman We can add a Solidus::BaseSerializer to "cement" our configuration. That way when someone changes something globally, it won't hurt the serializers.

OR

Also, we could just use the a certain json format via the content type? This way we can explicitly say to the request: hand us this format, and not the main applications: Content-Type: application/prs.solidus+json. See RFC 6838 Section 3.3

OR...

There's also another option where we can make a Solidus::JsonAdapter that can "cement" some of the configuration.

I feel like this cat has many ways of being skinned. Treading carefully on the configuration portion is probably important.

If anyone has any thoughts on this, I can start experimenting with different methods on the https://github.com/wildcardlabs/solidus_json_api and see what turns up.

[kennyadsl]

This issue was mainly created for using a different tool than RABL, and this has been done with #2147 .