Locomo.io reposted this
CEO at Unthinkable | Building Locomo.io | Making Software Engineering Less Redundant, More Productive
From my previous post about generic APIs - what enables us to do it? It's the separation of definition from logic. Let's talk about how this insight helps us reduce redundancy in our code. Here's what we typically write: /// ProductService 🏭 validate(data) > check if name exists checkPrice(data) > validate price > 0 getRegionTax(data) > tax calculation getFinalPrice(price, tax) > price with tax findWithInventory(id) > get stock info findForCatalog(id) > get catalog view findWithSupplier(id) > get supplier updateStatus(id) > validate transition // OrderService 🛍️ validate(data) > check items exist validateAddress(data) > verify address calculateTotal(items) > sum with tax calculateShipping(address) > shipping cost findWithItems(id) > get order items findForCustomer(id) > customer view findForAdmin(id) > admin view updateStatus(id) > validate flow // Then for Users, Inventory... We keep writing the same patterns with slight variations for EVERY entity... The key insight? Separate WHAT (your specific business rules) from HOW (the generic implementation): ProductModel = { // Your business rules stay specific fields: { name: { type: String, required: true }, price: { type: Number, min: 0 }, region: { type: String, enum: ['US', 'EU'] } }, // Complex logic stays in YOUR control computed: { finalPrice: { deps: ['price', 'region', 'discountCode'], compute: price * (1 + tax) * (1 - discount) } }, // YOUR views, YOUR way views: { search: ['id', 'name', 'finalPrice'], catalog: ['id', 'name', 'finalPrice', 'image'] } } The generic handler just handles the repetitive parts: POST /api/{entity} - creation with YOUR validation GET /api/{entity}/{view} - YOUR custom views GET /api/{entity}?filter=xyz - YOUR filters This isn't about cramming everything into models or making things generic for the sake of it. It's about keeping your business logic clear and specific while eliminating repetitive technical code. Most of our CRUD boilerplate gone and for edge cases we still can write entity specific CRUD API's. so no flexibility lost and redundant code gone. What patterns have you found to reduce boilerplate while keeping business logic clear? Will love to hear your thoughts #SoftwareEngineering #TypeScript #WebDevelopment #CleanCode #DeclarativeCode