{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/huggingface-co/2026-04-01-any-custom-frontend-with-gradio-s-backend/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "A few weeks ago, we wrote about [one-shotting full web apps with `gr.HTML`](https://huggingface.co/blog/gradio-html-one-shot-apps): building rich, interactive frontends entirely inside Gradio using custom HTML, CSS, and JavaScript. That unlocked a lot. But what if that's not enough?\n\nWhat if you want to **build with your own frontend framework entirely** like React, Svelte, or even plain HTML/JS, while still benefiting from Gradio's queuing system, API infrastructure, MCP support, and ZeroGPU on Spaces?\n\nThat's exactly the problem **`gradio.Server`** solves. And it changes what's possible with Gradio and Hugging Face Spaces.\n\n## What We Wanted to Build\n\n**[Text Behind Image](https://huggingface.co/spaces/ysharma/text-behind-image)** : an editor where you upload a photo, the background gets removed using an ML model, and then you place stylized text *between* the foreground subject and the background. The text appears to sit behind the person or object in the image.\n\nThis needs:\n\n- A **drag-and-drop canvas** with layered rendering (background → text → foreground)\n- A **rich control panel** with sliders for font size, weight, letter spacing, color, opacity, stroke, shadow, 3D extrusion, perspective transforms, and more\n- A **backend ML endpoint** that runs a background-removal model and returns a transparent PNG\n- **Export to PNG** on the client side\n\nThere's no way to express this UI in Gradio components. It's a full web application. But We still wanted the backend power of Gradio: queuing, concurrency management, ZeroGPU support, and hosting on HF Spaces without infrastructure headaches.\n\n## Enter `gradio.Server`\n\n`gradio.Server` extends FastAPI. It gives you the full power of FastAPI (custom routes, middleware, file uploads, any response type) while adding Gradio's API engine on top: queuing, SSE streaming, concurrency control, and `gradio_client` compatibility.\n\nHere's the entire backend for Text Behind Image:\n\n```python\nimport os\nimport torch\nfrom PIL import Image\nfrom torchvision import transforms\nfrom transformers import AutoModelForImageSegmentation\nfrom gradio import Server\nfrom gradio.data_classes import FileData\nfrom fastapi.responses import HTMLResponse\nimport spaces\n\ntorch.set_float32_matmul_precision(\"high\")\n\nbirefnet = AutoModelForImageSegmentation.from_pretrained(\n \"ZhengPeng7/BiRefNet\", trust_remote_code=True\n)\nbirefnet.to(\"cuda\")\nbirefnet.float()\n\ntransform_image = transforms.Compose([\n transforms.Resize((1024, 1024)),\n transforms.ToTensor(),\n transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]),\n])\n\napp = Server()\n\n\n@spaces.GPU\ndef segment(image: Image.Image) -> Image.Image:\n \"\"\"Run BiRefNet segmentation to produce a transparency mask.\"\"\"\n image_size = image.size\n input_images = transform_image(image).unsqueeze(0).to(\"cuda\")\n with torch.no_grad():\n preds = birefnet(input_images)[-1].sigmoid().cpu()\n pred = preds[0].squeeze()\n mask = transforms.ToPILImage()(pred).resize(image_size)\n image.putalpha(mask)\n return image\n\n\n@app.api(name=\"remove_background\")\ndef remove_background(image_path: FileData) -> FileData:\n \"\"\"Remove background from an image. Returns transparent PNG.\"\"\"\n im = Image.open(image_path[\"path\"]).convert(\"RGB\")\n result = segment(im)\n out_path = image_path[\"path\"].rsplit(\".\", 1)[0] + \".png\"\n result.save(out_path)\n return FileData(path=out_path)\n\n\n@app.get(\"/\", response_class=HTMLResponse)\nasync def homepage():\n html_path = os.path.join(os.path.dirname(os.path.abspath(__file__)), \"index.html\")\n with open(html_path, \"r\", encoding=\"utf-8\") as f:\n return f.read()\n\n\napp.launch(show_error=True)\n```\n\nThat's it. ~50 lines of Python. The model loads at startup, `@spaces.GPU` handles ZeroGPU allocation, and `gradio.Server` manages queuing and concurrency. Let's break down what's happening.\n\n### Why `@app.api()` Instead of a Plain FastAPI Route?\n\nIf this were a regular FastAPI app, you'd define a `@app.post()` route for background removal. That works, until two users hit it at once. Without concurrency management, both requests fight for the GPU, and the app crashes or returns garbage.\n\n`@app.api()` solves this. It wraps your function with Gradio's queuing engine: requests are serialized, concurrency is controlled, and on ZeroGPU Spaces, GPU allocation is handled automatically via `@spaces.GPU`. As a bonus, any `@app.api()` endpoint is also callable via `gradio_client`, so other apps or scripts can use your Space programmatically:\n\n```python\nfrom gradio_client import Client, handle_file\nclient = Client(\"ysharma/text-behind-image\")\nresult = client.predict(\n image_path=handle_file(\"photo.jpg\"),\n api_name=\"/remove_background\"\n )\n```\n\nMeanwhile, `@app.get(\"/\")` is a standard FastAPI route that serves the HTML page. Both coexist naturally because `Server` *is* a FastAPI app.\n\n### The Frontend: Pure HTML/CSS/JS\n\nThe `index.html` in this example is a self-contained ~1300-line web application. No React, no build step, no bundler. Just vanilla HTML with:\n\n- A **three-layer canvas**: background image → text layer → foreground (transparent PNG) stacked with CSS `z-index`\n- **Drag-and-drop text positioning** using pointer events\n- A **control panel** with 20+ parameters: font family (25+ fonts), size, weight, spacing, color, opacity, background fill, stroke, shadow, 3D extrusion depth and angle, rotation, skew, and full CSS perspective transforms\n- **Client-side PNG export** using `` compositing\n\nThe frontend talks to the backend using the [Gradio JS Client](https://www.gradio.app/guides/getting-started-with-the-js-client):\n\n```javascript\nimport { Client, handle_file } from \"https://cdn.jsdelivr.net/npm/@gradio/client/dist/index.min.js\";\n\nconst client = await Client.connect(window.location.origin);\nconst result = await client.predict(\"/remove_background\", {\n image_path: handle_file(file),\n});\nforegroundLayer.src = result.data[0].url; // transparent PNG\n```\n\nThis is the key part: by using the Gradio JS client rather than a raw `fetch()` call, the frontend goes through Gradio's queue. That means concurrency is managed, GPU requests don't collide, and you could even show queue position or progress to the user. Everything else, text rendering, layer compositing, export, happens in the browser.\n\n## What This Unlocks\n\nHere's what was **not possible** before `gradio.Server`:\n\n| Before | After |\n| ------------------------------------------------------ | -------------------------------------------- |\n| Custom UI meant leaving Gradio entirely | Custom UI *with* Gradio's backend engine |\n| No way to serve static HTML from a Gradio app | `@app.get(\"/\")` serves anything |\n| `gradio_client` only worked with Gradio component apps | `@app.api()` endpoints are client-compatible |\n| Choosing between Gradio's infra and design freedom | You get both |\n\nWith `gradio.Server`, **Gradio doubles as a backend framework, use its UI system when you want it, bring your own frontend when you don't.**\n\nIf you want Gradio's UI, you can use `gr.Blocks`, `gr.Interface`, `gr.ChatInterface`. If you want your own UI, use `gradio.Server` and bring whatever frontend you like. Either way, you get Spaces hosting, API queuing, `gradio_client` access, the full HF ecosystem, and more.\n\n## Try It\n\nThe app is live on Spaces: **[ysharma/text-behind-image](https://huggingface.co/spaces/ysharma/text-behind-image)**\n\nUpload any photo with a clear subject, and start layering text behind it. Try the 3D extrusion, perspective tilt, and stroke effects, they combine nicely.\n\n## What's Next\n\nThis post covered the core idea: `gradio.Server` lets you pair any frontend with Gradio's backend. There's more to explore, including **MCP tool registration** with `@app.mcp.tool()`, **SSE streaming** for real-time updates, **batch processing**, and patterns for building multi-page apps with shared state.\n\nWe'll dig into those in a follow-up post. Stay tuned.\n\n## Recommended reading\n\n- Docs: [gradio.Server](https://www.gradio.app/main/docs/gradio/server)\n- Guide: [Server mode](https://www.gradio.app/guides/server-mode)\n", "authors": [], "captured_at": "2026-10-04T12:50:30.804479567+00:00", "category": "ai", "content_html": "

A few weeks ago, we wrote about one-shotting full web apps with gr.HTML: building rich, interactive frontends entirely inside Gradio using custom HTML, CSS, and JavaScript. That unlocked a lot. But what if that's not enough?

\n

What if you want to build with your own frontend framework entirely like React, Svelte, or even plain HTML/JS, while still benefiting from Gradio's queuing system, API infrastructure, MCP support, and ZeroGPU on Spaces?

\n

That's exactly the problem gradio.Server solves. And it changes what's possible with Gradio and Hugging Face Spaces.

\n

What We Wanted to Build

\n

Text Behind Image : an editor where you upload a photo, the background gets removed using an ML model, and then you place stylized text between the foreground subject and the background. The text appears to sit behind the person or object in the image.

\n

This needs:

\n\n

There's no way to express this UI in Gradio components. It's a full web application. But We still wanted the backend power of Gradio: queuing, concurrency management, ZeroGPU support, and hosting on HF Spaces without infrastructure headaches.

\n

Enter gradio.Server

\n

gradio.Server extends FastAPI. It gives you the full power of FastAPI (custom routes, middleware, file uploads, any response type) while adding Gradio's API engine on top: queuing, SSE streaming, concurrency control, and gradio_client compatibility.

\n

Here's the entire backend for Text Behind Image:

\n
import os\nimport torch\nfrom PIL import Image\nfrom torchvision import transforms\nfrom transformers import AutoModelForImageSegmentation\nfrom gradio import Server\nfrom gradio.data_classes import FileData\nfrom fastapi.responses import HTMLResponse\nimport spaces\n\ntorch.set_float32_matmul_precision("high")\n\nbirefnet = AutoModelForImageSegmentation.from_pretrained(\n    "ZhengPeng7/BiRefNet", trust_remote_code=True\n)\nbirefnet.to("cuda")\nbirefnet.float()\n\ntransform_image = transforms.Compose([\n    transforms.Resize((1024, 1024)),\n    transforms.ToTensor(),\n    transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]),\n])\n\napp = Server()\n\n\n@spaces.GPU\ndef segment(image: Image.Image) -> Image.Image:\n    """Run BiRefNet segmentation to produce a transparency mask."""\n    image_size = image.size\n    input_images = transform_image(image).unsqueeze(0).to("cuda")\n    with torch.no_grad():\n        preds = birefnet(input_images)[-1].sigmoid().cpu()\n    pred = preds[0].squeeze()\n    mask = transforms.ToPILImage()(pred).resize(image_size)\n    image.putalpha(mask)\n    return image\n\n\n@app.api(name="remove_background")\ndef remove_background(image_path: FileData) -> FileData:\n    """Remove background from an image. Returns transparent PNG."""\n    im = Image.open(image_path["path"]).convert("RGB")\n    result = segment(im)\n    out_path = image_path["path"].rsplit(".", 1)[0] + ".png"\n    result.save(out_path)\n    return FileData(path=out_path)\n\n\n@app.get("/", response_class=HTMLResponse)\nasync def homepage():\n    html_path = os.path.join(os.path.dirname(os.path.abspath(__file__)), "index.html")\n    with open(html_path, "r", encoding="utf-8") as f:\n        return f.read()\n\n\napp.launch(show_error=True)\n
\n

