DEV Community: Saribeg

Full Stack Open Course: My Experience with Part 8 (GraphQL)

Saribeg — Sat, 20 Dec 2025 11:06:17 +0000

After wrapping up Parts 0-7 of Full Stack Open with two different implementations of the BlogApp (Redux vs React Query), I was ready for something new. Enter Part 8: GraphQL.

If you've been following the MERN stack journey in my previous articles, you know I'm all about diving deep and going beyond the minimum requirements. Part 8 was no exception - and honestly, GraphQL turned out to be both fascinating and frustrating in ways I didn't expect.

Repository folder with codebase

Why GraphQL?

Before jumping in, let's address the elephant in the room: REST APIs work perfectly fine for most applications. So why learn GraphQL?

The course materials make a compelling case: GraphQL solves the over-fetching and under-fetching problems inherent in REST. Instead of hitting multiple endpoints or getting back data you don't need, you ask for exactly what you want in a single request.

Sounds great in theory. But theory and practice are two very different beasts.

What Part 8 Covers

The project is a deliberately simple library-style application, built to explore GraphQL fundamentals - authors, books, genres, the usual suspects. Here's what the course teaches:

GraphQL server with Apollo Server - schemas, resolvers, queries, mutations
React frontend with Apollo Client - querying data, managing cache
MongoDB integration - because GraphQL still needs to get data from somewhere
Authentication with JWT - protecting mutations behind login
Subscriptions - real-time updates via WebSocket

The course exercises took me about 20 hours. But here's where it gets interesting: I spent an additional 15+ hours implementing features that weren't required but felt necessary for a real-world application.

Let me explain why.

Beyond the Exercises: Where Things Got Real

1. Pagination - When the Cache Has a Mind of Its Own

Here’s where I made my first ‘creative’ decision: the course doesn’t cover pagination. Not content with adding it like a reasonable person, I decided to spice things up by implementing both approaches. Because why solve one problem when you can create two?

Offset-based pagination for the Authors page (the traditional "page 1, 2, 3" approach)
Cursor-based pagination for Books with infinite scroll (like social media feeds)

The offset approach was straightforward - nothing too surprising there. But cursor-based pagination with infinite scroll? That's where Apollo Client's cache became... interesting.

The problem: When you're loading more items incrementally (load 30 books, scroll down, load 30 more), Apollo needs to remember what you've already fetched and append new results. Easy, right? Not quite.

Apollo Client caches data in a normalized way - think of it like a smart database that stores each object once and references it elsewhere. When I added real-time subscriptions (so new books would appear instantly when added by other users), the cache got confused about how to merge the new data with the existing paginated list.

New books wouldn't appear. Or they'd appear twice. Or the cache would just forget chunks of data entirely.

Why this happens: Apollo provides mechanisms for merging paginated data, but when you combine custom merge strategies with real-time updates, you need to explicitly tell Apollo: "Hey, this new book reference goes here in the list, check if it already exists first, and update these specific query results."

The solution: Instead of letting Apollo's default behavior handle it, I had to manually update the cache whenever a new book arrived. This meant checking if the book already existed (to avoid duplicates), creating a proper reference to it (not embedding the whole object), and inserting it at the right position in the paginated list.

Lesson learned: Apollo's cache is incredibly powerful, but it requires you to think about data as references and relationships, not just objects. When in doubt, the Apollo DevTools cache inspector became my best friend - seeing the actual cache structure helped me understand what was going wrong.

2. Custom Scalars - Validation That Makes Sense

The course uses basic types: strings, numbers, booleans. But in a real application, you want more specific validation.

The idea: GraphQL lets you define custom data types (called "scalars") that validate input automatically. Instead of accepting any string for a username, you can create a Username type that only accepts alphanumeric characters between 3-15 characters long.

I added custom scalars for:

Year - ensures it's a valid 4-digit year (not 99999 or -500)
Username - enforces formatting rules
Password - sets length requirements before hashing
Genre - normalizes to lowercase, prevents weird formatting

Why this matters: Validation happens at the GraphQL layer before your data even reaches the database. If someone tries to add a book published in year 3000, GraphQL rejects it immediately with a clear error message. Time travelers will need to use a different API. No need to write validation logic in multiple places - it's baked into the schema itself.

