Why not json:api?

[alexandru-calinoiu]

The library looks flexible enough so adding support in my app for json:api with this gem should be trivial, was wondering if there is a deeper reason on why not supporting it, or is simply that you want to keep this gem nice and clean?

[okuramasafumi]

There are a few reasons, but the biggest one is the fact that there are so many gems out there such as jsonapi-serializers and jsonapi-resources. I don't think Alba has an advantage over them right now. Personally I'm interested in implementing support for JSON:API, but if the result is not better than the alternatives, I'd like to spend time on different, more unique features. What would you like to get out of JSON:API support of Alba? That means, what would be the advantage(s) of Alba when Alba supports JSON:API?

[mediafinger]

I do agree with @okuramasafumi. And somewhat related I've opened a PR to add jsonapi-serializers to the benchmark, in case you wonder how it compares speed wise with alba: https://github.com/okuramasafumi/alba/pull/109

[okuramasafumi]

If Alba supports JSON:API, it becomes easier to implement different styles of APIs (JSON:API compatible one and flat one) with only Alba. This could be a killer feature for some.

The interface would be something like:

class JSONAPIResource
  include Alba::Resource
  jsonapi!
end

class FlatResource
  include Alba::Resource
end

# This resource follows JSON:API convention
class FooResource < JSONAPIResource
  attributes :id
  # ...
end

# This resource follows no convention
class BarResource < FlatResource
  attributes :id
  # ...
end

[stas]

Hi there, I'm the maintainer of the jsonapi-serializer and a bunch of other JSONAPI related gems. I got here because of the https://github.com/Netflix/fast_jsonapi/issues/477

Unfortunately I could not find any reference on how to configure this gem to generate JSONAPI payload, but more importantly, I'd prefer to not have jsonapi-serializer listed as part of your benchmarks #109 since the comparison is not running JSONAPI specs. Basically, you're comparing here apples to oranges and this is confusing.

But I'm more than happy to add alba to the benchmarks we're maintaining as soon you have the JSONAPI support: https://github.com/jsonapi-serializer/comparisons

I appreciate your support in having this confusion sorted out. Thanks in advance!

[okuramasafumi]

Hi, I'd like to mention a few things. It's absolutely fine to remove jsonapi-serializer from the benchmark, but what do you think about using it to generate non-jsonapi style output? I guess it's not a standard way to use the gem, but it works. Currently we don't have a way to output JSONAPI compatible JSON with Alba. I'm going to implement the feature in near future.

[stas]

It's absolutely fine to remove jsonapi-serializer from the benchmark

Please proceed.

but what do you think about using it to generate non-jsonapi style output? I guess it's not a standard way to use the gem, but it works.

JSONAPI was not designed and not optimized to generate some other specs. The goal of the project is to produce a valid JSONAPI spec and be as fast as possible at it.

This project is claiming that it is:

Alba is the fastest JSON serializer for Ruby.

And then you claim you provide support for JSONAPI, but you don't. Next, folks recommend switching away from fast_jsonapi to your project, and this is just all confusing (as it was for me on how I arrived here...).

My goal with raising this issue is simply to clarify the current situation, if you want to keep using jsonapi-serializer the way it is done now, it's your choice, just make sure you clearly state that this has nothing to do with JSONAPI.

I hope it all makes sense. Thanks again for helping out!

[jgaskins]

@stas

This project is claiming that it is:

Alba is the fastest JSON serializer for Ruby.

And then you claim you provide support for JSONAPI, but you don't.

The way these two are presented, it appears they are meant to be related arguments, but unless I'm misunderstanding I don't believe they are.

Where do you see the claim that it supports JSON:API? I see a few places where it says it doesn't and explains why, but I don't see anything that says it does.

Next, folks recommend switching away from fast_jsonapi to your project, and this is just all confusing (as it was for me on how I arrived here...).

Are there others mentioning it outside of this comment?

I'd prefer to not have jsonapi-serializer listed as part of your benchmarks #109 since the comparison is not running JSONAPI specs. Basically, you're comparing here apples to oranges and this is confusing.

There is a jsonapi_same_format benchmark provided by @mediafinger that uses jsonapi-serializer but emits the same JSON structure as the other implementations, making it very much an apples-to-apples comparison. I don't believe the fact that this benchmark is not about generating an JSON:API-defined structure is a reason to remove that implementation from the benchmarks here. My current company uses the jsonapi-serializer gem but we don't use JSON:API. My coworkers wanted the implementation because it's fast, but JSON:API as a standard isn't something we wanted. That is to say, it's being used this way on a production app that receives more traffic than Hacker News. I don't love the idea that we do that, but I think it makes this a pretty useful comparison.

I do sympathize with your position, though, to be clear. My own serializer implementation, primalize, is not optimized for the structure being emitted by these benchmarks, either (it prefers a flat, normalized structure, similar in concept to JSON:API's includes but not compatible with them), but that doesn't invalidate the comparison. If someone wants a denormalized JSON structure, as many teams often do, this is the most comprehensive performance comparison I've seen for it.

[stas]

@jgaskins thanks for sharing. I already said I have no problem keeping things the way they are, as long as it's clarified this is not JSONAPI spec.

I appreciate everyone sharing their opinions, but this is merely a request to clarify things and remove any confusions.

@okuramasafumi apologies for the noise raised by my comment. I'll stop entertaining this topic, since I think we already have at least a couple of solutions. :bow:

[swilgosz]

+1 for JSON:API support

[okuramasafumi]

Hi everyone in this thread, I found it pretty hard to implement this feature. I create a "help wanted" discussion in #217 so if you really want to add JSON:API feature please share it with your friends so that we can achieve the goal more quickly.