Level 5
there is no "best" way, the common way is what you want to avoid: write a new type in your frontend repo, commit it and deploy it every time you have a new notification type, the api is just a number, or s string, doesnt matter.
Nov 6, 2024
3
Level 1
Best practices for returning types/enums/ids to the frontend
I'm a dilemma.
What is the best way to return specific enum/id/types to the frontend?
Using a NotificationConfiguration table, it will be returned on a frontend configuration page.
These are my data:
data: {
finances: {
email: [
id: 1
fk_id_user: 1
notification_type: 1
notification_channel: 1
notification_enabled: true
notification_email: [email protected]
]
}
}
Ok, with a little work I can return an object with arrays. A Finance object (I will have other main objects) that have other arrays (email, sms, web) with an indefinite size of emails or other configured numbers.
So, this can help me display in the frontend (I'm not 100% sure if it's the best way), as I just use finances.email, finances.web, etc... but to create a new notification, I need to code the id/number/type or make a request to check possible notification types and notification channels.
In the backend it's just Enums, and I'm thinking about returning the name of the enum and when the API receives the post request to create a Notification Configuration, I'll just read it and store it as the id of the enum.
I know that Enum can be a column type in the database, but I'm not sure about compatibility and want to maintain best practices in the other APIs.
So what's the best way to deal with this? I can check everything using ids and configure everything manually, or make numerous requests for any possible fields, or make the configuration more user-friendly using a field name, I can return the data like this too:
data: {
finances: {
email: [
id: 1
fk_id_user: 1
notification_type: FINANCES
notification_channel: EMAIL
notification_enabled: true
notification_email: [email protected]
]
}
}
Level 1
From the point of view of API, strings.
As API consumer, what do you prefer to read? notification_type: FINANCES or notification_type: 1 ? I highly prefer to read finances that a random number that i have no idea what means.
Level 1
In general, I tend to stay away from using the enum column type in the database. See this discussion from a few months ago: https://laracasts.com/discuss/channels/laravel/managing-db-enum-columns-for-reusability-and-avoid-dry
I agree with the comments there; there is no single "best" way. When writing an API that is publicly exposed, I use strings for enums to enhance readability. But if it's only for internal development, I prefer integers to save a few bytes in requests and create a corresponding enum in TypeScript to handle conversion on the frontend.
Please or to participate in this conversation.