The Problem I Kept Running Into

Every Oracle Cloud engagement has the same friction point: you know the data is in there, you know the REST API exists, but actually getting to it — authenticating, constructing the right URL, handling the response, making an edit — requires too many steps for what should be a 30-second task. Postman collections help, but they’re not shareable as a tool. Fusion UI gets you there eventually, but it’s not built for the diagnostic workflows a consultant actually runs. I wanted something purpose-built: a single interface that handles OAuth, knows the endpoint catalog, and lets you read and write Oracle Cloud data without ceremony.

One Prompt, One Direction

The build started with a specification prompt — not a wireframe, not a backlog, not a requirements document. A single, structured prompt that described exactly what I needed across four dimensions: core features, Oracle Cloud modules to support, technical requirements, and expected deliverables. I’ve pasted it verbatim below because I think the quality of this prompt is the most instructive thing in this entire post.

“I want to build a comprehensive Oracle Cloud API Assistant web application with the following requirements: [OAuth 2.0 authentication with client credentials flow, support for multiple Oracle Cloud instance profiles, AES-256 encrypted storage, auto token refresh] … [Dynamic data table — auto-generate columns from API JSON responses, handle all data types, sortable columns, global search, pagination] … [Inline editing — click-to-edit cells, track changes with visual indicators, batch editing support, submit changes via PATCH requests, auto-save edits to survive page refresh] … Please build this step-by-step, starting with project setup, then authentication, API client, data table, and finally editing features.”

What made this prompt work wasn’t length — it was structure. Four clearly delineated sections, each answering a different question: what does it do, what Oracle modules does it touch, what’s the tech stack, and what counts as done. That last part — the explicit deliverables list — is what kept the build from drifting. When you’re working across 13 development phases over two weeks, the specification is your anchor.

The Architecture Decision That Changed Everything

The most consequential decision in this build wasn’t a framework choice — it was the decision to use no backend at all. Every credential, token, and edit session is stored in the browser’s LocalStorage, encrypted with AES-256. No Node.js API server. No database. No hosting infrastructure beyond static file delivery.

For a single-user consulting tool, this is the right call. The security model is sound: AES-256 encryption means the data at rest is protected even if the browser storage is somehow accessed. The operational model is simpler: there’s nothing to maintain, nothing to patch, nothing to go down. And the deployment model collapses to a single command — push a static build to Netlify, Vercel, or GitHub Pages and you’re live in under 30 minutes. Total infrastructure cost: zero.

The tradeoff is real: this architecture doesn’t scale to multi-user or collaborative scenarios. If you need audit logging, conflict resolution, or shared sessions, you need a backend. But for a practitioner tool built to accelerate individual Oracle Cloud work, the tradeoff is clearly worth it. Ship something in 30 minutes that works, rather than spend three weeks standing up infrastructure for a tool three people will use.

Building in 13 Phases Over 10–12 Days

The build followed a clean dependency order: TypeScript type definitions before services, services before components, components before styling. This sounds obvious, but it’s the part that most rapid builds skip — and skipping it is why rapid builds turn into 6-week projects. When you define your data shapes first, everything downstream writes itself.

Days 1–2 covered the foundation: project setup with Vite, TypeScript interfaces for every data structure in the app (credentials, tokens, endpoints, table columns, edit sessions), and the encrypted storage service. Day 2–3 added the OAuth 2.0 authentication service and the Axios-based HTTP client with interceptors for token injection and auto-refresh. By end of day 3, I could authenticate against an Oracle Cloud instance and make API calls.

The endpoint registry took a full day on its own — and it was worth it. Mapping 47 endpoints across Financials, SCM, HCM, and CX forced a level of precision about Oracle Cloud’s API surface that I hadn’t needed before. Every endpoint has a category, a method, a URL pattern, a parameter definition, and a display name. That registry is what powers the dropdown selector in the UI — it’s not hardcoded strings, it’s a structured catalog.

