Let's relive this project!

[falood]

Hi, I want to add official serialization for maru, I know you have had this repo, but this repo haven't update for a long time. Do you have interest to relive it? Let's discuss how to do it!

@secretworry sorry for my disturb, I notified that you fork this repo and fix warning and unittest for it. are you using it, join us!

[secretworry]

@falood Such a surprise to receive the notification. I'm very glad to offer some help. My last project heavily depends on the maru & maru_entity, but the latest one relies mainly on the absinthe, which has a more powerful serialization system. Maru entity works in the prepare-everything-before-serialization fashion, but I prefer the serialize-on-the-go fashion adopted by absinthe( or inherited in the graphql). To adopt Maru entity, I crafted a project named weaver to compose everything well before sending them to maru entity. For now, I use the absinthe itself, providing a kind of full-fledged DSL( I mean resolver, bunch things), to deal with the composing and serializing things. So, I think the absinthe is a good reference to resort to.

For me, the problem with maru_entity lies in trying to imitate the grape-entity, which from the ruby community, as the rails magic makes fetching data from DB identical to calling a field accessing method, so you don't need to pre-fetch anything( if you don't care for the performance, as most of rubyers, lol). But for elixir, here is no such a magic.

[teodor-pripoae]

Hi,

I'm sorry for the lack of activity on this repository, I didn't use Elixir much in the past year. We postponed our migration to Elixir due to lack of good libraries for our use cases (gRPC, Google Cloud, etc). Coming back to elixir this days, I can see there is better support for this libraries and we may implement some of our new services in Elixir.

Our use case for maru-entity involves very simple entities, usually not even using entity->otherEntity chains, so I'm not sure what is the better way to do it yet.

Related to prepare-everything-before-serialization vs serialize-on-the-go, I think you can do both of them using maru-entity, at least this is how we are doing in ruby. If you want serialize on the go, just point expose with on an entity and it will serialize the result returned by the object method, resulting in N+1 queries. If you want to prefetch this results, you can assign the result of prefetch inside the options and get the results from there.

Unfortunately, I don't think I will have time to adapt maru-entity to other uses cases in the near future but I can see two options:

• you can create a pull request with your needed functionality and I will try to review and merge it
• I can donate this project to elixir-maru organization and you can start adapting it to your needs

[secretworry]

@teodor-pripoae You can have a peek on how does the absinthe solve the N+1 Problem. In short, they separate the serialization into two (or more )phases, in each phrase, the serializer can either directly return the result, or optionally return a {: batch, ...} which will be aggregated to form a batch query, and then to be used to handle the batch query result. The handler can further return a {:batch, ...} to be processed by next phase.

While it's not easy to avoid the N+1 problem in maru-entity for now.

[falood]

@secretworry I'm studying GraphQL, and I agree GraphQL is the future. But I think REST won't be die in few years. I just want make REST as easy to use as GraphQL. Maru have a lot of changes from grape to fit the difference between Ruby and Elixir, I think I'll find a way to make maru-entity a good serializer for maru and Elixir. Thank you for your points about prepare-everything-before-serialization serialize-on-the-go and N+1 query, I should thinking about them clearly and look into what weaver do before restart maru-entity.

@teodor-pripoae I think there're too many things to do for restarting maru-entity, such as add docs(we can't publish a hex package without docs now), integrate Maru.Type and so on. I have sended invitation to you to join elixir-maru, very thankful if you could donate the project.

Thank you very much, guys!

[secretworry]

@falood REST having much lower adoption cost will definitely seize enough space for it to continue to stand. I think maru have done quite well on defining RESTful API(I personally like it), but I don't have a good idea on how to find a mechanism to solve the problems inherited in its way of defining queries.

Building maru-entity with dynamic ( I mean async, batch) on thought, providing resolver/provider like mechanism as fist-citizen and adopting the Maru.Type for defining types will definitely make the maru-entity a great project.

[teodor-pripoae]

Hi,

I've moved the code to elixir-maru organization, as promised:

https://github.com/elixir-maru/maru_entity

[falood]

Thanks a lot!

[falood]

Hi guys, I have finished a simple refactor version here, I changed some grammar, solved N+1 Problem and made it a concurrent serializer. @secretworry Thank you very much for your suggestion and guiding, I did it with a totally different way with absinthe, but I don't think I can finish it without your help! There're still many things to do, but I think it's time to release a new version, and upgrade instructions from v0.1.x to v0.2.0 will be finished soon. @teodor-pripoae could you please add me as an owner of https://hex.pm/packages/maru_entity? Thank you!

[teodor-pripoae]

@falood I've added you to hex.

[falood]

A new version released 🙂 Thank you.