WEB API's Lesson 40 – Career Roadmap | Dataplexa
Web APIs · Lesson 40

Career Roadmap

Map the skills you have built to real job roles, identify the portfolio projects that prove them, and chart a clear path to the next level — whether that is a first developer job, a senior role, or building your own product.

Finishing a course is the start, not the end. The 38 lessons you just completed gave you a foundation in API design, security, performance, and deployment — skills that are in demand across every layer of the software industry. What you do with that foundation in the next 90 days will determine whether it stays theoretical or becomes something you can point to in an interview and say: "I built that."

This lesson does four things: maps your current skills to the job titles that need them, identifies the portfolio projects that demonstrate those skills concretely, specifies what to learn next based on where you want to go, and gives you a 90-day action plan with specific weekly milestones. The plan is not motivational — it is tactical.

Skills You Have Now — After 40 Lessons
DESIGN AND ARCHITECTURE
REST API design from resource model to endpoint spec
HTTP methods, status codes, request and response structure
Cursor and offset pagination with correct use cases
API versioning strategies and breaking change management
Structured error responses with type, code, param, request_id
SECURITY
JWT authentication with access and refresh token patterns
bcrypt password hashing, salt rounds, timing-safe comparison
Redis rate limiting with atomic counters and correct headers
HMAC webhook signature verification and replay protection
OAuth 2.0 flow with CSRF state parameter and token encryption
PERFORMANCE AND RELIABILITY
N+1 query identification and elimination with JOINs
Gzip compression, pre-signed S3 URLs, search index sync
Idempotency keys for safe retries on mutating endpoints
Background job queues with exponential backoff retry
p50/p95/p99 latency measurement and load testing with k6
DEPLOYMENT AND OPERATIONS
PM2 cluster mode, zero-downtime reload, startup configuration
Nginx reverse proxy, HTTPS with Let's Encrypt, HSTS
Environment variable management and secrets security
Health check endpoints and cron-based monitoring with alerting
Acceptance criteria-driven testing across 40 scenarios

Job Roles That Use These Skills

The skills from this course span four distinct job roles. Knowing which role fits your interests and situation helps you prioritise what to learn next — a backend engineer needs deeper database and systems knowledge, while an API integration specialist needs breadth across third-party services and SDK design.

Role Course Skills Used Additional Skills Needed Typical Salary Range
Backend Engineer REST design, auth, database design, performance, deployment SQL depth, data modeling, system design, Docker, CI/CD pipelines $70k–$160k (junior to mid)
Full-Stack Engineer API design, auth, error handling, versioning, real-world integrations React or Vue, TypeScript, state management, frontend testing $75k–$150k (junior to mid)
API Integration Engineer Webhooks, OAuth, rate limiting, idempotency, real-world use cases SDK development, API documentation, Postman/OpenAPI, partner onboarding $80k–$140k (junior to mid)
DevOps / Platform Engineer Deployment, PM2, Nginx, health monitoring, environment configuration Docker, Kubernetes, Terraform, cloud provider services, observability tooling $90k–$170k (junior to mid)
Which role is right for you?
If you enjoyed the database query work and system design decisions in Lessons 30–37, Backend Engineer is your natural path. If you find yourself wanting to connect the API to a UI, Full-Stack is the direction. If the Lesson 33 API Gateway and Lesson 34 case study were the most interesting lessons in the course, API Integration or Platform Engineering suits your problem-solving style. Follow the lessons that felt like puzzles rather than chores — that is the signal.

Portfolio Projects That Prove These Skills

A certificate proves you completed a course. A GitHub repository with working code proves you can build. Hiring managers at companies like Stripe, GitHub, and Shopify evaluate take-home projects and portfolio work more heavily than certifications. The four projects below are designed to demonstrate specific, employer-valued skills — not just "I know what a REST API is."

Each project has a clear scope, a skill it demonstrates, and a description of what makes it stand out in a portfolio. They are ordered from quickest to build to most impressive — complete them in order if you are working toward a job search, or pick the one that aligns with the role you want.