The data table component (days 7–9, 8–12 hours) was the most complex single piece. TanStack Table v8 handles the core — sorting, filtering, pagination — but the auto-column generation logic, inline editing with change tracking, and edit session persistence required real design work. The result is a table that takes any Oracle Cloud API response, generates appropriate columns automatically based on the JSON types, and lets you click any cell to edit it, with changes tracked visually and auto-saved to survive a page refresh.

Deployment: 30 Minutes, Zero Dollars

Because the app is a pure static build, deployment is a solved problem. A single npm run build produces a deployable dist/ folder. Push it to Netlify or Vercel with one CLI command and it’s live with HTTPS, automatic CDN distribution, and a custom domain if needed. GitHub Pages works too, with a small Vite base path configuration. For teams that need it containerized, a two-stage Docker build with Nginx serves the same output behind a corporate proxy or on-premise.

The one non-negotiable on deployment: HTTPS. The app handles OAuth tokens, and serving it over HTTP — even on a local network — is not acceptable. All three recommended platforms enforce HTTPS by default. If you’re self-hosting, make sure your Nginx or Apache configuration has a valid certificate before you hand credentials to this tool.

What Was Built

• OAuth 2.0 Authentication Service — Client credentials flow with auto token refresh, AES-256 encrypted credential storage, and support for multiple Oracle Cloud instance profiles (dev/test/prod switching)
• 47-Endpoint API Registry — Structured catalog covering Financials/ERP (15 endpoints), SCM (4), HCM (6), CX/Sales (7), and supporting modules — each with method, URL pattern, parameter definitions, and display metadata
• Dynamic Data Table — Auto-column generation from any Oracle Cloud API JSON response, with sortable columns, global search, configurable pagination (10/25/50/100 rows), and type-aware cell rendering
• Inline Editing Engine — Click-to-edit with visual change tracking, batch PATCH submission, discard option, and LocalStorage-based session persistence to survive page refresh
• Zero-Infrastructure Deployment — Static build deployable to Netlify, Vercel, GitHub Pages, or Docker in under 30 minutes at zero ongoing cost
• 2,843 Lines of Documentation — User guide, architecture reference, API endpoint documentation, quickstart guide, and implementation guide

5 Things That Surprised Me

1. The specification prompt is the architecture document. I’ve always believed that good requirements drive good delivery. But this build made the relationship viscerally clear: the precision of that initial prompt determined 80% of the outcome quality. Ambiguity in the spec created the only real rework. This has direct implications for how I write SOWs and functional specs on Oracle engagements.
2. AES-256 LocalStorage is a legitimate security model — in the right context. I went into this expecting to need a backend for anything involving OAuth credentials. I was wrong. For a single-user practitioner tool, encrypted LocalStorage is not a workaround — it’s the right architecture. The constraint is scope, not security.
3. 47 endpoints forced me to actually understand Oracle’s module boundaries. I’ve implemented Fusion across ERP, SCM, HCM, and CX. But mapping the REST API surface made me confront where the module seams actually are in ways that UI-layer work never does. The endpoint catalog is now a reference artifact I use outside this tool.
4. TanStack Table v8 is the only serious choice for dynamic Oracle data. Headless architecture means I control every pixel. TypeScript-native means the type inference from Oracle’s response schemas works without ceremony. And the performance on 100-row payloads with sorting and filtering active is noticeably better than the table libraries I’d used before.
5. 10–12 days is now the honest benchmark for a full-featured internal tool. This used to be a 3-month project with a 2-person team. The constraint has shifted from engineering capacity to specification quality. That changes how I scope and price practitioner tooling in consulting engagements.

What I’m taking into the next build is the discipline of the specification prompt — not just for AI-assisted development, but as a template for how I brief any technical delivery. The teams that will benefit most from this kind of tooling aren’t the ones with the most engineering resources. They’re the ones with the clearest articulation of what they need.

Christian Guidibi
Oracle Cloud Practice Lead & AI & Futuristic Technology Consultant

Christian leads Oracle Cloud implementations and AI-enabled delivery in a consulting context. He writes about the intersection of enterprise architecture, modern AI tooling, and practical delivery at guidibi.com.

LinkedInguidibi.com

The post I Built an Oracle Cloud API Client in 10 Days — Starting With One Prompt appeared first on Guidibi.com.