Week 5 Reading Questions
Question 1
🚀 You’re deploying a full-stack children’s educational app built with the Ionic framework (frontend) and a Python backend. The app runs on both mobile and web and includes AI-generated content. Based on the reading/your own research, rank the following deployment options for this app. (best fit to worst fit)
A. Vercel
B. Fly.io
C. Netlify
D. Heroku
Click to see answer
| Option | Fit for Python Backend | Fit for Mobile/Web | AI Support | Overall Fit |
|---|---|---|---|---|
| Fly.io | ✅ Excellent (native support) | ✅ Mobile/web friendly (Ionic OK) | ✅ Good for AI, Docker-supported | 🥇 Best choice |
| Heroku | ✅ Easy Python support | ✅ Decent for full-stack apps | ⚠️ Limited AI/long-running task support | 🥈 Good fallback |
| Netlify | ❌ No backend Python support | ✅ Static/mobile web support only | ❌ AI features limited | 🥉 Not full-stack ready |
| Vercel | ❌ Optimized for Node/Next.js only | ❌ Poor Ionic/mobile support | ❌ Limited for Python/AI | 🟠 Worst fit here |
Question 2
🔍 What is the first thing you should do as soon as you have deployed your application?
Click to see answer
-
Navigate to the site where your application is deployed.
-
Test all the different functionality and visuals of the application to make sure they’re consistent with what you have seen when testing locally. Sometimes there will be discrepencies and you want to burn down on them.
Question 3
🛠️ Your application works locally, but after deploying to Vercel, you’re seeing inconsistencies (differences) from your locally deployed app. Which should you try? Rank from most to least helpful. A. Check if all required environment variables are set correctly in your Vercel project settings
B. Look at Vercel’s deployment logs and serverless function logs to debug any backend errors
C. Clear your browser cache and reload the page several times
D. Confirm that you’re using NEXT_PUBLIC_ prefix for environment variables needed on the client
E. Reinstall node_modules on your local machine
F. Check for differences in how routes (especially dynamic ones like [id].tsx) are handled in production
Click to see answer
| Option | Description |
|---|---|
| A | 🔑 Missing or misconfigured environment variables are the most common cause of deployment discrepancies on Vercel. |
| B | 🪵 Deployment/serverless logs often reveal runtime errors or build failures that don’t appear locally. |
| C | 🔄 Cache can occasionally cause display issues, but it’s not the root cause of server/client-side logic discrepancies. |
| D | 🌐 If client-side env vars lack NEXT_PUBLIC_, they won’t be exposed in production, causing issues like undefined values. |
| E | 💻 Reinstalling local modules affects only local dev — irrelevant to the deployed Vercel build. |
| F | 🔁 Vercel may handle dynamic routes differently (e.g. SSR/ISR), so it’s worth confirming route behavior and fallbacks. |
Question 4
📊 You want to track how far users scroll down a page, and then trigger a custom event when they reach the bottom 25%, 50%, 75%, and 100% of the page. Which of the following best describes the requirements?
A. Google Analytics supports scroll tracking natively, so no extra setup is needed.
B. Google Analytics can track scroll depth, but only when integrated with a tag manager or custom script.
C. Google Analytics does not support scroll tracking; you must use a separate tool like Hotjar.
D. Google Analytics can support scroll tracking, but only through server-side event configuration.