Four Portfolio Projects — In Order of Impact
1
Public API with Full Documentation — 1 to 2 weeks
Build a public REST API around a topic you know well — book tracking, recipe management, sports statistics, anything with real data. Deploy it live. Write complete OpenAPI documentation. Add a README with example requests and responses.
Proves: REST design, deployment, documentation. Stand-out factor: a live, documented, actually usable API that anyone can call right now.
2
Multi-Provider Auth Service — 2 to 3 weeks
Build a standalone authentication service that supports email/password (JWT), Google OAuth, and GitHub OAuth. Include refresh token rotation, a GET /me endpoint, and a token revocation endpoint. Deploy it as a service other apps can integrate with.
Proves: JWT, OAuth 2.0, security depth, service architecture. Stand-out factor: most developers have built basic JWT auth — multi-provider with rotation is senior-level.
3
Stripe Integration with Webhooks — 2 to 3 weeks
Build a subscription API that processes payments with Stripe, activates features on webhook confirmation, handles card declines with structured errors, and uses idempotency keys on every charge attempt. Include a webhook log endpoint so users can see delivery history.
Proves: payment integration, idempotency, webhook verification, real-world error handling. Stand-out factor: hiring managers at fintech and SaaS companies consider this proof of production readiness.
4
API Gateway with Rate Limiting Dashboard — 3 to 4 weeks
Extend the Lesson 33 gateway with a web dashboard showing real-time rate limit consumption per API key, request volume per route, and error rate trends. Add API key management (create, rotate, revoke) and per-key rate limit configuration. Deploy the entire stack.
Proves: gateway architecture, Redis data aggregation, operational tooling. Stand-out factor: this is the kind of internal tool that platform teams build — shows you think beyond CRUD.

The 90-Day Action Plan

Knowledge without output is not a career asset. This plan converts the course content into concrete, dated milestones. Each month has a specific goal and a specific deliverable — something you can link to in a job application, show in an interview, or share in a technical community.

The plan assumes 8 to 10 hours per week of focused time. Adjust the scope of each project if your available hours are lower — a smaller project completed and deployed is worth more than a larger project that stays local.

# WHAT: APIForge graduate 90-day career action plan
# Goal: three public portfolio items and one job application or product launch

# ── MONTH 1: SOLIDIFY AND PUBLISH ─────────────────────────────────────────

Week 1-2: Polish the Final Project
  [ ] Review all 40 acceptance criteria from Lesson 36 and confirm passing
  [ ] Add OpenAPI documentation (use swagger-ui-express to serve it at /docs)
  [ ] Write a thorough README: setup, endpoints, example requests, architecture decisions
  [ ] Push to a public GitHub repository

Week 3-4: Deploy and Share
  [ ] Deploy the APIForge Platform API to a live server (Lesson 38 steps)
  [ ] Verify HTTPS, health check, PM2 startup, and Nginx config are all working
  [ ] Share the live API URL and GitHub link in a developer community (Dev.to, Twitter/X, LinkedIn)
  [ ] Write one technical post explaining one decision from the build
    (Examples: "Why I use cursor pagination", "How I handle idempotency with Redis",
     "Building a webhook system from scratch")

Month 1 deliverable: live, documented, public API + one published article

# ── MONTH 2: BUILD PORTFOLIO PROJECT 2 ────────────────────────────────────

Week 5-6: Multi-Provider Auth Service — Design and Build
  [ ] Define the API contract: register, login, Google OAuth, GitHub OAuth,
      refresh, revoke, GET /me
  [ ] Set up Google OAuth app in Google Cloud Console
  [ ] Set up GitHub OAuth app in GitHub Developer Settings
  [ ] Implement all endpoints using the patterns from Lessons 20, 21, 32

Week 7-8: Auth Service — Polish and Deploy
  [ ] Add token rotation (invalidate old refresh token on use)
  [ ] Write integration tests covering the full auth flow end-to-end
  [ ] Deploy to a live server with its own subdomain (auth.yourdomain.dev)
  [ ] Document the integration guide — how another app consumes this service

Month 2 deliverable: live multi-provider auth service + integration documentation

# ── MONTH 3: SPECIALISE AND APPLY ─────────────────────────────────────────