The challenge: GraphQL's built-in scalars are limited, so you have to define custom ones yourself. But once set up, they work everywhere automatically - queries, mutations, even in nested objects.

3. Error Handling - Making Sense of What Went Wrong

In REST APIs, you have HTTP status codes: 400 for bad request, 401 for unauthorized, 500 for server error. Simple.

In GraphQL, every request returns HTTP 200, even when things go wrong. Error details live inside the response body under an errors array.

The problem: Different types of errors (validation errors, authentication errors, database errors) all look similar to the frontend unless you explicitly categorize them.

My approach: Following the sacred DRY principle and my personal vendetta against scattered error handling, I created a central error formatting function on the server that:

Catches database validation errors (like duplicate usernames)
Transforms them into clear, user-friendly messages
Adds proper error codes (like BAD_USER_INPUT or UNAUTHENTICATED)
Hides internal server details from the client

On the frontend, I doubled down on this strategy with an error handling pipeline that:

Intercepts all GraphQL errors globally
Shows user-friendly toast notifications
Automatically logs out users when authentication expires
Retries failed requests for network issues (but not for bad input)
Prevents duplicate error messages from spamming the user (a deceptively simple bullet point that cost me time wondering, “why is this toast appearing three times?!”)

Why this matters: Without proper error handling, users see cryptic messages like "E11000 duplicate key error" instead of "This username is already taken." Good error handling is the difference between a confusing app and a polished one.

4. The N+1 Query Problem - Efficiency at Scale

Here's a sneaky performance issue that GraphQL makes easy to create: the N+1 query problem.

Scenario: You want to show a list of 20 authors, each with their book count.

Naive approach:

Query the database for 20 authors (1 query)
For each author, query the database for their books (20 queries)
Total: 21 database queries

If you have 100 authors, that's 101 queries. Yikes.

The solution: DataLoader

DataLoader is a utility that batches requests. Instead of making 20 separate "get books for this author" queries, it collects all the author IDs, makes ONE query to get book counts for all authors at once, then distributes the results back to the right resolvers.

Result: 21 queries become 2 queries. On large datasets, this is the difference between a snappy UI and a sluggish one.

Why GraphQL makes this tricky: Because GraphQL lets clients request nested data flexibly, it's easy to accidentally create these N+1 scenarios without realizing it. REST APIs force you to think about this upfront because you're designing specific endpoints.

5. Security - Protecting Your API

The course doesn't cover GraphQL security, but here's the thing: GraphQL's flexibility is also a potential attack vector.

Problems that don't exist in REST:

Deeply nested queries: Someone could request books → authors → books → authors → books... 50 levels deep, crashing your server
Expensive queries: A client could request every field on every object in your entire database in a single query
Schema introspection: By default, anyone can query your GraphQL schema to see every available field and type - like having your API documentation publicly available to attackers

My security additions:

Query depth limiting: Reject queries nested deeper than 5 levels
Query cost analysis: Assign "costs" to different fields and reject queries that exceed a budget
Introspection toggle: Disable schema introspection in production

Why this matters: These attacks are specific to GraphQL's flexibility. A REST API naturally limits what clients can request because each endpoint is fixed. In GraphQL, you have to enforce these limits explicitly.

6. Database Aggregations - When Abstractions Break

Here's a fun quirk I discovered: When using Mongoose (MongoDB library), there are two ways to query data:

Regular queries - Mongoose handles everything nicely, transforms your data automatically
Aggregation pipelines - You write raw MongoDB queries for complex operations

For the Authors page, I wanted to sort authors by book count. This required using aggregation pipelines because I needed to count related books and sort by that count.

