Допустим, у меня есть API с конечными точками GET, такими как:
/api/customers
/api/customers?filter=buyers&sort=DESC&limit=50
/api/customers?countryCode=23&limit=50
etc
В настоящее время они соответствуют функциям pg-обещания, таким как:
getCustomers: async () =>
db.manyOrNone(
`SELECT * FROM customers`),
getFilteredCustomersByPurchases: async (filter, sort, limit) =>
db.manyOrNone(
`SELECT * FROM customers
WHERE type=$1
ORDER BY purchase_quantity $2
LIMIT $3`,
[filter, sort, limit]),
getFilteredCustomersByCountry: async (countryCode, limit) =>
db.manyOrNone(
`SELECT * FROM customers
WHERE countryCode=$1
LIMIT $2`,
[countryCode, limit]),
Но моя проблема в том, что Я создаю кучу очень похожих функций, которые кажутся довольно избыточными.
Я рассмотрел попытку создать функцию, объединяющую их все, как показано ниже:
getCustomers: async (filter, sort, limit, countryCode) =>
db.manyOrNone(
`SELECT * FROM customers
WHERE $1 IS NULL OR type=$1 AND $4 IS NULL OR countryCode=$4
ORDER BY coalesce($2, id) DESC
LIMIT $3`,
[filter, sort, limit, countryCode]),
Но похоже, что Я добавляю больше параметров, и это быстро станет кошмаром для поддержания разборчивости, особенно если я начну делать CTE, союзы и т. Д. c условно. В производстве с большим API-интерфейсом, вторая модель более подвержена проблемам с ремонтопригодностью? Я попытался просмотреть несколько руководств, и они, похоже, не фокусируются на этой конкретной проблеме c.