Now that we have a cleaned up API, which means we dont depend on spree_api, we dont have rabl files and we only use AMS serializers for all api endpoints, we can now move to the next problem: AMS is no longer supported.
But, it looks like AMS still runs on Rails 6, see here. We have time…
In Spree 3.7, released in Feb 2019, spree presents its “store front api v2” that does not use rabl anylonger and moved to fast_json_api.
On the AMS gh repo the two first alternatives listed are fast_jsonapi and jsonapi-rb.
The migration to fast_jsonapi is easy on the backend, the serializers would be very similar to ams, but all frontend code would need to be adapted to jsonapi (which is a good thing imo: data, errors, etc). That’s why this may really be a good time to do the change, our API will only grow from now on…
Questions for the ofn dev community?
- Shall we keep AMS and do not worry as it will only be a problem when AMS stops working with latest rails versions? Rails 7…
- Shall we investigate and adopt an alternative that is actively maintained like fast_jsonapi NOW that we are changing it all as far as the api is concerned?
What do you think?
On one hand, I think for once we should update a dependency before it becomes a critical issue. On the other, I think it’s less urgent than many other things…
However, there’s the added argument that we’re now touching the API. So it seems reasonable but first I’d like to spike and document how an AMS should be refactored to fast_jsonapi, including cached responses. Once we have that information we can decide on a plan.
How does that sound?
We finally removed the last rabl file from our code 
I found there are other alternatives to AMS:
and
Blueprinter syntax looks more similar to AMS, maybe an advantage. And I think you can use jbuilder together with fast_jsonapi.
Looking at this again, the easier option would be to play it safe and move to the most widely used (including spree) fast_jsonapi.
To do that we need to create an issue on GH, a spike to see how the migration would look like. Maybe a good issue for new devs.
Awesome. Getting to Rails 4 was a blocker to trying out fast_jsonapi, but now that we’re there I think we should try it. When playing with reports I came to the conclusion that AMS is actually quite bad in terms of performance.
I had a feeling when I first looked at fast_jsonapi that it didn’t like returning nested associated objects, but it looks like it can 
1 Like
On #5638, I investigated a lot to don’t use render plain, but I believe this an integration problem between Rails and AMS.
I usually use fast_jsonapi on my projects and, IMHO, it works really well. It is easy to set up, to test, the syntax is similar to AMS, and it is fast (or at least, faster than AMS).
1 Like