The surprise: All the nice automatic data transformations Mongoose does (like converting MongoDB's _id to id via Mongoose’s toJSON transform) don't happen in aggregation pipelines. Suddenly, my GraphQL queries expected an id field, but the database was returning _id.

The fix: I had to manually specify the field transformation in the aggregation pipeline itself.

Lesson learned: Abstractions are great until they're not. Sometimes you need to understand what's happening under the hood, especially when performance optimizations take you outside the happy path.

GraphQL vs REST: My Honest Take

After spending 35+ hours with GraphQL, here's what I think:

GraphQL shines when:

You have complex, interconnected data (think social networks, content platforms)
Different clients (web, mobile, desktop) need different data subsets
You want a strongly-typed contract between frontend and backend
Real-time updates are important

REST is still better when:

Your API is straightforward CRUD operations
You want to leverage standard HTTP caching (GraphQL usually uses a single POST endpoint, which makes CDN and browser-level caching much harder)
Simplicity matters more than flexibility

GraphQL isn't magic - it's a trade-off. You exchange REST's simplicity for flexibility and type safety, but you pay for it with increased complexity in caching, error handling, and security.

Time Breakdown

Here's how those 35 hours broke down:

Task	Time
Course material (Parts 8a-8e)	20h 3m
Custom scalars & validation	1h 40m
Pagination (offset + cursor-based)	7h 42m
Error handling & bug fixes	4h 12m
Security (depth/cost limits)	1h 15m
Total	35h 17m

That pagination time? Most of it was debugging cache issues and reading Apollo documentation to understand why things weren't working.

What's Next?

The Full Stack Open course continues with CI/CD, containers, and more. I’ll probably write about other parts in future articles.

Want to see the code? Check out my GitHub repository with the full implementation, including all the extra features I added.

Have you worked with GraphQL? What was your experience? Drop a comment — I’m curious how it played out for you.

Happy coding. 😉

Full Stack Open Course: My Experience with Parts 0-7

Saribeg — Tue, 30 Sep 2025 14:10:07 +0000

After spending several years deep in the e-commerce trenches with Salesforce Commerce Cloud, I found myself craving something different. Not just another JavaScript framework tutorial or a "build a todo app in 10 minutes" speedrun, but a proper, comprehensive deep dive - not into the unknown, but into refreshing what I already knew and discovering new corners of full-stack JavaScript.

That's when I stumbled upon Full Stack Open from the University of Helsinki.

Why This Course Hit Different

Let's be real - the internet is drowning in coding courses. So what made FSO stand out?

University-backed quality: This isn't someone's weekend project. It's an actual university course, taught by professors who know their stuff
University-recognized credits: You can earn real ECTS credits through the University of Helsinki’s Open University - formal European university credits that may count toward degree studies, or simply serve as official proof of your learning via transcript.
The price tag: Free. Completely. No "premium" upsells, no paywalls after lesson 3

After years of fragmented tutorials and "just trust me bro" explanations, finding a structured, academic approach felt like discovering clean code after debugging spaghetti for hours.

What's Actually in Parts 0-7?

These first seven parts focus on the MERN stack and give you enough knowledge to start contributing to real-world projects:

The Tech Stack:

Frontend: React, Redux, React Query (because state management debates never get old)
Backend: Node.js, Express, MongoDB, REST APIs, JWT authentication
Testing: The whole spectrum - unit tests with Vitest, integration tests with SuperTest, E2E with both Playwright and Cypress
Deployment: To cloud PaaS platforms like Render and Fly.io (goodbye, localhost:3000!)

The course includes around 153 exercises, but here's the beautiful part: there's no ceiling. Complete the basics? Great, you pass. Want to go deeper and polish every edge case? The playground is yours.

How I Approached the Course

Since I wasn't completely new to these technologies, I decided to challenge myself:

Part 5 - The Testing Showdown

Instead of picking one E2E framework, I implemented tests in both Playwright and Cypress. Nothing teaches you the pros and cons of each tool quite like writing the same test suite twice.

Part 7 - The Ultimate Comparison

I built the final BlogApp project twice with different tech stacks:

Redux Toolkit + TailwindCSS (for that utility-first satisfaction)
React Query + Material-UI (because sometimes you want components that just work)

🚀 Check Out the Demo

Want to see the code in action? I built a dedicated landing page with details about the project, the tech stack, and even time-tracking logs. There you’ll find links to both versions of the app, which you can try out. Each version also includes an About page with technical notes, design choices, my impressions and other details.

🌐 Demo App

📦 GitHub Repository

Who Should Take This Course?

Developers who already know JS/React and want to see the full picture of full-stack development.
Anyone who wants to brush up on their full-stack skills.
Those who value a structured roadmap and the bonus of earning university credits.

What the Course Doesn't Cover (Yet)

Let's keep it real - no course is perfect. Here's what you might want to supplement:

Redux thunks and custom middleware aren't covered. You'll want to explore these for handling complex async flows and error boundaries
Caching strategies get a surface-level treatment. In production, this becomes critical (and no, you can't just memorize it - experiment and break things!)
Advanced authentication patterns like refresh tokens, session management, and token rotation are left as "exercises for the reader"

I ended up implementing database seeding for demo environments - not required, but incredibly useful for testing and showcasing your work. But I left some features untouched - the infinite like counter stayed as is. Let’s just call it an artistic choice.

The Golden Rule

Don't rush through it like you're cramming for an exam. Use FSO as your foundation, then build on top of it with what you actually need in your day-to-day work. The course gives you the blueprint; you're the architect.

What's Next?

Maybe later I’ll also write about other parts I’ve completed - for example, GraphQL, CI/CD, and Docker. Each part adds another layer to your full-stack toolkit.

For now, if you're looking to build a rock-solid foundation in the MERN stack with proper testing and easy (non-DevOps) deployment practices, Parts 0-7 are your launchpad.

Happy coding, and remember: console.log() is a perfectly valid debugging strategy, no matter what anyone tells you. 😉

💬 Share Your Experience

Have you taken Full Stack Open? What was your experience? Drop a comment below - I'd love to hear about your approach to the exercises!

The Developer’s Learning Journey: When Study Methods Evolve Over Time

Saribeg — Thu, 11 Sep 2025 06:46:59 +0000

“Live as if you were to die tomorrow. Learn as if you were to live forever.” - Mahatma Gandhi

In tech, you never stop learning. But the way you learn changes over time. What feels perfect at the beginning can become a roadblock a few years later.

This is my personal story of how my learning stack evolved from in-person IT school to video courses, from reading the docs while building pet projects to structured, practice-heavy programs, and finally to a cautious relationship with AI.

If you recognize yourself in any of this, you’re not alone.

Stage 1: IT Bootcamps (IT School) as a Beginner’s Compass (2018)

Coming from a completely different field, I needed three things that self-study couldn't provide:

Structure - a clear, well-designed curriculum with the right topics in the right order.
Support - mentors and instructors you can turn to when you’re stuck - they can unblock you and help you move forward.
Community of peers - fellow strugglers who understood why a missing semicolon could ruin your entire evening.

At this stage, scattered video tutorials and mini-courses on individual technologies felt like trying to build a house by randomly collecting bricks. They lacked the comprehensive, systematic approach I needed.

The bootcamp (in my case, an IT school program) became the obvious choice. In-person attendance added the necessary atmosphere and drive - there's something about physically showing up that makes you take it seriously. Team projects with coursemates and a community to discuss solutions accelerated the process exponentially. Nothing beats the "aha!" moment when you explain your bug to someone and suddenly realize the solution mid-sentence.

That's how I entered the programming world through a Full-Stack JavaScript Developer program. Back then, React was still written with class components! 😄 (For the younger folks reading this - yes, we used to write componentDidMount and this.setState everywhere, and we liked it... sort of.)

IT bootcamps provide an excellent foundation and smooth entry into the profession - ideal for first steps. But once you understand the landscape, you're ready for independent exploration. Later, returning to a bootcamp for new topics feels like overkill. My university education had already given me the necessary skills for finding and analyzing information; I just needed that initial push into the profession.

This realization made me reconsider video courses. Platforms like Udemy - what hadn't worked at the very beginning suddenly became the perfect tool.

Stage 2: Video Tutorials - Quick Immersion (First 2 Years of Experience)

When you're learning a technology for the first time without similar experience to lean on, visual and sequential information delivery with step-by-step explanations is perfect for comprehension. You diligently follow the instructor, implement course projects, add your own touches. Eventually, the information sticks. It's a fast way to master new tools without significant investment.

I consumed countless hours on Udemy and similar platforms. Topics ranged from advanced Node.js concepts in my early days to TypeScript and GraphQL as I gained experience.

But as my knowledge grew, this format suddenly stopped working. I discovered several pain points:

The Illusion of Understanding. Everything makes sense immediately. No need to type the code in your IDE - it all seems simple and obvious. This completely kills effectiveness. Learning must happen through practice, not passive watching. It's not about laziness; it's about blind confidence that "I get it." Result? You've watched a movie you'll forget in two weeks.
Excessive Detail. Information is over-explained for universality - to suit beginners too. Even at 1.5-2x speed, I lacked patience and wanted to skip ahead. When a format irritates you, it's time to find alternatives.
The Same Instructors Everywhere. They'll teach you the entire JavaScript stack. Eventually, the same voices, mannerisms, and presentation styles become grating. Like your favorite song that you overplayed until you can't stand it anymore. No offense to the instructors - they're doing great work. This is about my perception evolving.
The Boredom of Following Along. I wanted to build my own ship, not copy someone else's blueprint. The value of courses evaporated - it became simpler to start a pet project and use documentation with AI to learn through practice.
Lack of Real Assessment. Small automatic quizzes don't test actual skills. There's a desperate need for project assignments with subsequent review or mentoring.

Combined, you outgrow this format - it starts holding you back. The checkbox is ticked, but you haven't actually learned anything substantial.

A perfect example: learning GraphQL. In video courses, everything looks logical and clear - schemas, resolvers, queries. You feel like you've mastered it. But in practice, the real fun begins: Apollo Client caching doesn't work as expected for your specific case, pagination combined with subscriptions breaks cache update logic, and error handling requires deep understanding of the framework's internals. What looks simple in a smooth tutorial flow can take hours of debugging and documentation diving in reality. This gap between "understood in theory" and "made it work in practice" is the format's key limitation.

This format worked perfectly for about two years, then the need for change emerged. It's ideal when you're ready to move independently but aren't yet experienced - you don't have similar patterns in your head, and every detail is absorbed with interest. For experienced developers, the "follow along" format loses its value.

Stage 3: Documentation and Pet Projects - Independent Exploration

If official documentation once seemed dry and non-sequential, failing to provide the big picture, experience flips everything upside down. With a mental model of the stack already formed, associative memory and intuition for common principles help you grasp new tools on the fly. You no longer need hand-holding and step-by-step instructions - documentation and solid Google-fu fill the gaps.

It's fascinating to observe this evolution, when dry official documentation becomes the preferred learning method.

No fluff - you read exactly what you need, when you need it.
Realistic learning - you hit real errors, search for real solutions, and remember them because they hurt a little. You stumble, fall, get up, and that struggle makes the knowledge stick.
Transfer learning - prior patterns help you grasp new tools faster, connecting the dots through intuition and experience.

“Reading documentation without building something is like reading a cookbook without cooking - you might understand the recipe, but you haven’t learned to cook.”

Reading docs alone achieves nothing. The principle stays the same: learn by doing. Build your own ship (a learning pet project) and keep the docs open as your map. For example, this is how I kept my MERN stack skills fresh while working commercially on a different stack. When documentation is thin, bring in other tools selectively - the key is free flight: the ability to find, interpret, and apply information on your own.

This format is harder for beginners - without an existing mental model, documentation can feel confusing and incomplete. But with experience, it’s faster and more “professional” than video tutorials.

The loop: Project → Problem → Docs → Fix → Repeat. That’s how you learn the way you actually work.

This approach also addresses an industry paradox: job postings often demand “2+ years of X” - but how do you get that if no one hires you without it? Self-study through documentation and pet projects isn’t identical to a job, but it’s closer than passively consuming tutorials. It proves you can solve problems in unfamiliar territory.

Rule of thumb: Always start with a project. Let the project drive your reading list.

Stage 4: Courses with Assignments - Structure Plus Freedom

Technologies constantly expand, new tools emerge. The Full-Stack role requires a broad knowledge base, but it's project-specific - you use far from the entire arsenal in any particular job, and logically, the rest fades. Eventually, endless throwaway pet projects also become tiresome and demotivating. You crave a new format.

I recently discovered Full Stack Open from the University of Helsinki, which perfectly suited both reviewing familiar technologies and learning new ones. It worked for me because:

Motivation matters. You can earn official university credits. This requires actually submitting work. There's no direct feedback, but there's the feeling of it - repositories undergo manual review for credit allocation. And it's free.
Build it yourself. Lots of assignments you must implement independently. You can extend them beyond the minimum. The course provides theory and direction, but you own the execution.

It's essentially the same as your own project with documentation, but under university patronage with a structured program. Sometimes it's pleasant to return to roots. As the proverb goes, “Everything new is well-forgotten old.” This mixes different approaches with fresher air.

Through FSO, I covered:

Backend: Node.js, Express, Supertest, Node testing framework
Frontend: React, Redux Toolkit, React Query, Vitest, Playwright, Cypress
Databases: MongoDB, Mongoose, Sequelize, PostgreSQL
CI/CD: GitHub Actions
Containers: Docker
Other: TypeScript, GraphQL

No, the brain can’t memorize every detail of all those technologies (I’ll write about cognitive limits another time). But you can learn to use them to solve real business problems.

Stage 5: Using AI in Learning - A Double-Edged Sword

This is dangerous territory, and I haven't fully formed my boundaries yet, but some things deserve highlighting. AI can either accelerate your growth or completely stall your progress.

Upside: AI is a 24/7 mentor that speeds up work, cuts hours of Googling and Stack Overflow searches, explains complex topics instantly, provides ready solutions.

Downside: if you’re learning something new, pasting AI-generated code directly into your project can rob you of the struggle that actually builds expertise. In learning mode, you need the painful cycles: break → fix → refactor → repeat. That’s where understanding is forged.

Anti-pattern: “Explain this code line by line and I’ll remember it.”

You won’t - if you didn’t fight for it.

Even if AI explains the code in detail, you’ll forget it because you didn’t live through the process. Experience matters far more than passive understanding. Copy-pasting ready solutions during learning is an anti-pattern: you haven’t internalized the mistakes and fixes, so you haven’t built the skill.

If you’re already an experienced developer, leaning on AI isn’t as dangerous - you can read, adjust, and apply code consciously. But when learning new tools, you need to first become a specialist without AI, and only then exploit it as leverage. Otherwise, you risk building an illusion of knowledge, only to discover you can’t solve even simple tasks without the crutch.

One clarification: I’m not against AI in every context. I’m using it right now - not to generate my ideas, but to help polish my words into a readable article. That’s no different from hiring an editor. The thoughts are mine; the tool just helps me present them better. And that's OK, because I’m not aiming to become a professional writer or editor. But in my core craft - software development - the rules are different. That’s the contrast: if it’s your profession, you need to live through the work. If it’s not, outsourcing is just practical.

This article isn’t meant to prescribe rules - I’m just sharing what I’ve observed. But after mentoring in an IT school for 4 years, I’ll risk one piece of advice for beginners: use AI extremely carefully, or better yet, don’t use it at all until you can confidently handle the technology without it. The struggle is what makes the learning real.

What Stayed True Across All Stages

Active > passive. Editors beat videos. Tickets beat lectures.
Theory + practice. As the saying goes, "Theory without practice is dead, and practice without reflection is blind."
Change the method, not the mission. When a method stops working, switch it - don’t stop learning.

“Formats expire. Curiosity doesn’t.”

Conclusion: To Learn Is to Adapt

Looking back, I see a clear evolution: from structured learning with support, to full independence, and finally to a balanced mix of structure and freedom. Each stage was necessary and made perfect sense for its time.

IT school gave me the foundation and confidence to enter the profession.
Video courses helped me quickly adopt new technologies in the early years.
Documentation with pet projects taught me to solve problems in unfamiliar areas by extrapolating existing skills to unknown tools.
Practice-heavy courses restored motivation and structure without taking away freedom.
AI became a powerful assistant - useful, but requiring careful guardrails.

The main discovery: your learning format must evolve with you. But one principle never changes - stay an active learner, not a passive viewer.

What format works for you right now?

Share your current stack (courses, routines, tools, rituals) in the comments. Have you noticed your learning style changing over the years? What triggered your transitions between different approaches? I’d love to compare experiences.