October 13, 2026
The original system for which this rewrite is based upon was built upon Java/Spring and Oracle, a fairly common stack at that time. The server handled UI rendering as well as state management and business logic. There was no Angular, React, or Vue at the time. This effort briefly preceeded Microsoft's XMLHTTP, and the browser HTTP Fetch API we all take for granted today. I would equate that to the technical equivelent of the dark ages.
Today in contrast, is a different world.
As if this is an enterprise app, decision was made to use a persistent store. This is a proven approach with decades of proven reliability. Foriegn key constraints work. I default to this approach. I am fascinated with NoSQL options, however I think you really need to prove out a use case for that approach. During a past role I was able to work with a MongoDB based approach. That introduced a weird set of challenges I won't address here. It was my impression that the development team chose that approach for 'speed of development' purposes. I believe that though process is a mute one at this point as agent assisted development reduces any potential small gain from utilizing NoSQL options. Lack of a schema can prsent some interesting problems.
I work primarily with React and Angular. I don't operate under a particular prejudice. Each has it's own merits and drawbacks. All to often, I find younger developers fixated on a given framework. They come, they go, time passes, each with it's own benefits and drawbacks. I have worked a lot with React, comfortable with it, get's the job done. It provides a lot of possibilities for UI optimization. To be honest, we won't really need that here as this is an enterprise app, not responsbile for supporting a high number of users.
As per the backend, my original effort as of two years ago was an attempt at producing both Java/Spring and Node/Express stacks. Point being, demonstrate how common concepts are applied in both. I have back off of that approach during this most recent iteration and have focused on agentic driven efforts.
This is another point where I am not strongly opiniated, I am comfortable with both. I have spent over a decade in Java. With the relatively recent introduction of lower level threading and async capabilities, this has closed the performance gap with what Node has offered from day one.
I am utilizing REST here, with GraphQL as a popular option. There seems to be a strong series of opinions between the two options. I think the younger generations seem to get caught up in this debate. There are pros and cons to each. I am rolling with REST here as it is a proven approach, I have worked a lot with it, and it provides exactly what we need here.
GraphQL isa perfectly viable option here as well. An interesting excersize would be to implement backends in each, time does not permit me. I havd a recent interview where the company appeared to be fixated on the fact I had not used GraphQL in a production environment. Honestly, I spent a day or two playing around with it. Easy to pick up, low effort for my level of experience. Kinda threw a red flag that this might be the right role for me if they could not understand that someone can pick that up and hit the ground running.
So one thing I find that has worked though my career that has definately worked is a consistent exception handling strategy. I throw custom exceptions whenever possible, and establish a global exception handler for consistent exception codes sent back to the server.
It is important to send back correct HTTP status codes when working with REST. Any attempts to send back calls status information in the response body should be considered anti patterns. In my experience, this is indicative of projects where hacks are hidden trhoughout the codebase. In one case, I found a central piece of code deep in an React framework that had to perform three conditional cheks in order to determine if the call had actually failed. I was able to locate this while troubleshooting a production issue, 'nuff said'.
Special detail was applied to 404 exception codes. When a request for an entity that does not exist is made, an exception is thrown server side for which is ultimately handled by the global exception handling logic. Ultimately an 404 exception is returned, however an additional header element is included allowing the client to differentiate between and actual bad request for an endpoint that does not exist vs a request to a valid endpoint for a record that does not exist. There might be a little room in the HTTP spec to provide a new code to avoid that work around in the future...
The original application was a monolith. Challenges there we total downtime and a lot of testing between deployments. I have decomposed the application into a series of independently deployable services. I would be hard pressed to call this a micro service application, as all services share a common persistent store. As per the UI, I am expirimenting on establishing a project structure that