Zatvobor/tirexs

Consider switching to Poison

rschmukler opened this issue · 6 comments

Thank you for your work on this library, it's fantastic!

It would be nice if this library used the more feature rich and maintained devinus/poison for HTTP encoding. It also claims to be among the fastest native JSON libraries.

The big advantage that this would allow is support for searches to decode directly into structs. I envision an API as follows:

Tirexs.Query.create_resource(query, hits_as: %Person{})

Further benefits include the ability for those structs to be able to implement Poison.Encoder and Poison.Decoder to allow custom json representations.

I looked into implementing this, and there is one major problem: Poison does not support encoding lists into objects. ie. [{:_id, 5}] is not currently supported. The existing code base has a heavy reliance on this feature.

The options, if you are open to the switch, I see as follows:

  • Option A: Convert all lists to maps - This would take a lot of work but be the more performant of the two options but requires touching almost all of the code to make this change.
  • Option B: Hijack HTTP.encode to recursively convert lists into maps using Enum.into/2. This is a much easier fix to implement, but adds a performance overhead of recursively converting lists.

To me, A seems the more "correct" approach, even though it is a good deal more work. Eager to hear your thoughts.

edit Upon further thought, the query objects are generally pretty small and sent relatively infrequently... Option A is probably a safer and cleaner approach

Thanks!

You are right. We have to switch to [devinus/poison]. Let me think about further steps towards Option A.

Thanks.

I like your proposal, but still thinking about that...

@rschmukler It's a good idea, can you create some draft PR?

+1

I've been dealing with cryptic encoding issues due toDateTime structs being passed to Tirexs.

@mtwilliams How did you managed your issues with Tirexs and DateTime encoding ?

@Electron-libre Manually lowered to ISO 8601.