I wrote a sort-of serializer for nested maps (or Ecto schemas) to a JSON-API-like format which can then be serialized to JSON, and was wondering if anyone could provide some feedback on the code.
The main thing I thought was odd was the view being responsible for generating the resource structure instead of the base view (this part). I recon it’s simpler, but it requires every view to correctly generate that part of the structure to be valid JSON API. Seeing as, you’ve extracted out relationships as its own thing, seems like you might want to do the same for the rest.
I’ll also say, I question the decision to include every relationship. I think that strategy can work for very simple domains, but once you have many schemas, with many relationships, you want to be a lot more selective. You’ll constantly run into issues of needing to preload things and based on the way you’re defining relationships, you’ll also need to keep in sync actual relationships and the views to render those relationships on each view. It also appears you’re tying your API tightly to your schema, which is generally an anti-pattern.
I don’t see any real issues with the actual code you wrote. Seems well written and follows good conventions.
In case you’re not aware, there is a library that does most of this already called ja_serializer. It’s worked pretty well for me in the past.
The main reason for this is because I don’t (want to) support the actual JSON-API spec. The output is based on it, but not entirely the same. You’re right however that I could write some functions for generic JSON-API responses that can be swapped out when needed.
I don’t quite understand what you mean with this. No relationships will be included / loaded unless you specify them in when calling the render function: like on this line.
I had heard of ja_serializer before but hadn’t checked it out in detail yet. I think I’ll be able to get some inspiration from it.
Thanks again for taking the time to read through the code.