08:38 <FromGitter> <jrei:matrix.org> hightower2: done!

08:46 <FromGitter> <jrei:matrix.org> I've implemented custom serialization/deserialization in Crystalizer

08:48 <FromGitter> <jrei:matrix.org> I don't really know how @Blacksmoke16 has came up with something more complicated with https://athenaframework.org/Serializer/ 😅 ⏎ Or maybe that's just me because not my code

13:36 <FromGitter> <Blacksmoke16> the key difference i think is it works *after* it already deserialized the data, so you can work with JSON::Any for example and be able to easily check the data for given values and such

13:36 <FromGitter> <Blacksmoke16> versus trying to do all that while deserializing it

14:29 <FromGitter> <jrei:matrix.org> without creating a custom type?

14:29 <FromGitter> <Blacksmoke16> for custom classes and stuff you need to include a module

14:30 <FromGitter> <jrei:matrix.org> I see, for me data validation and deserialization can be separated

14:30 <FromGitter> <Blacksmoke16> that is part for allowing it to pick the right overload, and part defines a method that describes the properties that should be (de)serialized. I.e. based on the applied annotations

14:30 <FromGitter> <Blacksmoke16> they are

14:32 <FromGitter> <Blacksmoke16> are separate components so are separate modules

14:33 <FromGitter> <jrei:matrix.org> Right, there are in a different library

14:33 <FromGitter> <Blacksmoke16> yup

14:33 <FromGitter> <Blacksmoke16> so can be used independently of the other, but https://github.com/athena-framework/athena/blob/master/src/request_body_converter.cr shows how they can be used together

14:34 <FromGitter> <Blacksmoke16> did some refactoring in Athena land so you can just do like: ⏎ ⏎ ```code paste, see link``` ⏎ ⏎ now. I.e. it knows what type to deserialize based on the type restriction of the related argument [https://gitter.im/crystal-lang/crystal?at=613626fa4c7be06b79a2b9a5]

14:36 <FromGitter> <jrei:matrix.org> And then you said "versus trying to do all that while deserializing it". But we can use my lib to deserialize, then yours to validate

14:36 <FromGitter> <Blacksmoke16> yea

14:37 <FromGitter> <Blacksmoke16> but more so meant how JSON::Serializable does it all with a PullParser, so doing stuff like discriminator is harder because you might not have deserialized that property yet

14:38 <FromGitter> <Blacksmoke16> nor is it really possible to tap into if you wanted to allow dynamic skipping of a property for example

14:42 <FromGitter> <jrei:matrix.org> For discriminator, or having custom strategies like a `size` field setting the size of the next field (e.g. a string), how I see the whole thing is to have a custom type handling this, instead of supporting it natively

14:42 <FromGitter> <Blacksmoke16> for sure, having a DTO to represent that would be a much better option

14:43 <FromGitter> <Blacksmoke16> although it could be done with a https://athenaframework.org/Serializer/Annotations/VirtualProperty/ :P

14:48 <FromGitter> <jrei:matrix.org> I don't understand what's a DTO and the VirtualProperty :/

14:49 <FromGitter> <Blacksmoke16> `data transfer object`, basically can think of it as a type that is meant to be used to transfer data between systems w/o containing any business logic

14:50 <FromGitter> <Blacksmoke16> because the structure of that data is part of your API so for larger applications can make sense to decouple that from your database models for example

14:51 <FromGitter> <Blacksmoke16> virtual property just allows the return value of a method to be included in the serialized data, which could be used for dynamic data. e.g. `def count; @data.size; end`

14:56 <FromGitter> <jrei:matrix.org> I see!

14:57 <FromGitter> <Blacksmoke16> 👍

14:58 <FromGitter> <jrei:matrix.org> why Virtual Property? If I emplement that, I likely juste reuse the `@[Crystalizer::Field]` annotation haha 😄

14:58 <FromGitter> <Blacksmoke16> i guess in my case i dont have a `Field` annotation so needed something

14:58 <FromGitter> <jrei:matrix.org> I'm easily lost with all this annotations I admit

14:59 <FromGitter> <Blacksmoke16> that's what the docs are for :P

14:59 <FromGitter> <Blacksmoke16> was better than having 1 annotation with a lot of fields, at least that was my thinking when first making it

15:00 <FromGitter> <jrei:matrix.org> for DTO, a dedicated custom type can be used, implemented a serialize and deserialize, no?

15:01 <FromGitter> <Blacksmoke16> pretty much yea, can think of it as a serializable record. I.e. only getters

15:02 <FromGitter> <Blacksmoke16> makes sense for larger APIs, prob not really needed if you only have a few endpoints

15:03 <FromGitter> <jrei:matrix.org> I had this with my previous test game, the messages were object with just data fields

15:04 <FromGitter> <Blacksmoke16> exactly! then you're free to change the internal data model w/o breaking communication between systems

15:09 <FromGitter> <jrei:matrix.org> In fact, it was the simplest approach I had in mind - what was the alternatives?

15:10 <FromGitter> <jrei:matrix.org> Adding logic on the server (Crystal) side in the class messages?

15:18 <FromGitter> <jrei:matrix.org> Looking at the visitors, "dynamic" YAML and JSON parsing (to Any) are used (?!).

15:19 <FromGitter> <Blacksmoke16> hm?

15:21 <FromGitter> <Blacksmoke16> it's mainly more helpful in a like REST API context in that a REST resource does not need to mean a database table

15:21 <FromGitter> <jrei:matrix.org> https://github.com/athena-framework/serializer/blob/master/src/visitors/yaml_deserialization_visitor.cr

15:22 <FromGitter> <Blacksmoke16> but if you tightly couple the endpoint response to how a table is structured it could be an issue if you change something about that internal representation as the payload would also change

15:22 <FromGitter> <Blacksmoke16> yea, that's what i mean you're working with the already deserialized data

15:23 <FromGitter> <Blacksmoke16> not as performant compared to YAML::Serializable, but still plenty fast and a lot more flexible

15:24 <FromGitter> <jrei:matrix.org> Could have both, supporting static and dynamic

15:24 <FromGitter> <Blacksmoke16> although tbh im not super happy with the implementation, might try and refactor it one of these days

15:25 <FromGitter> <Blacksmoke16> possibly yea

15:50 <FromGitter> <jrei:matrix.org> I guess Crystalizer won't have all the advanced features you seek

15:54 <FromGitter> <Blacksmoke16> other main thing i wanted was to have the serializer be its own obj. just fits better into rest of athena that way, and makes unit testing a bit easier

15:54 <FromGitter> <Blacksmoke16> so yea, are just two diff implementations with diff goals

18:01 <FromGitter> <jrei:matrix.org> I've changed this recently

18:02 <FromGitter> <jrei:matrix.org> Now there is a Deserializer, Serializer and Format interfaces

18:08 <FromGitter> <jrei:matrix.org> It is a lot better to accept a given type to implement custom serialization of course