Locomo.io

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

Ever wonder why we keep writing the same CRUD APIs over and over? Here's a controversial take: Your CRUD APIs should start generic, not specific. Yes, you read that right. Here's why this matters: Instead of creating multiple endpoints: POST /api/users POST /api/products POST /api/orders GET /api/users/:id GET /api/products/:id GET /api/orders/:id PUT /api/users/:id PUT /api/products/:id PUT /api/orders/:id DELETE /api/users/:id DELETE /api/products/:id DELETE /api/orders/:id You have one generic endpoint: POST /api/:model GET /api/:model/:query PUT /api/:model/:id DELETE /api/:model/:id "But wait!" I hear you say, "What about specific business logic?" That's where the real insight comes in - it's all about well-defined database models. Your DB models should do the heavy lifting: Validation rules? In the DB model. Computed properties? In the DB model. Business constraints? You guessed it - in the DB model. It's like switching to a declarative paradigm. Instead of spreading business logic across multiple API layers, you define it once in your models. Your API layer stays clean, focused, and most importantly - reusable. And here's the kicker - you can always add specific APIs when you actually need them. But why start there? Why write boilerplate CRUD operations for every entity when you haven't proven you need anything special? We've been implementing this approach in our projects, and the results are clear: 70% less redundant code Faster feature development More consistent API patterns Easier to maintain and test It's about separating the 'what' from the 'how' - letting your logic live once in the API layer, while your domain-specific needs are expressed through definitions in your models. Your "model" is just a definition file (JSON/TypeScript/etc) where you declare everything about an model: GET /api/:model/:query // This is the game changer Want active orders? Add a query definition. Need completed orders by region? Add another query. Want admins to see all orders but users to see only their own? Define roles per query: { queries: { activeOrders: { filter: { status: 'active' }, roles: ['admin', 'sales'] // Only admin/sales can access }, myOrders: { filter: (user) => ({ userId: user.id }), roles: ['user'] // Users see their own orders } } } The API stays generic, but your model definitions make it powerful and secure. Just ask /api/orders/activeOrders and the API knows what to return AND who can access it. What do you think? Are you still writing entity-specific CRUD APIs by default? Let's discuss! #SoftwareArchitecture #Engineering #TechLeadership #SoftwareDevelopment #CleanCode