React and Node.js Architecture: Where Responsibilities Belong

For this editor, a reasonable starting design is one Node.js application with separate modules for records, permissions, and activity history. Each module exposes the operations other modules need. This is often called a modular monolith: boundaries are explicit in the code, while deployment remains shared.

A folder called services is not a boundary by itself. If every handler can update every table and bypass the record module's rules, the application still has tangled ownership. Describe which module may change a record and which operation callers must use. A shared deployment makes this arrangement easier to change while the product requirements are still becoming clear.

React needs local state for an unsaved title, the selected tab, and whether a save is in progress. The loaded record is server data with a different owner and lifetime. If a background refresh replaces the editor's draft on every fetch, a user's unsaved work can disappear even though the data-fetching code is behaving as configured.

Choose when the draft starts, when it resets, and what happens if newer server data arrives. Derive simple display values instead of keeping duplicate state that can disagree. In this example, a dirty indicator can compare the draft title with the version originally loaded into the editor; it does not need a second independently maintained flag.

The HTTP boundary establishes the caller, checks access to the target record, and validates the request shape and size. A disabled save button can improve the interface, but a direct request can bypass it. The record module then applies the update policy and returns an outcome the client understands.

Keep the authority to choose the workspace in trusted authentication and authorization context. A workspace identifier received in a URL or body can identify a requested resource; it does not prove membership. Database queries must be scoped to the authorized record. Sharing TypeScript contracts between frontend and backend is useful, but runtime validation is still necessary at the network boundary.

Load a record with a version, then submit that expected version with the change. The server can perform an update conditioned on both the record identity and the expected version, incrementing the version in the same operation. If no eligible row is updated, the application must determine whether the record changed, disappeared, or is no longer accessible under its policy.

Do not first check the version in one query and then update unconditionally in another; another edit can occur between them. A version conflict should preserve the user's draft and offer a way to compare or reload. The example response union makes that distinction visible to the UI, while the database operation is responsible for enforcing it.

If a record update and its audit entry must always agree, write them in one database transaction. An email or webhook belongs to a different failure boundary: a database rollback cannot unsend a message. Decide whether a delayed notification is acceptable and how an unsuccessful delivery will be retried.

For delivery that must survive an application restart, a possible design records pending work in the same transaction as the update, then lets a dispatcher deliver it. That pattern adds its own retry and duplicate-handling responsibilities. A best-effort notification may need less machinery; the product's delivery requirement should determine the choice.

Node.js can coordinate asynchronous requests, but CPU-heavy synchronous work still occupies its event loop. A large export or document-processing operation may need a separate execution path. Measure the time spent computing, waiting for the database, and waiting on external services before treating every slow request as the same problem.

A durable job and a worker thread solve different concerns. A job records work that should survive a restart; a worker thread can move suitable CPU work away from the main JavaScript thread. Neither automatically supplies the other. Start from the required lifetime and resource profile, then choose the smallest mechanism that meets both.

Splitting a module into a service can become useful when it needs independent deployment, resource scaling, or ownership. It also introduces network failures and distributed data changes. A small API boundary inside one application gives you a place to make that split if evidence later supports it.

Before adding a service, explain the constraint that the existing deployment cannot meet and how the new boundary resolves it. For the CRM editor, verify saved updates, invalid titles, authorization failures, concurrent edits, and retained drafts first. Those behaviors are more useful evidence of architecture quality than a diagram containing many runtime boxes.