[FEATURE] Proposal to add methods to serialize the output of documents prior to delivering to end user client

Goal

Add serialization methods to output Items/Documents in one or more formats to aid in adding, removing, or modifying information prior to output to an end user or other internal methods.

Based on this package for serializing Sequelize Documents: https://github.com/hauru/sequelize-to-json

Proposed API

Model.addSerializer(name, options)

Configuring a new serializer that can be called by name

• name - The name of this serializer
• options - A schema defining how to manipulate a given document

Model.serialize(documents: Array, nameOrOptions: String/Object/Array)

Runs an array of documents through a given serializer by name or provided schema

• documents - And array of documents belonging to this model
• nameOrOptions - One of either a name of an existing configured serializer, an array containing the names of fields that should be returned (equivalent to options.include), or an options object detailing more complex operations (see below)

Document.serialize(nameOrOptions: String/Object/Array)

Runs the given document through the named serializer or provided schema

• nameOrOptions - One of either a name of an existing configured serializer, an array containing the names of fields that should be returned (equivalent to options.include), or an options object detailing more complex operations (see below)

Options

Field	Type	Description
include	array	Field names which should be included in the serialized output of the document
exclude	array	Field names which should not be included in the serialized output of the document
postSerialize	function	A function which receives the fully serialized object and the original document to make last minute changes to the output

Example

const document = myModel.create({
  email: '[e-mail]',
  username: 'bobdole',
  firstName: 'Bob',
  lastName: 'Dole',
  password: 'testing123',
  stripeCustomerId: 'cust_m1234567890',
  status: 'ACTIVE'
});

const options = {
  include: ['email', 'username', 'firstName', 'lastName'],
  exclude: ['password', 'stripeCustomerId', 'status'],
  postSerialize: (serialized, original) => {
    serialized.isActive = original.status === 'ACTIVE';
    return serialized;
  }  
}

myModel.addSerializer('mySerializer', options);

const serialized = document.serialize('mySerializer');

console.log(serialized);

/*
  Returns:

  {
    email: '[e-mail]',
    username: 'bobdole',
    firstName: 'Bob',
    lastName: 'Dole',
    isActive: true
  }
*/

[ablankenship10]

@fishcharlie Thanks thanks! Builtin or plugin would be fine by me either way, I do see it as something that should be possible without a plugin, its always been frustrating to clean up objects from different ORMs before.

I like the idea of adding the methods under Model.serializer (and keeping document.serialize())

Model.serialize(documents: Array, nameOrOptions: String/Object/Array)

Output of this will be an array correct?

Correct, it would be an array of the serialized objects (plain objects, no longer documents). Document.serialize() also returns a plain object, no longer a document.

I forgot to mention a concept of a default serializer, so something like Model.serializer.default(name) could set the name of a default serializer to use, and automatically setting the default to the first one created. This way you could call document.serialize() without a name in most places. The only reason you would need different named schemas is for example outputting a users own user object with some sensitive information that only they should see versus outputting that same user object to another user searching for friends who doesn’t necessarily need more sensitive info or the other users account settings fields. So you could use a different named schema in that case.

Other question answers:

1. I think there are cases where straight outputting the serialized data could be useful but could come at a later date. I believe its already possible to specify which fields you want returned directly from the database so thats kinda a way to control that already. The main point of the serializer IMO is that you need to request the entire object from the database, perform some logic using sensitive data such as authenticating the user with their password, and then output a cleaned version in the API response.

2. The other main feature that library has is being able to deep serialize joined documents (the assoc option), so if your user had a field user.contacts where contacts was a list from another table, you could also define rules on how to serialize that document at the same time. I’m not familiar enough with Dynamo yet if that case is relevant or if they have any kind of join support, or if you’ve built in sorta pseudo-joins here. Basically we could just filter through all the fields and if any of them are other document instances, just also call serialize on them.

3. See my second comment above on that, and checkout Attribute Lists here: https://github.com/hauru/sequelize-to-json#attribute-lists. Basically they have these catch all attributes you can put in to either include or exclude several fields at once. The case where you would need to use both include and exclude at the same time is if you were to use one of those catch alls that included a group of fields but you also want to exclude one of them in the group.

[github-actions[bot]]

This issue is stale because it has been open 7 days with no activity. Remove stale label or comment or this will be closed in 3 days.