You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have a lot issues with the jsonapi resources. I would like to discus if it would be better to migrate to another serializers.
Currently we have the following issues
No namespace support
A lot of magic (things happening automatically)
Issues with migrating to Active Storage
When we would migrate we could do things again more vanilla Rails instead of a lot automatically. Disadvantage would be that we probably will lose the full jsonapi spec (like all relationship endpoints) but we probably do not need all of this.
As far as I can see from the documentation it looks like this can work mostly with rails without a lot of magic. However, the is not much documentation. The jsonapi-rails project is mainted. However, the jsonapi-rb project (which the rails project uses) is not updated since 2017.
This promises to be a fast serializer. This also works with rails without a lot of magic. However, since november 2018 there are only 3 documentation commits and no other commits. The deserialization needs to be done by hand, but we can do this with params.permit(..) so that shouldn't be a problem.
This is the most active project of those 3. It looks very flexible but I don't see anything about relationships (except including the full record). It also includes 'conditional fields' which is nice mainly for the user model (probably the other projects also include this, not sure)
I also see some disadvantages of those 3
Manual definition of all routes (so the relationship routes are lost)
No out of the box filter options (like filter[ids]=1,2,3)
... probably more
I would like to get some feedback about your ideas about JSON API resources and a possible alternative
The text was updated successfully, but these errors were encountered:
I really understand your frustrations, and I've had them too. I've also struggled with the search for something new. fast_jsonapi looked most promising, but since there is no deserialization it requires quite a bit of effort.
I've never heard of Blueprint. I'll look into it now.
p.s. option 4 was ActiveModel::Serializer. But, since that is even less maintained than the jsonapi-resources, I can't recommend it.
Yes ActiveModel::Serializer is also an option. But that was the serializer we came from before jsonapi-resources and it is not maintained at all I didn't include it in the list
Currently we have a lot issues with the jsonapi resources. I would like to discus if it would be better to migrate to another serializers.
Currently we have the following issues
When we would migrate we could do things again more vanilla Rails instead of a lot automatically. Disadvantage would be that we probably will lose the full jsonapi spec (like all relationship endpoints) but we probably do not need all of this.
There are a few options.
jsonapi-rb (http://jsonapi-rb.org/)
As far as I can see from the documentation it looks like this can work mostly with rails without a lot of magic. However, the is not much documentation. The jsonapi-rails project is mainted. However, the jsonapi-rb project (which the rails project uses) is not updated since 2017.
Netflix fast_jsonapi (https://github.com/Netflix/fast_jsonapi)
This promises to be a fast serializer. This also works with rails without a lot of magic. However, since november 2018 there are only 3 documentation commits and no other commits. The deserialization needs to be done by hand, but we can do this with
params.permit(..)
so that shouldn't be a problem.Blueprint (https://github.com/procore/blueprinter)
This is the most active project of those 3. It looks very flexible but I don't see anything about relationships (except including the full record). It also includes 'conditional fields' which is nice mainly for the user model (probably the other projects also include this, not sure)
I also see some disadvantages of those 3
I would like to get some feedback about your ideas about JSON API resources and a possible alternative
The text was updated successfully, but these errors were encountered: