GraphQL Queries, Mutations, Subscriptions and RBAC Guide

3. Subscriptions – “Notify me when something happens”

This is where GraphQL stops being polite small talk and starts being really cool.

The question is “What is the patient’s current appointment status?” Subscriptions are “Text me as soon as anything changes.” It’s the difference between refreshing your package tracking page every five minutes like a caveman, and getting push notifications when your package leaves the depot.

Subscription complete Web Socketsnot regular HTTP. Your client opens a connection and just… waits. No polling, no setInterval hacks, no embarrassment.

subscription OnAppointmentStatusChanged {
  appointmentStatusChanged(patientId: "patient-001") {
    id
    status
  }
}

In my POC, when a doctor updates an appointment from SCHEDULED to IN_PROGRESS, the patient dashboard updates directly, no refresh button needed. The server publishes an event, the subscription catches it, the UI fires. It really felt like magic the first time I saw it work, until it didn’t, and at that point it felt like a personal attack. (Pro tip: check your WebSocket connection before assuming that the universe specifically hates you.)

Interesting summary: Question asked once. Mutations occur once. Subscriptions never stop, in the best way.

4. Access Control – “Not everyone can see everything”

Here’s the plot twist no one warned you about: creating the API is the easy part. Decide who is allowed to do what that’s where things get spicy.

In the healthcare system, this is not an option, it is at the heart of the problem. A patient should not ask about another patient’s medical records. A nurse may not delete a doctor’s account. And under no circumstances should anyone except doctors and admins be allowed to see sensitive fields like a patient’s SSN.

This is Role Based Access Control, or RBAC if you like an acronym with a slightly bureaucratic feel.

The idea is simple although the implementation has layers:

• Authentication the answer to “who are you?”, is usually the JWT token you get after logging in.
• Authorization answered “what can you do, now that I know who you are?”

In practice, this means every GraphQL operation is checked against user role before being allowed to run:

The really fun part is field level access control, not just “can you run this query,” but “can you see this specific field in the response.” A patient who asked for his own records got ssn: cancel even though the field exists in the schema. Same question, different people, different answers. GraphQL quietly edits documents right in front of you, like a polite government agency.

Lines to remember: Authentication is the guard checking your ID. Authorization is the guard who decides which rooms you are allowed to enter once you enter. Don’t confuse the two, or you’ll spend three hours debugging a “bug” that you actually only missed one step in.

Putting it all together (without losing your mind)

Here’s the mental model that ultimately worked for me:

• Scheme = contract. What data is there, what form does it take.
• Question = read that data.
• Mutation = changes that data.
• Subscriber = get notified when data changes, instantly.
• RBAC = guards make sure everyone only sees and touches what they are supposed to see.

Four concepts. One mental model. No PhD required.

What really surprised me when making this was how stackable everything was. Once your schema is solid, Queries and Mutations will write themselves. Subscriptions are just Mutations with a megaphone. And RBAC is just… rules, applied consistently, everywhere, without exception, the same discipline you would want from a firm but fair teacher.

Get up

I created a complete working version of all of the above, patients, doctors, appointments, prescriptions, real-time subscriptions, full role-based access control, using Node.js, TypeScript, PostgreSQL and React. No ORM, no shortcuts, completely raw SQL, so you can actually see what’s happening instead of trusting the magic box.

Repo link: https://github.com/ArzooJain-25/healthcare-graphql-poc

Clone, run, break, fix. That’s really the quickest way to learn this, not by reading one more blog post (yes, even this one), but by watching the query fail, cursing under your breath, and figuring out why.

GraphQL isn’t scary. Only REST eventually underwent therapy and learned to communicate his needs clearly.