_blogs
// blogs / 20260626.md
// blogs / 20260626.md
Dev Log: June 26 Wrap-up
Overview
Today was a mix of performance plumbing and connecting the dots between our modules. I spent a good chunk of time making the frontend smarter about how it fetches data, and the rest of the day was spent fixing a few 'derp' moments in our backend decorators and finalizing an integration trigger.
What I Worked On
Stopping the Request Waterfall
I noticed our frontend was being a bit too aggressive with API calls. If two components on the same page needed the same resource, they'd both fire off identical requests at the same time. It’s a waste of bandwidth and puts unnecessary load on the server.
I implemented a simple request tracking mechanism in our base data service. Now, if a request is already in flight for a specific resource and set of filters, any subsequent calls will just subscribe to the existing observable. Once the data comes back, it cleans itself up. It’s one of those small changes that makes the whole app feel snappier.
// Simple map to track active observables
private activeRequests = new Map<string, Observable<any>>();
getData(resource: string, params: any): Observable<any> {
const cacheKey = JSON.stringify({ resource, params });
if (this.activeRequests.has(cacheKey)) {
return this.activeRequests.get(cacheKey)!;
}
const request$ = super.getData(resource, params).pipe(
shareReplay(1), // Share the result with all subscribers
finalize(() => this.activeRequests.delete(cacheKey)) // Cleanup when done
);
this.activeRequests.set(cacheKey, request$);
return request$;
}
Integration Triggers and 'Derps'
On the backend, I hooked up a trigger so that whenever an invoice is marked as 'Fully Paid,' we automatically notify our external integration service. It’s mostly just mapping local order data to the external payload format, but it’s a crucial step for keeping our downstream systems in sync.
I also had a classic developer moment where I was banging my head against the wall because a deal's status wasn't updating. Turns out, I was calling setState() instead of setStatus(). Total copy-paste error. I ended up refactoring that whole section to use a proper enum for deal statuses so I don't make that mistake again.
Expanding the Distributor Flow
Finally, I spent some time expanding the CRM modules to support distributor-specific views. Instead of building entirely new components, I updated the routing logic to pass the resource type through the route snapshot. This lets us reuse the same UI logic for won deals, orders, and invoices while just swapping out the data source based on whether a partner or a distributor is logged in. It's much cleaner than duplicating templates.
Wrapping Up
The deduplication logic in the service layer is definitely the win of the day. It’s one of those 'invisible' features that saves us from future headaches. Tomorrow, I’ll likely be looking into some edge cases in the distributor dashboard, but for now, I’m calling it a day.