The initial release of JaSerializer successfully accomplishes it's mission; it serializes data to jsonapi.org format.
Roadmap:
- Solidify/determine future of the DSL.
- Better Ecto integration.
- A Phoenix view integration.
A few members of the Elixir community have indicated the DSL based approach isn't recommended. This is an exercise in embracing that critisim and seeing how much of a DSL can be removed w/o sacrificing important functionality.
Desired functionality:
- Define what attributes the serializer exposes.
- Add custom logic/presenter functions.
- Controll on a per conn/model basis what is serialized.
Definition vs Data
AMS and the existing DSL is mostly a 'descriptive' dsl. The DSL establishes how to serialize something. An alternative approach would be defining a behaviour that expects the actual data to be serialized to be returned. An example of this is the attributes/2
function in behaviour_dsl_2.ex
which expects an actual map to be returned, vs the other two examples which expect lists to be returned.
type
, location
, id
, and attributes
are examples where returning the actual data is straightforward.
However, relationships are fairly complicated and perhaps less easy to easily return as data.
Consistency
The API should be consistent for all functions. Mixing macro dsl w/ behaviour definition or definition dsl with data dsl can create confusion.
Overriding data/presenter functions
Importantly the serialization layer is the only place where the curent user (via conn) and the model are combined. This is a super important feature and means we must be able to inject values to be serialized that were not available before. It also means we should be able to restrict the attributes returned based on the user/conn.
- Relationships should just work w/o defining a custom function.
- A view version of JaSerializer that can be used in as a phoenix view.