#Sending enums/static values to frontend for dropdowns etc in DDD

11 messages · Page 1 of 1 (latest)

dapper axle
#

Hi there! I have a quick question regarding architecture, more than anything. Let's say I have a table called work order with a status, that can be 'open', 'closed', 'completed', which is joined from another table called Status, with its respective foreign key. In short, workOrder would have statusId 4 for example.

My question is, how do you guys handle static values like this that may or may not change? I know I can always set it up as an enum, but I was wondering how to structure it. Initially, a created a module/folder for each one, and each specific service returned the values. /status would return a list of status, /priority would return a list of priorities and so on so forth.

Is this overkill? I've also read that some (I could be wrong) create a 'reference/lookup' module/folder with getStatus, getPriority, getCategories, etc. such as /reference/status, /reference/priority.

This is ONLY for populating dropdowns and things like that, there will not ever be business logic and if there is, I'll move it to its own respective module.

Is this okay? Not okay? is it terrible? I'm not that familiar with backend best practices and I really have no one to ask 😅 any help would be appreciated!

slender phoenix
#

Hi, I'm very interested you.
That’s actually a solid approach — creating a /reference module for static lookup data (like status, priority, category) is common and totally valid. It keeps your API organized and avoids overengineering individual modules when there's no real business logic involved. Using enums is great for internal code consistency, but keeping the values in the database allows for easy updates and dropdown population without redeploying. Your current setup sounds clean and maintainable — you're on the right track! 👍

fierce osprey
#

Initially, a created a module/folder for each one

Is this overkill?

If you are creating a module per picklist type, then absolutely, it is overkill. Instead of thinking about the concrete things of each type of picklist, abstract out and think about what your module should be solving. It is a kind of picklist metadata management process, right? Because, you are not only controlling the value outcomes of picklists, but rather what the field itself should show as value to the user, also the selection values, the kind of selection, single or multiple, if picklists are related, etc., etc. all stored in the database. Picklists are one of the hardest fields to get right. 🙂

I'm working on something similar it just so happens, but with MongoDB/Typegoose. But, I'm also engineering a type system for all fields, not just picklists. Because, what you are considering for picklists can be abstracted out to all fields, not just picklists. So, I have a field-definition module and my picklist field type is related to picklist-definitions and pick-list values (selections), which are handled in one module. I'm just getting started, so I have nothing to really show from the practical side. It's mainly engineering POCs/ prototypes and what I have is totally borked at the moment. Hehehe.... 😛

What I guess I wish to say as an answer is, if you are abstracting out or rather away from enums to use database driven dynamic picklists, you should need one module, which concerns itself with picklists only.

dapper axle
dapper axle
# fierce osprey > Initially, a created a module/folder for each one > > Is this overkill? If y...

Right! That was my initial question, I was thinking that maybe if the module gets more use cases or particular business logic side effects then yes, I could move the picklists (didn't really know people called them like this 😅 ) to a particular endpoint wwith said business logic or side effects there, it felt like a little too much having 10 plus folders for this haha.

Thank you very much for the detailed answer as well! Having no senior kinda sucks in having to figure these things out yourself :/

fierce osprey
#

/status would return a list of status, /priority would return a list of priorities

@dapper axle - These would be selected by a user, right? So the UI element they use is what I'd call "selection" and also "picklist". Pull down menu is another. 🙂

dapper axle
finite otter
#

sorry a bit of topic just confused why hes doing that

hybrid isle