That's it. ~50 lines of Python. The model loads at startup, @spaces.GPU handles ZeroGPU allocation, and gradio.Server manages queuing and concurrency. Let's break down what's happening.

\n

Why @app.api() Instead of a Plain FastAPI Route?

\n

If this were a regular FastAPI app, you'd define a @app.post() route for background removal. That works, until two users hit it at once. Without concurrency management, both requests fight for the GPU, and the app crashes or returns garbage.

\n

@app.api() solves this. It wraps your function with Gradio's queuing engine: requests are serialized, concurrency is controlled, and on ZeroGPU Spaces, GPU allocation is handled automatically via @spaces.GPU. As a bonus, any @app.api() endpoint is also callable via gradio_client, so other apps or scripts can use your Space programmatically:

\n
from gradio_client import Client, handle_file\nclient = Client("ysharma/text-behind-image")\nresult = client.predict(\n      image_path=handle_file("photo.jpg"),\n      api_name="/remove_background"\n  )\n
\n

Meanwhile, @app.get("/") is a standard FastAPI route that serves the HTML page. Both coexist naturally because Server is a FastAPI app.

\n

The Frontend: Pure HTML/CSS/JS

\n

The index.html in this example is a self-contained ~1300-line web application. No React, no build step, no bundler. Just vanilla HTML with:

