Q: How do I set up Apollo Client to handle both queries/mutations and subscriptions in React?
A: You use two different links: an HTTP link for queries/mutations and a WebSocket link for subscriptions. Then wrap your React app in ApolloProvider, use hooks like useQuery for queries and useSubscription for real-time updates.
Q: What problems do GraphQL Subscriptions solve compared to polling or plain HTTP?
A: Subscriptions allow clients to receive real-time updates over WebSockets, so you don’t need to make repeated HTTP requests at intervals. This reduces server load, latency, and improves user experience.
Q: What are the security considerations in this deployment?
A: Some include: using SSH via keys rather than weak password auth, ensuring only necessary ports are open, handling secrets (e.g. in GitHub Actions), and likely using least privilege access. The blog mentions they used password auth but plan to look at SSH key auth for better security.
Q: What initial setup is required on the AWS EC2 instance?
A: The steps include launching an EC2 instance (Ubuntu OS), installing Docker, adding your user to the Docker group so you can run Docker without sudo, and configuring the server (e.g. SSH access with a key or password).
Q: How are GitHub Actions used in this flow?
A: The blog shows using GitHub Actions CI/CD pipelines so that when code is pushed to main (or PRs), Docker image is built, then deployed to the EC2 instance via SSH (or similar). This automates shipping new versions.
Q: Why containerize with Docker before deploying to EC2?
A: Docker helps package the application with all its dependencies so that it runs the same way across environments. It simplifies deployment to servers like EC2 and avoids “it works on my machine” problems.
Q: What is Rocket in Rust, and why use it for REST APIs?
A: Rocket is a web framework for Rust that makes creating REST endpoints more ergonomic. The tutorial uses it to build a REST API and then deploys that API reliably. Using Rust + Rocket ensures performance, type safety, and minimal overhead.
Q: Why use Nginx as a reverse proxy rather than letting the front/backend handle routing directly?
A: Because Nginx centralizes concerns like SSL handling, domain routing, load distribution, caching, compression. This simplifies configuration per-service, improves performance, and adds security. Also, it abstracts away individual service ports from the public.
Q: What kind of folder structure is recommended for this kind of deployment?
A: The article shows separate repos for frontend and backend, an nginx folder containing the reverse proxy configuration, and workflows (like .github/workflows/main.yml) that orchestrate building, pushing, and deploying the containers.
Q: What is SSL termination in Nginx and how is it handled in this setup?
A: SSL termination means the reverse proxy (Nginx) handles HTTPS requests from the client (decrypting SSL) and forwards plain HTTP to the backend services. In this blog, Nginx is set up to handle SSL certificates and perform SSL termination for the incoming requests.