Week 9-10: Deep Dive Into Your Target Role
  Backend Engineer path:
    [ ] Add Docker and docker-compose to the Final Project
    [ ] Set up a basic CI/CD pipeline with GitHub Actions
    [ ] Study: database transactions, connection pooling with PgBouncer
  Full-Stack path:
    [ ] Build a minimal frontend for the APIForge API using React
    [ ] Implement auth flow in the frontend — login, token storage, refresh
  Platform/DevOps path:
    [ ] Containerise the API with Docker
    [ ] Deploy using docker-compose with Nginx, PostgreSQL, and Redis
    [ ] Add structured logging with a log aggregator

Week 11-12: Job Applications or Product Launch
  [ ] Update CV and LinkedIn with specific technologies and projects
  [ ] For each project, write 2-3 bullet points using the format:
      "Built [what] using [how] that [result/scale/impact]"
      Example: "Built a production REST API with JWT auth, cursor pagination,
      and Redis rate limiting serving 100 req/min per user under PM2 cluster mode"
  [ ] Apply to 5 backend or full-stack roles, or ship v1 of your own product
  [ ] Prepare answers to these interview questions (covered in the course):
      What is the difference between PATCH and PUT?
      How does JWT authentication work and what are its limitations?
      What is the N+1 query problem and how do you fix it?
      When would you use cursor pagination vs offset pagination?
      How do you handle webhook verification securely?

Month 3 deliverable: job applications sent OR product v1 live
90-day plan milestone tracker ============================== MONTH 1 — Solidify and Publish Week 1-2: [ ] OpenAPI docs [ ] README [ ] GitHub push Week 3-4: [ ] Live deploy [ ] Article published Deliverable: Live API at https://api.yourname.dev + published article MONTH 2 — Multi-Provider Auth Week 5-6: [ ] Google OAuth [ ] GitHub OAuth [ ] All endpoints built Week 7-8: [ ] Token rotation [ ] Tests [ ] Live at auth.yourname.dev Deliverable: Live auth service + integration guide MONTH 3 — Specialise and Apply Week 9-10: [ ] Role-specific deep dive complete Week 11-12: [ ] CV updated [ ] 5 applications sent OR product v1 live Deliverable: Active job search OR product in users' hands Interview questions from this course: "What is the difference between PATCH and PUT?" PATCH updates specific fields (partial). PUT replaces the entire resource. "How does JWT work and what are its limitations?" Self-verifying token. Limitation: cannot be revoked before expiry without a token denylist. Refresh token rotation mitigates this. "What is the N+1 problem?" 1 query for list + N queries per row for related data. Fix: JOIN query or batch load with IN clause. "Cursor vs offset pagination?" Cursor: stable under concurrent writes, always indexed-fast. Offset: simple, breaks when data changes between pages. "How do you verify webhooks securely?" HMAC-SHA256 signature over timestamp + body. Reject if timestamp older than 5 minutes (replay protection).
What just happened?

The five interview questions at the bottom of the plan are not random. They are the questions that backend and full-stack hiring managers at product companies consistently ask candidates who list "REST API development" on their CV. Each one has a precise answer that this course covered — PATCH vs PUT in Lesson 13, JWT limitations in Lesson 21, N+1 in Lesson 30, cursor pagination in Lessons 14 and 34, webhook verification in Lessons 34 and 35. You already know the answers. The plan is about making sure you can articulate them clearly under interview conditions.

The bullet point format for CV entries — "Built [what] using [how] that [result/scale/impact]" — is the format that passes automated resume screening and makes human reviewers stop scrolling. "Developed RESTful APIs" tells a reviewer nothing. "Built a production REST API with JWT auth, cursor pagination, and Redis rate limiting serving 100 req/min per user under PM2 cluster mode" tells them your technical level, your tooling familiarity, and your operational awareness in one sentence.

Try this: Write your CV bullet point for the APIForge Final Project right now. Use the format above. Time yourself — it should take under 5 minutes. If it takes longer, the project is not concrete enough in your memory yet. Go back to Lesson 37, re-read the Phase 4 output, and try again.

What to Learn Next — By Role

The technologies below are not arbitrary recommendations. Each one extends a specific skill from this course in the direction that employers and projects actually require. Study them in the order listed — each one builds on the previous.