\n\n

The frontend talks to the backend using the Gradio JS Client:

\n
import { Client, handle_file } from "https://cdn.jsdelivr.net/npm/@gradio/client/dist/index.min.js";\n\nconst client = await Client.connect(window.location.origin);\nconst result = await client.predict("/remove_background", {\n    image_path: handle_file(file),\n});\nforegroundLayer.src = result.data[0].url;  // transparent PNG\n
\n

This is the key part: by using the Gradio JS client rather than a raw fetch() call, the frontend goes through Gradio's queue. That means concurrency is managed, GPU requests don't collide, and you could even show queue position or progress to the user. Everything else, text rendering, layer compositing, export, happens in the browser.

\n

What This Unlocks

\n

Here's what was not possible before gradio.Server:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
BeforeAfter
Custom UI meant leaving Gradio entirelyCustom UI with Gradio's backend engine
No way to serve static HTML from a Gradio app@app.get("/") serves anything
gradio_client only worked with Gradio component apps@app.api() endpoints are client-compatible
Choosing between Gradio's infra and design freedomYou get both
\n

With gradio.Server, Gradio doubles as a backend framework, use its UI system when you want it, bring your own frontend when you don't.

\n

If you want Gradio's UI, you can use gr.Blocks, gr.Interface, gr.ChatInterface. If you want your own UI, use gradio.Server and bring whatever frontend you like. Either way, you get Spaces hosting, API queuing, gradio_client access, the full HF ecosystem, and more.

