Databases and external services fit into the request path as separate systems that server-side code may call while handling a request; they are not automatically or directly accessed by the browser’s original request.
Learning Question
When a web request reads or changes data, where does the database or another service enter the path?
The browser usually does not talk directly to the database.
The browser sends a request to server-side code. Server-side code may then decide to query a database, write to a database, call another service, publish a message, or do none of those things.
The first mental model is:
The request reaches application code first; application code may then initiate separate data or service operations.
Database Access Is a Server-Side Operation
In a typical server-backed web application, database access happens from the server side.
The server application may have:
- database connection configuration
- credentials or secrets
- network access to the database
- query builders or ORM models
- transaction logic
- validation and authorization checks before querying
The browser should not receive raw database credentials or direct database network access.
When the client asks:
GET /api/itemsthe server might run:
select items from database where user is allowed to see themThat database query is a new operation initiated by server-side code. It is not the original browser request traveling into the database unchanged.
The Database Has Its Own Protocol and Boundary
A database is usually a separate process or managed service.
The server communicates with it using a database protocol, driver, client library, or HTTP API depending on the database system.
For example:
browser
-> HTTP request
-> application server
-> database query over database connection
-> database response
-> application server
-> HTTP response
-> browserThe browser-to-server request and the server-to-database query are different communications.
They may use different:
- protocols
- ports
- credentials
- permissions
- data formats
- trust boundaries
- error models
This separation matters for both security and debugging.
Server Code Translates Request Data Into Data Operations
The request usually does not map directly to a database query.
Application code translates request data into a controlled operation.
For example:
request path: /api/items/42
authenticated user: user 7
server decision: user 7 may read item 42
database query: fetch item 42 where owner or permission allows accessThe path parameter 42 is external input.
It becomes a database identifier only after server code validates it, checks authorization, and builds a database operation.
Without that server-side control, a user could ask for arbitrary data just by changing URLs or request bodies.
ORMs and Query Builders Are Server-Side Tools
An ORM or query builder may make database access look like ordinary object operations in server code.
For example:
const item = await db.item.findUnique({ where: { id } });This is still not a local memory lookup if db represents a database client.
It is server-side code initiating communication with another system.
The database client library may serialize a query, send it over a connection, wait for a result, parse the result, and return a server-side object.
The object returned to application code is a representation of database data in the server runtime.
It is not the database row itself moving into the process as live database memory.
Transactions Belong to Data-System Work
Some request handlers need several data changes to succeed or fail together.
That may require a database transaction.
For example:
create order
decrease inventory
insert payment recordThe server application may wrap these operations in a transaction so the database preserves consistency.
The browser does not manage that transaction directly.
The request may ask the server to perform an operation, but the server and database decide the transactional behavior according to server-side code and database rules.
External APIs Are Separate Requests
Application code may call external services while handling the original request.
Examples:
- payment processor
- email service
- authentication provider
- search service
- object storage
- AI API
- internal microservice
These calls are new network operations.
The path may become:
browser request
-> application server
-> external service request
-> external service response
-> application server response
-> browserThe original browser request does not directly become the external API request. The server constructs a new request with its own URL, headers, credentials, body, timeout, and error handling.
Background Work May Outlive the Request
Some handlers do not complete all work before returning a response.
They may enqueue background work:
- send email later
- process image upload later
- generate report later
- publish event to message broker
- start asynchronous job
In that case, the request handler may return a response after scheduling work, not after all work finishes.
The browser receives the response to the original request. Background workers may continue independently.
This is another reason not to equate “request completed” with “all related system work completed.”
Common Misunderstandings
”The frontend gets data from the database.”
Usually, the frontend gets data from a server response. The server may have obtained that data from a database, but the browser did not directly query the database.
”The API endpoint is the database table.”
An API endpoint is a server-controlled interface. It may read from one table, many tables, a cache, an external service, or no database at all.
”Changing the request body changes the database directly.”
The request body is input. Server-side validation, authorization, and business logic decide whether any database change happens.
”A server-to-service call is just an internal function call.”
If the service is a separate process or machine, the server is making another network request. It may look convenient through a client library, but it still crosses a boundary.
What This Chapter Does Not Explain Yet
This chapter explains where data systems and external services fit in the request path.
It does not teach SQL, database indexing, transaction isolation, ORM design, message brokers, microservice architecture, or API integration patterns in full.
The goal is the boundary: databases and external services are separate systems called by server-side code, not direct extensions of the browser request.
Core Mental Model
Keep these operations separate:
- Browser sends HTTP request to server.
- Server code validates, authenticates, and authorizes request-derived input.
- Server code creates database queries or external service requests when needed.
- Databases and services respond to the server.
- Server code turns the result into an HTTP response for the browser.
The diagnostic question is:
Is this data operation part of the original client request, or a separate operation initiated by server-side code?
Final Summary
Databases and external services are downstream systems that server-side code may use while handling a web request.
The browser sends a request to the server. The server decides whether to query a database, call another service, schedule background work, or return without doing any of those things.