Solidus: Migrate from JBuilder to another serialization library?

[nvh0412]

We're using JBuilder too long, and its performance is the one that we can improve by using AMS. Spree didn't migrate JBuilder to AMS, just because AMS is not ready at the time they discuss it.

AMS v0.10 is stable now, and I used it in many production environments, so my suggestion is migrating to ASM for all our API endpoint to improve our response time. At least we can save ~100ms for each one, I believe.

Really glad to receive any feedbacks about this issue.

[tvdeyen]

Panko is a AMS compatible serializer that’s even faster than AMS.
https://yosiat.github.io/panko_serializer/performance.html

[nvh0412]

Good one @tvdeyen, have you ever use Panko for the production environment? just want to know does it have any limitation.

[yosiat]

hi,
I am the creator panko and we are using at production environment,
If can help, feel free to ask any questions

[jarednorman]

One issue that we encountered in previous discussions about AMS is that it used global configuration, meaning that apps would be stuck using it the way we configured it, or their configuration would override and potential break the admin and stuff.

I personally work on stores that are using AMS (though honestly haven't been super happy with it) where this would be an issue.

For some personal opinion/anecdotal info, most stores I've worked with built out custom APIs for any storefront related logic they needed, so the performance of the Solidus API has never been a problem for me. I prefer using the Rails-endorsed solution for building JSON, jbuilder, for maintenance reasons.

[tvdeyen]

Supergood points @jarednorman. I did not thought of that tbh. Yes, extentability is an issue with AMS and much easier with jbuilder (as longs as you don't need to override the controller action anyway)

[nvh0412]

thanks @tvdeyen @jarednorman for this discussion, closing issue.

[BenMorganIO]

I'm :+1: on moving away from JBuilder.

[jacobherrington]

Let's keep this issue open for discussion.

[BenMorganIO]

TBH if we change up the API a bit more, we could just use to_json/as_json and remove the need for a JSON serialization dependency. It would be hard work, but probably worth it on a few endpoints. Like, the main problem we keep having is: we want to to use a thing that makes the API look nice. We could try getting rid of that altogether.

[ericsaupe]

Netflix also has a serializer https://github.com/Netflix/fast_jsonapi. Adding that link just to give another option.

We ran into a few areas where we wanted more data from the API that wasn't given. I'd like to see some improvements made to the API and serializing models might be useful.

[hoanglannet]

Is there any decision on this? fast_jsonapi should be a great approach we should go because of its performance improvements.

[aldesantis]

@hoanglannet unfortunately, adopting fast_jsonapi would mean migrating to JSON::API, which would force us to release a new version of the REST API and maintain both until (at least) Solidus 4. With all the work we've been doing on GraphQL recently, I don't think we'll be undertaking a project of this size any time soon.

We want to understand which API(s) stores use and how they use them — that will allow us to figure out whether we want to continue supporting both the REST and the GraphQL APIs indefinitely, or if GraphQL should eventually supersede REST.

Are you running into serious performance issues with the REST API or are there other reasons you're looking to switch to another serialization library?

[tvdeyen]

I could imagine a solidus-json_api gem.

GraphQL should not supersede but live besides the REST API. GraphQL has many downsides while REST is performing better and very well known. I see the importance in GraphQL, but would never vote for it to be the "default" API of Solidus.

[aldesantis]

An extension (and perhaps some kind of generic serialization architecture in the core) would be more than welcome! 😍