u/Getch_2067

hey everyone,

before I start, please go easy on me. I'm about a year and a half into c#/.NET and considering myself junior to mid-level dev.

I'm working on a project using fastendpoints and vertical slice architecture, and I'm hitting a bit of a boilerplate wall with lookup tables/entities like payment methods, marital statuses, genders, etc which are almost always just an id and name used to populate dropdowns in the frontend.

right now, creating a separate endpoint, request/response dto, data fetching for every single lookup table creates a lot of repetitive code and feels kinda overkill.

specially with layered architecture, creating controllers, services, repos, etc for every lookup entity and injecting them in program.cs.

I'm considering consolidating this into a single generic feature slice with a route like GET /api/lookups/{type} and map the {type} string to the corresponding database table in the handler.

but before I do that , I wanted to get your thoughts on the pros and cons of this approach.

EDIT: thanks for the quick replies, everyone. but my question wasn't clear enough for some of you so here's a more detailed explanation:

the tables are used to enforce data integrity and avoid user spelling errors, and some are used for business logic in the backend. the frontend fetches these for dropdowns, and the chosen id is stored as a foreign key for the main domain tables.

the database design looks something like:

1. lookup tables(the ones i want to consolidate) which are simple Id/Name tables.
   Example: EducationLevel table: [{id:1, name:"BSc"},{id:2, name:"MSc"}], PaymentMethod table: [{id:1, Name:"Cash"}, {id:2, name:"card"}, {id:3, name:"bank transfer}], ApplicationStatuse table:[{id:1, name:"pending"}, {id:2, name:"approved"}]

2. the main domain tables with foreign keys which reference the lookup table ids
   Example: ApplicationForm table: {id, applicantName, educationLevelId, applicationStatusId}, Payment table: {id, amount, paymentMethodId}.

i've a number of similar lookup tables and the code got repetitive. so my question is, instead of creating separate endpoints, request/response dtos, data access or slice like: GET /api/education-levels, GET /api/payment-methods, GET /api/application-statuses, i want to create one generic endpoint slice in the project like GET /api/lookups/{type}. this way the frontend calls GET /api/lookups/education-levels and the endpoint checks the route param, queries the education-level table, maps it to a generic List<LookupResponse>, and returns it. and does the same for other lookup entities.

is routing everything through api/lookups/{type} a clean to handle these simple fk dropdowns or does it hurt long term?