\n

Try It

\n

The app is live on Spaces: ysharma/text-behind-image

\n

Upload any photo with a clear subject, and start layering text behind it. Try the 3D extrusion, perspective tilt, and stroke effects, they combine nicely.

\n

What's Next

\n

This post covered the core idea: gradio.Server lets you pair any frontend with Gradio's backend. There's more to explore, including MCP tool registration with @app.mcp.tool(), SSE streaming for real-time updates, batch processing, and patterns for building multi-page apps with shared state.

\n

We'll dig into those in a follow-up post. Stay tuned.

\n

Recommended reading

\n\n", "content_markdown": "A few weeks ago, we wrote about [one-shotting full web apps with `gr.HTML`](https://huggingface.co/blog/gradio-html-one-shot-apps): building rich, interactive frontends entirely inside Gradio using custom HTML, CSS, and JavaScript. That unlocked a lot. But what if that's not enough?\n\nWhat if you want to **build with your own frontend framework entirely** like React, Svelte, or even plain HTML/JS, while still benefiting from Gradio's queuing system, API infrastructure, MCP support, and ZeroGPU on Spaces?\n\nThat's exactly the problem **`gradio.Server`** solves. And it changes what's possible with Gradio and Hugging Face Spaces.\n\n## What We Wanted to Build\n\n**[Text Behind Image](https://huggingface.co/spaces/ysharma/text-behind-image)** : an editor where you upload a photo, the background gets removed using an ML model, and then you place stylized text *between* the foreground subject and the background. The text appears to sit behind the person or object in the image.\n\nThis needs:\n\n- A **drag-and-drop canvas** with layered rendering (background → text → foreground)\n- A **rich control panel** with sliders for font size, weight, letter spacing, color, opacity, stroke, shadow, 3D extrusion, perspective transforms, and more\n- A **backend ML endpoint** that runs a background-removal model and returns a transparent PNG\n- **Export to PNG** on the client side\n\nThere's no way to express this UI in Gradio components. It's a full web application. But We still wanted the backend power of Gradio: queuing, concurrency management, ZeroGPU support, and hosting on HF Spaces without infrastructure headaches.\n\n## Enter `gradio.Server`\n\n`gradio.Server` extends FastAPI. It gives you the full power of FastAPI (custom routes, middleware, file uploads, any response type) while adding Gradio's API engine on top: queuing, SSE streaming, concurrency control, and `gradio_client` compatibility.\n\nHere's the entire backend for Text Behind Image:\n\n```python\nimport os\nimport torch\nfrom PIL import Image\nfrom torchvision import transforms\nfrom transformers import AutoModelForImageSegmentation\nfrom gradio import Server\nfrom gradio.data_classes import FileData\nfrom fastapi.responses import HTMLResponse\nimport spaces\n\ntorch.set_float32_matmul_precision(\"high\")\n\nbirefnet = AutoModelForImageSegmentation.from_pretrained(\n \"ZhengPeng7/BiRefNet\", trust_remote_code=True\n)\nbirefnet.to(\"cuda\")\nbirefnet.float()\n\ntransform_image = transforms.Compose([\n transforms.Resize((1024, 1024)),\n transforms.ToTensor(),\n transforms.Normalize([0.485, 0.456, 0.406], [0.229, 0.224, 0.225]),\n])\n\napp = Server()\n\n\n@spaces.GPU\ndef segment(image: Image.Image) -> Image.Image:\n \"\"\"Run BiRefNet segmentation to produce a transparency mask.\"\"\"\n image_size = image.size\n input_images = transform_image(image).unsqueeze(0).to(\"cuda\")\n with torch.no_grad():\n preds = birefnet(input_images)[-1].sigmoid().cpu()\n pred = preds[0].squeeze()\n mask = transforms.ToPILImage()(pred).resize(image_size)\n image.putalpha(mask)\n return image\n\n\n@app.api(name=\"remove_background\")\ndef remove_background(image_path: FileData) -> FileData:\n \"\"\"Remove background from an image. Returns transparent PNG.\"\"\"\n im = Image.open(image_path[\"path\"]).convert(\"RGB\")\n result = segment(im)\n out_path = image_path[\"path\"].rsplit(\".\", 1)[0] + \".png\"\n result.save(out_path)\n return FileData(path=out_path)\n\n\n@app.get(\"/\", response_class=HTMLResponse)\nasync def homepage():\n html_path = os.path.join(os.path.dirname(os.path.abspath(__file__)), \"index.html\")\n with open(html_path, \"r\", encoding=\"utf-8\") as f:\n return f.read()\n\n\napp.launch(show_error=True)\n```\n\nThat's it. ~50 lines of Python. The model loads at startup, `@spaces.GPU` handles ZeroGPU allocation, and `gradio.Server` manages queuing and concurrency. Let's break down what's happening.\n\n### Why `@app.api()` Instead of a Plain FastAPI Route?\n\nIf this were a regular FastAPI app, you'd define a `@app.post()` route for background removal. That works, until two users hit it at once. Without concurrency management, both requests fight for the GPU, and the app crashes or returns garbage.\n\n`@app.api()` solves this. It wraps your function with Gradio's queuing engine: requests are serialized, concurrency is controlled, and on ZeroGPU Spaces, GPU allocation is handled automatically via `@spaces.GPU`. As a bonus, any `@app.api()` endpoint is also callable via `gradio_client`, so other apps or scripts can use your Space programmatically:\n\n```python\nfrom gradio_client import Client, handle_file\nclient = Client(\"ysharma/text-behind-image\")\nresult = client.predict(\n image_path=handle_file(\"photo.jpg\"),\n api_name=\"/remove_background\"\n )\n```\n\nMeanwhile, `@app.get(\"/\")` is a standard FastAPI route that serves the HTML page. Both coexist naturally because `Server` *is* a FastAPI app.\n\n### The Frontend: Pure HTML/CSS/JS\n\nThe `index.html` in this example is a self-contained ~1300-line web application. No React, no build step, no bundler. Just vanilla HTML with:\n\n- A **three-layer canvas**: background image → text layer → foreground (transparent PNG) stacked with CSS `z-index`\n- **Drag-and-drop text positioning** using pointer events\n- A **control panel** with 20+ parameters: font family (25+ fonts), size, weight, spacing, color, opacity, background fill, stroke, shadow, 3D extrusion depth and angle, rotation, skew, and full CSS perspective transforms\n- **Client-side PNG export** using `` compositing\n\nThe frontend talks to the backend using the [Gradio JS Client](https://www.gradio.app/guides/getting-started-with-the-js-client):\n\n```javascript\nimport { Client, handle_file } from \"https://cdn.jsdelivr.net/npm/@gradio/client/dist/index.min.js\";\n\nconst client = await Client.connect(window.location.origin);\nconst result = await client.predict(\"/remove_background\", {\n image_path: handle_file(file),\n});\nforegroundLayer.src = result.data[0].url; // transparent PNG\n```\n\nThis is the key part: by using the Gradio JS client rather than a raw `fetch()` call, the frontend goes through Gradio's queue. That means concurrency is managed, GPU requests don't collide, and you could even show queue position or progress to the user. Everything else, text rendering, layer compositing, export, happens in the browser.\n\n## What This Unlocks\n\nHere's what was **not possible** before `gradio.Server`:\n\n| Before | After |\n| ------------------------------------------------------ | -------------------------------------------- |\n| Custom UI meant leaving Gradio entirely | Custom UI *with* Gradio's backend engine |\n| No way to serve static HTML from a Gradio app | `@app.get(\"/\")` serves anything |\n| `gradio_client` only worked with Gradio component apps | `@app.api()` endpoints are client-compatible |\n| Choosing between Gradio's infra and design freedom | You get both |\n\nWith `gradio.Server`, **Gradio doubles as a backend framework, use its UI system when you want it, bring your own frontend when you don't.**\n\nIf you want Gradio's UI, you can use `gr.Blocks`, `gr.Interface`, `gr.ChatInterface`. If you want your own UI, use `gradio.Server` and bring whatever frontend you like. Either way, you get Spaces hosting, API queuing, `gradio_client` access, the full HF ecosystem, and more.\n\n## Try It\n\nThe app is live on Spaces: **[ysharma/text-behind-image](https://huggingface.co/spaces/ysharma/text-behind-image)**\n\nUpload any photo with a clear subject, and start layering text behind it. Try the 3D extrusion, perspective tilt, and stroke effects, they combine nicely.\n\n## What's Next\n\nThis post covered the core idea: `gradio.Server` lets you pair any frontend with Gradio's backend. There's more to explore, including **MCP tool registration** with `@app.mcp.tool()`, **SSE streaming** for real-time updates, **batch processing**, and patterns for building multi-page apps with shared state.\n\nWe'll dig into those in a follow-up post. Stay tuned.\n\n## Recommended reading\n\n- Docs: [gradio.Server](https://www.gradio.app/main/docs/gradio/server)\n- Guide: [Server mode](https://www.gradio.app/guides/server-mode)\n", "dateCreated": "2026-10-04T12:50:30.804479567+00:00", "date_created": "2026-04-01T00:00:00+00:00", "date_modified": "2026-04-01T00:00:00+00:00", "date_published": "2026-04-01T00:00:00+00:00", "description": "A few weeks ago, we wrote about one-shotting full web apps with gr.HTML: building rich, interactive frontends entirely inside Gradio using custom HTML, CSS, and JavaScript. That unlocked a lot. But what if that's not enough? What if you…", "external_url": "https://huggingface.co/blog/introducing-gradio-server", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/huggingface-co/2026/04/2026-04-01-any-custom-frontend-with-gradio-s-backend.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/huggingface-co/2026/04/2026-04-01-any-custom-frontend-with-gradio-s-backend.md" }, "id": "urn:aggr:item:bd7a337cb6f192c42bc146bdbda4f7e079151b8d", "isBasedOn": { "@id": "https://huggingface.co/blog/introducing-gradio-server" }, "mainEntity": { "@id": "https://huggingface.co/blog/introducing-gradio-server", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/huggingface-co/2026-04-01-any-custom-frontend-with-gradio-s-backend/#webpage" }, "dateModified": "2026-04-01T00:00:00+00:00", "datePublished": "2026-04-01T00:00:00+00:00", "headline": "Any Custom Frontend with Gradio's Backend", "timeRequired": "PT5M", "url": "https://huggingface.co/blog/introducing-gradio-server", "wordCount": 1013 }, "name": "Archived snapshot: Any Custom Frontend with Gradio's Backend", "preview": null, "reading_minutes": 5, "replicated_at": null, "source": "huggingface-co", "source_name": "Hugging Face - Blog", "summary": null, "tags": [], "temporalCoverage": "2026-10-04T12:50:30.804479567+00:00", "title": "Any Custom Frontend with Gradio's Backend", "url": "https://aggr.aymericbeaumet.com/items/huggingface-co/2026-04-01-any-custom-frontend-with-gradio-s-backend/", "word_count": 1013 }