add an alternative to pekko-http-spray-json

[pjfanning]

Spray-JSON is not causing any problems but it is not actively maintained.

We could deprecate pekko-http-spray-json and provide an alternative. In terms of active maintenance and performance, it would appear that jsoniter-scala would be a good choice.

Other options include

• borer
• jackson/jackson-module-scala

I guess Circe is an option but it is not as performant as the others (there is a jsoniter-scala booster though that seems to help improve Circe writes).

Feel free to suggest alternatives.

For jsoniter-scala, jackson and circe, we have https://github.com/pjfanning/pekko-http-json but it would require that we a Software Grant from Roland Kuhn (because pekko-http-json is forked from akka-http-json) and some CLAs signed.

For Circe, we also have https://github.com/mdedetrich/pekko-streams-circe

One of the main issues is that we use pekko-http-spray-json in many pekko-connectors as well as in some of the discovery modules in pekko-management. If we have an alternative to pekko-http-spray-json, we can switch these usages to the alternative. It does feel like we should use Apache Pekko maintained libs for these use cases.

Some perf comparisons: https://plokhotnyuk.github.io/jsoniter-scala/

[mdedetrich]

I would try and include circe, it may not be the fastest but its used heavily in the Scala ecosystem and is actively maintained. Also another thing to note about pekko-stream-circe is its a pure streaming implementation that uses jawn's AsyncParser, i.e. if you have a JSON file that is one terabyte in size it will parse the JSON content in chunks rather than serializing it all into memory at once (and likely causing a heap error).

This means that in terms of raw throughput its always going to lose compared to other JSON parsers, but it will have advantageous if you are dealing with extremely large JSON payloads (i.e. very large arrays).

[pjfanning]

@mdedetrich Any interest in adding your lib to pekko-http-circe for 1.1.0? I'm thinking of getting 1.1.0-M1 out within a week or 2 but we can get pekko-http-circe added prior to the full 1.1.0 release. Would we need pekko-streams-circe too and if so, would that be better off being added to the main pekko repo?

[mdedetrich]

@mdedetrich Any interest in adding your lib to pekko-http-circe for 1.1.0? I'm thinking of getting 1.1.0-M1 out within a week or 2 but we can get pekko-http-circe added prior to the full 1.1.0 release. Would we need pekko-streams-circe too and if so, would that be better off being added to the main pekko repo?

Yeah I am thinking that maybe splitting out pekko streams circe so the core goes into pekko-core and the http related marshallers/unmarshallers goes into pekko-http?

[pjfanning]

I'm a little bit dubious if streaming makes a massive difference when we are serializing from and/or deserializing to Scala/Java class instances that themselves require a lot of memory (large collections, etc.). I guess it helps if the JSON libs don't consume as much memory as some of the alternatives.

[pjfanning]

Yeah I am thinking that maybe splitting out pekko streams circe so the core goes into pekko-core and the http related marshallers/unmarshallers goes into pekko-http?

I agree that this is probably the most sensible approach.

[mdedetrich]

I'm a little bit dubious if streaming makes a massive difference when we are serializing from and/or deserializing to Scala/Java class instances that themselves require a lot of memory (large collections, etc.). I guess it helps if the JSON libs don't consume as much memory as some of the alternatives.

Oh it does make a difference, its just in very specific/niche scenarious where you are handling large chunks of JSON. With pekko-streams-circe, it will only parse a single chunk (i.e. subset) of valid JSON (rather than the entire entity) and feed that smaller chunk to downstream consumers and since those consumers will only be working with a smaller chunk of JSON the performance will be higher (i.e. the json being worked on will more likely to sit inside of cache lines), there is also the bonus of less memory pressure as well.

After all, pekko-streams-circe was forked and then developed myself when solving this specific problem I used to work at, we were getting JSON payloads which were essentially massive arrays that were going into many many megabytes territories.

[pjfanning]

@plokhotnyuk you wrote the akka-http-jsoniter-scala code on which pekko-http-jsoniter-scala - do you think that code can stream large inputs and outputs? Many of the other JSON libs are not purely streaming under the hood and jsoniter-scala appears to be a streaming first solution.

[plokhotnyuk]

AFAIK both those integrations of jsoniter-scala use parsing from byte arrays. Currently jsoniter-scala can handle long JSON arrays or line-feed separated JSON values in sync mode only (blocking operations because of using java.io.InputStream).

[pjfanning]

Thanks @plokhotnyuk - I'm just modifying pekko-http-jsoniter-scala to have the ByteString read by jsoniter-scala as an InputStream instead of via a byte array. Pekko 1.1 has this support while Pekko 1.0 does not.

Would it be feasible for jsoniter-scala to support parsing IndexedSeq[Byte]? Akka and Pekko ByteString classes implements IndexedSeq[Byte] so a JSON lib that can parse from Iterable, Seq or IndexedSeq of Bytes would allow us to avoid converting the ByteString to an InputStream or byte array.

[pjfanning]

@plokhotnyuk I had a better look at pekko-http-jsoniter-scala and I decided to get a ByteBuffer for the ByteString instead. This support exists in Akka and all versions of Pekko. It avoids having to clone byte arrays and jsoniter-scala can parse ByteBuffers.