Lesson 1.1
What a proxy does
The simplest gateway: take a request, forward it, return the answer. What 'forwarding' really involves.
A doorman who runs the errand for you.
Picture a hotel. You hand a note to the doorman at the front desk and ask him to deliver it to a shop down the street. He carries it over, waits for the reply, and brings the reply back to you. You never walk to the shop. You only ever talk to the doorman.
That is a proxy: something that stands between you (the client) and the place you actually want to reach (the server), passing your request along and handing the answer back. The gatekeeper monk at our gate is exactly this doorman. Every traveler talks to him, not to the rooms behind the gate.
More precisely, the gateway is a reverse proxy. The everyday kind of proxy sits in front of you and reaches out to the wider world on your behalf. A reverse proxy sits in front of the servers and answers on their behalf. The provider (OpenAI, Anthropic, Google) is the shop. The gateway is the desk you call instead.
A proxy stands between client and server and relays the request both ways. Our gateway is a reverse proxy: it sits in front of the providers and speaks for them.
"Just forward it" hides three jobs.
Forwarding sounds like a single move: receive a request, send it onward, relay the response back. It is. But even the plainest proxy has to get three small things exactly right, or the call breaks.
Carry the request body faithfully.
The model, the messages, the settings the client sent are what the provider needs to answer. The proxy passes that payload through unchanged.
Attach the provider's key, not the client's.
The client authenticates to the gateway. The gateway authenticates to the provider with its own secret key. The client never sees or holds the provider key. Swapping in the right key is the proxy's job.
Return the response unchanged.
Whatever the provider replies, the body and the status code, comes back to the client as-is. The client should not be able to tell a proxy was in the path at all.
That third point is the whole contract of a plain proxy: be invisible. If the answer that reaches the client differs from what the provider sent, the proxy has changed the meaning of the call, and that is a bug until you choose to do it on purpose later.
One call, walked through.
Say the client sends a chat request to the gateway. It calls the gateway's own address, with the request body it would have sent the provider:
Authorization: Bearer <client's gateway key>
{ "model": "gpt-4o", "messages": [ ... ] }
The gateway takes that same body and sends it to the provider's real address, but swaps the key for its own provider secret:
Authorization: Bearer <gateway's OpenAI key>
{ "model": "gpt-4o", "messages": [ ... ] }
The provider answers. The gateway hands that answer straight back to the client. Same body in, same body out, only the destination and the key changed in the middle.
The client talks to one address and holds one key. The gateway maps that to the provider's address and the provider's key. The client never touches a provider secret.
Why bother, if it just forwards?
A proxy that only relays calls looks like it adds nothing. Its value is not in what it changes; it is in where it sits. Every request now flows through one place you control.
One address for your whole app to call. One place to write a log line for every request. One place to keep the provider key, instead of pasting it into every service. And one place to add everything that comes later in this course: retries, routing, caching, budgets. None of those would have a home if calls went straight from your app to the provider.
So the plain proxy is not the feature. It is the foundation the features bolt onto. Build the door first; decide what the doorman does next later.
Key takeaways
A proxy stands between client and server and forwards both ways; our gateway is a reverse proxy, speaking for the providers behind it.
Even the plainest proxy must carry the body faithfully, swap in the provider's key (never the client's), and return the response unchanged.
The value of even a do-nothing proxy is the single point of control: one endpoint, one log, one place to add every feature that follows.