Recap and final exam
Ten modules to move from a single function to a published assistant that anyone can try in their browser. Here is the course condensed, then the threads that run through it, then the tradeoff with the other Python demo framework covered in the previous course.
The course at a glance
| Module | The essential point |
|---|---|
| 1. Interface | gr.Interface(fn, inputs, outputs) is the entire foundation; the choice of output component controls what the user sees |
| 2. Components | gr.Image(type="pil"/"numpy"/"filepath") and gr.Audio return specific Python shapes; guard against None |
| 3. Blocks | Components inside Row/Column, wired by .click/.submit/.change; gr.State holds per-session values |
| 4. Chat interfaces | gr.ChatInterface(fn) with (message, history, ...); system prompt lives in additional_inputs |
| 5. Streaming | A generator with cumulative yield; time to first token and tokens per second decide perceived speed |
| 6. Examples and cache | Pick one success, one edge case, one failure; cache_examples trades startup time for click latency |
| 7. Queue | default_concurrency_limit=1 for heavy GPU calls; max_size refuses overflow politely; measure with hey or k6 |
| 8. Share link | share=True opens a 72-hour *.gradio.live tunnel; add auth=(user, pass) for private previews |
| 9. Spaces | app.py + requirements.txt + README.md frontmatter; secrets in Settings, never in code; free tiers sleep |
| 10. Project | A published streaming assistant composed from the nine previous mechanisms, with feedback capture and honest limits |
The threads running through the course
A Gradio demo is a function plus a shape. Modules 1 and 2 make one point that everything else builds on: gr.Interface binds a function to a page, and each component defines the exact Python object the function will receive or return. Get that shape right and the demo works on the first click; get it wrong and no amount of layout will save you. Image(type="numpy") versus Image(type="pil") is the smallest difference with the highest cost when it is wrong.
Blocks is Interface's superset, not its replacement. Module 3 introduces gr.Blocks because Interface stops scaling as soon as a demo has two functions that talk to each other. The vocabulary — components, containers, events, State — is the vocabulary of the rest of the course. Chat, streaming, feedback capture, custom themes: all of it composes with the same three ideas. Reach for Blocks the moment you write your second event.
Streaming is not a compute optimization, it is a UX optimization. Module 5 argues that the same call, split into a stream of yields, feels dramatically faster than the same call returned in one shot — because human perception of latency measures time-to-first-response, not total time. Every serious chat interface streams for that reason. Combine streaming with the queue (module 7) and you have a demo that survives a burst of traffic without silent timeouts.
Publish the way you plan to run. The share link, the Space, and the local launch differ not in features but in intent. share=True is for iteration between engineers. A Space is for a durable public URL. A local launch on 127.0.0.1 is for a debugging session. Confusing these three costs a demo down when the laptop closes, a leaked API key when a share link is scraped, or a costly cloud bill on a demo nobody visits. Choose the channel that matches the audience.
Gradio versus Streamlit
The previous course (course 38) covered Streamlit, and the two frameworks target overlapping problems from opposite directions. The distinction is worth naming so you can pick the right one for the next demo.
Gradio treats a model as a function. The primitives (Interface, ChatInterface) are shaped like the models they wrap: an input, an output, a title. That is why a Gradio demo for a classifier or a chat is ten lines. As soon as the demo becomes multi-step or has custom layout, Blocks reveals a component-and-event system that is close to a light front-end framework.
Streamlit treats a page as a script. Every user interaction reruns the whole Python file from top to bottom, with widgets remembered by key. That model is delightful for data-heavy pages — dashboards, exploratory tools, notebooks turned into apps — because you write the page as if it were a static script. It maps less cleanly to a chat with a running history, and streaming is more awkward.
The rough rule that has held for two years: model demo → Gradio, data app → Streamlit. If you build a classifier demo, a chat assistant, a transcription tool, an image generator, Gradio's shape fits. If you build a KPI dashboard, an interactive report, a spreadsheet-driven tool, Streamlit's shape fits. Both integrate with Hugging Face Spaces, both accept custom themes, both are open-source under permissive licenses. The choice is about the object being demoed, not about the framework's raw capabilities.
The final exam
The exam has 40 questions covering the ten modules: function-to-interface mapping and component types, data shapes for image and audio, Blocks layout and events, gr.State scoping, chat with system prompt, streaming semantics and cumulative yields, examples that show failure modes, cache_examples and its invalidation, queue and concurrency limits, share link exposure and authentication, Space files and secrets, hardware tiers and sleep policy, and the full project's design decisions.
Several questions present situations to diagnose: a demo that raises a shape mismatch on first upload, a chat that shows only the last token, a queue that fills up under load, a share link that has expired, a Space that ships an API key by mistake. It is judgment that is assessed, not the recitation of function signatures.
On success, your certificate of completion is issued immediately; its number is verifiable by any third party on the platform.
Take the table above and, for each row, ask yourself "how would I see that I am wrong here?". If you can say why type="pil" is not the safe default, why a stream must yield cumulatively, and why a share link is a bad answer for a client demo, you are ready. Good luck!
Final exam
Ready to validate this course?
40 questions drawn at random from the course bank · passing score 70% · verifiable PDF certificate issued immediately on success.
Start the examYou need to be signed in to your InSkillML account with an active subscription. You can also start the exam from My courses.