Api response model

[djabarovgeorge]

Hey all :)

While working on this project I noticed that it has input DTO however it is missing on convention regarding its API response DTO type (currently it is DAL entities however the client should not be aware of them), so the API could mold its output response as it like, and its clients can consume the same response type.

You can see a case of it that I noticed in the following PR
#573

Feel free to share your opinion and the ways you think we should approach this matter.

[scopsy]

So I think that we can use the @novu/shared package to host those response models with the different clients we have.
One thing we need to finalize is the convention for interface name, we can use something like:

interface IGetApplicationsResponse {

}

Where we add the Response suffix at the end of those interfaces so we can easily identify them.

A few open questions:

• How can we reduce boilerplate in case the endpoint returns an entity? (common in classic rest resources)
• Or actually just one question for me :P

[djabarovgeorge]

First of all, I agree that it needed to be located in@novu/shared and I am good with the suffix.

If you want to reuse the properties we can extendsone interface with another which may be tricky and we would need to discuss it, but in the end, I think we should have an independent interface for the response because I may be different from the entities because we would want to populate or map them in the pipeline.

[ComBarnea]

I agree with @djabarovgeorge, DTO interfaces should be independent interfaces, as DAL by design is aware of lower-level concepts. With that being said, @djabarovgeorge how do you think we can streamline the process of creation as well as the update process of said interfaces to make sure relevant direct properties are not being overlooked, and relevant related properties are available?