Where API logic belongs: database functions, middleware or application code

Moving a function closer to data can remove work from an application server while changing who owns the decision. A field validator that gradually starts deciding whether a customer may proceed becomes a business control, even if it still looks like a small optimization.

October publications offer a useful way to locate that boundary. Place a rule according to the data and authority it requires, how it can be tested and how it can be reversed. Language syntax and tool convenience come afterwards.

Four publications expose separate layers

Percona’s October 15 MySQL JavaScript discussion describes bounded functions without network, filesystem or Node.js APIs. Supabase’s October 15 middleware article describes ordered composition for Fetch handlers.

Cloudflare’s October 14 Hyperdrive investigation examines connection-state and caching correctness. Postman’s October 9 cloud performance publication describes running collection-based load tests from cloud infrastructure. None establishes a speed improvement for an arbitrary API.

Our architectural inference is to distinguish bounded value transformation, request admission and business decisions. A database function can transform a value; an entry layer can establish request context; the application can decide what that context authorizes for a specific record. A cache needs to preserve the meaning and access boundaries of the response it reuses. Each implementation still needs verification in its own stack.

Computation and authority are different

A function can normalize a phone number and return validation errors. Deciding whether to contact someone, reject a submission or ask an operator depends on process state, employee permissions and company policy. Those dependencies are harder to maintain inside a small transformation routine.

Middleware has another responsibility. It can stop a request whose identity has not been verified. A valid token, however, does not automatically authorize approval of a particular request. That decision also needs record ownership, current state and an allowed transition.

This separation does not demand a microservice for every rule. It needs clear contracts between parts of the same application: what has been checked, what value was produced and which component may decide. Otherwise reusing a convenient function can quietly broaden its authority without changing its interface.

The rollback question helps expose hidden coupling. If reverting a normalization function changes previously accepted identifiers, downstream matching may behave differently. If reverting an approval policy changes what operators can do, that is a product decision. Treating both as an ordinary utility update makes the risk difficult to review.

A hypothetical contact import

Suppose a company imports partner contacts from several sources. One row has a phone number with spaces, another resembles an existing customer, and a third belongs to a different organization. This is an illustrative design, not a reported implementation result.

The request boundary establishes the organization and permission to import. Value processing generates a normalized number and error flags. Application logic decides whether an existing contact may be updated and who should resolve a conflict. Similar names do not become permission to merge records.

Keep a stable source-row identity and a content version for repeated imports. If a new normalization rule changes the output, an operator should see why it changed rather than encounter an apparently unrelated new record. Retaining original input can help explain decisions, but that input needs the same access discipline as the rest of the customer data.

Caching a shared formatting dictionary and caching a personalized contact response are different policy choices. The latter needs access context, invalidation rules and an agreed tolerance for staleness. A faster screen does not prove that its caching policy is correct.

Measure displaced work

After computation moves into the database, the application can get faster while database work increases. Compare the whole request path, connection contention, transaction duration and failures. Otherwise an optimization can merely relocate a queue.

Include valid input, conflicts and denied operations in the workload. A clean import alone says little about the cost of problematic records. A cloud load generator can separate laptop constraints from API behavior; it cannot make an unrealistic scenario representative.

A useful release condition is that the same permissions and input produce the same business decision before and after the move. Measure performance afterwards. An intentional decision change deserves its own product acceptance criteria.

Business logic and rules develops these boundaries. The custom API project provides related engineering context. API integration planning can start with decisions and permissions before selecting where functions execute.