Integrating AI into a Website

Start with one useful interaction

Imagine a release-note editor with a “Draft announcement” button. The user supplies a few confirmed changes and receives an editable paragraph. The useful outcome is a faithful draft that takes less editing time. A chat window is optional: a focused button can fit the existing workflow better when the task has a clear beginning and end.

Define success before choosing a model. The draft should preserve the audience and feature names, avoid invented dates or prices, and remain unpublished until the user acts. Include an insufficient-information outcome. If the input is only “something changed,” asking for the actual change is more useful than manufacturing a polished announcement. Keep ordinary editing available when the AI service is unavailable.

Separate the three responsibilities

The browser collects the selected text and displays the result. Your application server establishes the user’s identity, checks access, bounds the request and calls the configured provider. The provider returns a candidate generation. Keeping this separation makes access, cost and result handling controllable independently of the model’s response.

Send the smallest necessary input. If the server already stores the release notes, send their identifier and revision instead of trusting an arbitrary client copy. Resolve the authorized content on the server and preserve which revision was summarized. Keep provider credentials out of browser bundles and public build variables. A hidden input field or a prompt asking for secrecy does not protect a secret.

Make the application endpoint explicit

A small contract might accept a note ID, revision and requested tone, then return a request ID, source revision and draft. Validate tone against an allowed set rather than forwarding arbitrary tool definitions or provider configuration from the browser. Reject missing or inaccessible notes before sending their text to the provider; include a useful response for a revision conflict.

The browser must check both the HTTP outcome and the application result. Fetch does not reject its promise merely because the server returns a status such as 404 or 429. Check the response status, parse the documented body safely, and handle an incomplete or invalid generation as a failure. A successful HTTP exchange does not establish that the draft is complete, faithful or ready to publish.

POST /api/announcement-drafts
Request: { noteId, revision, tone: "plain" }
Success: { requestId, sourceRevision, draft }
Possible failures: invalid_input, forbidden, revision_conflict,
                   usage_limit, unavailable, invalid_generation

The server supplies trusted instructions and provider credentials.
The response creates a draft only; publishing is a separate action.

Keep a draft attached to its source revision

Suppose generation starts from revision 1, then the user edits the notes to revision 2 before the result arrives. The old draft may be well written but no longer describes the current notes. Keep the source revision with the request and result; present an outdated-result state instead of quietly inserting it into the current editor.

This dependency-free simulation runs in Node.js or a browser console. It models only the application decision after a response arrives: no timers, network or AI are involved. The assertions show that the current revision is accepted, an outdated revision is not, and a provider failure is not mistaken for an empty successful draft. In a real UI, separately guard concurrent requests and component disposal.

function draftView(currentRevision, result) {
  if (!result || result.kind !== 'complete') {
    return { state: 'error', draft: null };
  }
  if (result.sourceRevision !== currentRevision) {
    return { state: 'outdated', draft: null };
  }
  if (typeof result.draft !== 'string' || !result.draft.trim()) {
    return { state: 'error', draft: null };
  }
  return { state: 'ready', draft: result.draft.trim() };
}
const complete = { kind: 'complete', sourceRevision: 1, draft: 'CSV export is available.' };
const cases = [
  [1, complete, 'ready'],
  [2, complete, 'outdated'],
  [1, { kind: 'failed' }, 'error'],
  [1, { ...complete, draft: ' ' }, 'error'],
];
for (const [revision, result, expected] of cases) {
  if (draftView(revision, result).state !== expected) throw new Error('Wrong draft state');
}
console.log('4 draft-state checks passed');

Make every state understandable and accessible

Show when generation is pending, when a draft is complete and when the request failed. Preserve the user’s notes after failure and offer a bounded retry. If streaming, label partial text as provisional; a stopped stream can look like a finished sentence even when important qualifications are missing. Do not automatically publish or replace the user’s own edits as tokens arrive.

Use a real labeled button, a labeled input or textarea, and a visible status message. A polite live region can announce completion or failure without moving keyboard focus; announcing every token can overwhelm a screen reader. Keep the preview readable on narrow screens and allow normal keyboard editing. Render generated content as text by default; rich HTML requires a deliberate sanitization policy and safe link handling.

Bound cost and recover from failures

Limit input size, output size, concurrent work and per-user usage on the server. Set a deadline for provider work and a clear client timeout state. Aborting the browser request may stop local waiting without guaranteeing that the provider stopped computing. Repeating generation can incur another charge, so avoid automatic unbounded retry loops and distinguish a user quota from a temporary provider failure.

Record request ID, duration, result category and usage information sufficient to investigate problems. Avoid unrestricted logs containing release notes, credentials or private drafts. Decide how long drafts and provider-side data should be retained under the actual service arrangement. Keep a switch that disables generation while preserving the ordinary editor, and compare prompt/model changes on saved representative notes before release.

Test the whole interaction, then assess value

Start with fixed local responses to test success, invalid shape, failure, outdated revision and inaccessible notes. Then test the real backend with a safe account and fictional content. Confirm access controls by trying a note belonging to a different test user. Check keyboard operation, status announcements, mobile layout and the ability to keep editing when generation fails.

Evaluate the drafts separately from transport behavior. Use notes with missing dates, conflicting audience statements, no user-visible change and deliberately irrelevant text. Compare every factual clause with the source. Track unsupported claims and useful abstentions as well as latency. A technically reliable endpoint that produces misleading announcements has not met the feature’s purpose; a good demo on one note is not enough evidence to roll out broadly.

Sources & further reading

Primary references for the concepts in this guide. Examples and exercises are illustrative; verify provider-specific behaviour against the version you use.

• MDN: Using Fetch
• MDN: Live-region announcements
• OWASP: REST security