Backend Engineer Path
1. TypeScript — adds types to the JavaScript you already know. Catches bugs at build time that crash Node at runtime.
2. Docker — containerise the APIForge API. Dockerfile, docker-compose with PostgreSQL and Redis. The natural next step from Lesson 38.
3. GitHub Actions — CI/CD pipeline that runs your acceptance criteria on every push. Automated deployment on merge to main.
4. SQL depth — window functions, CTEs, query plan analysis with EXPLAIN ANALYZE. Extends the N+1 and index work from Lesson 30.
5. System Design — how to scale from one server to many: load balancers, database sharding, CDN, eventual consistency tradeoffs.
Full-Stack Engineer Path
1. React — connect a frontend to the APIForge API. Implement the auth flow: login form, token storage, protected routes, token refresh.
2. TypeScript — use the same API contract from Lesson 36 to generate typed client code. Full-stack TypeScript with shared types is a major productivity win.
3. Next.js — server-side rendering that calls your API at build time or request time. Covers both static and dynamic data patterns.
4. tRPC or GraphQL — end-to-end type-safe API layers. tRPC is the faster path if you stay in TypeScript. GraphQL if your clients need flexible queries.
5. Vercel or Railway — deploy the full stack (frontend + API) from a single GitHub repository push.
API Integration Engineer Path
1. OpenAPI depth — write full specs for the APIForge API. Generate client SDKs from the spec. This is how Stripe, Twilio, and GitHub publish their SDKs.
2. Postman Collections — build a shareable Postman collection covering all 19 endpoints with pre-request scripts and test assertions.
3. Zapier or Make — build integrations using the APIForge webhook events as triggers and third-party services as actions. Shows you understand the integration ecosystem.
4. SDK development — build a Node.js and Python SDK for the APIForge API. Automatic retry on 429, idempotency key generation, typed response objects.
5. Developer Relations skills — technical writing, documentation, developer experience design. The human side of API products.
DevOps / Platform Engineer Path
1. Docker and Compose — containerise the APIForge stack. Replace the Lesson 38 PM2 setup with a Docker-based deployment.
2. Kubernetes basics — deploy the containerised stack to a Kubernetes cluster. Understand Deployments, Services, Ingress, and ConfigMaps.
3. Terraform — define the server, database, Redis, and DNS records from Lesson 38 as infrastructure-as-code. Reproducible environments with one command.
4. OpenTelemetry — add distributed tracing to the APIForge API. Replace the Morgan logger with structured traces that flow into Grafana or Datadog.
5. Incident response — runbooks, postmortem writing, on-call practices. The operational layer that sits above the technical stack.

Before and After: Course Complete vs Career Ready

Course completion and career readiness are not the same thing. The gap between them is portfolio evidence, interview preparation, and role-specific depth. The 90-day plan closes that gap.

Course Complete — Day 1
Knowledge of 37 concepts across API design, security, and deployment
One completed project (APIForge Platform API) running locally
No live portfolio items employers can access
Interview answers exist in lesson notes, not in confident recall
No role-specific depth beyond what the course covered
Career Ready — Day 90
Same 37 concepts — now attached to live, linkable proof of work
Two or three deployed projects with OpenAPI documentation and READMEs
Live portfolio URLs on CV and LinkedIn — employers can call the APIs
Five interview questions answered confidently with project examples
Role-specific depth in one area — Docker, React, OpenAPI, or Kubernetes
One last thing: The developers who get hired for backend and API roles are not the ones who know the most theory. They are the ones who can point to working systems they built, explain the decisions they made, and describe what broke in production and how they fixed it. This course gave you the foundation and the first project. The 90-day plan gives you the rest. The only remaining step is the one you take next.

Quiz

1. A developer is updating their CV after completing this course. Which of the following bullet points for the APIForge Final Project best follows the "Built [what] using [how] that [result/scale/impact]" format?

2. An interviewer asks: "How does JWT authentication work and what are its limitations?" What is the correct answer to the limitations part of this question?

3. An interviewer asks which pagination strategy you would choose for a live feed of user activity events where new events are constantly being added. What is the correct answer?

Course Complete
Web APIs — All 40 Lessons
You started with HTTP and finished with a production-deployed API, a Stripe-grade error system, signed webhooks, Redis rate limiting, and a live server behind Nginx. The foundation is solid. The next step is yours.