You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of our TypeScript rewrite a few years ago, the codebase introduced the idea of "private" types and "public" types - private types being types used exclusively within the codebase and not exposed to any client, and public types being types exposed to a client (most commonly via. an API response). For example, FeedbackModel would be a private type, and PublicFeedback would be its corresponding public type. We have this distinction of private vs. public to give the developer control over what data should be visible to the client via. API response, and in the future, to have public data types exclusively be exported via. a types package for the frontend codebase to use.
During our TypeScript rewrite, we had the mapping of private types to public types located in the service layer of the codebase (e.g., here in EventService). This issue proposes to move this mapping from the service layer to the API layer. This pattern is more ideal since the public type is a concept specific to the API layer (since it defines the structure of the responses of the API to the client), so it should be used only in the API layer. An initial effort has been made to have new services keep the mapping away from it and within the API layer (e.g., here in ResumeService), but since we do still have remnants of services returning the public type (as linked earlier), the mix of patterns can be confusing and something that should be solidified to reduce future confusion.
The text was updated successfully, but these errors were encountered:
As part of our TypeScript rewrite a few years ago, the codebase introduced the idea of "private" types and "public" types - private types being types used exclusively within the codebase and not exposed to any client, and public types being types exposed to a client (most commonly via. an API response). For example,
FeedbackModel
would be a private type, andPublicFeedback
would be its corresponding public type. We have this distinction of private vs. public to give the developer control over what data should be visible to the client via. API response, and in the future, to have public data types exclusively be exported via. a types package for the frontend codebase to use.During our TypeScript rewrite, we had the mapping of private types to public types located in the service layer of the codebase (e.g., here in EventService). This issue proposes to move this mapping from the service layer to the API layer. This pattern is more ideal since the public type is a concept specific to the API layer (since it defines the structure of the responses of the API to the client), so it should be used only in the API layer. An initial effort has been made to have new services keep the mapping away from it and within the API layer (e.g., here in ResumeService), but since we do still have remnants of services returning the public type (as linked earlier), the mix of patterns can be confusing and something that should be solidified to reduce future confusion.
The text was updated successfully, but these errors were encountered: