Mais

Figuring Out Firebase Realtime Database Transactions in Node

Fri, 13 Jun 2025 00:00:00 GMT

A few days ago, I was working on a small authentication feature using both Firebase Auth and the Realtime Database (RTDB). I decided to write this post because understanding how Firebase RTDB transactions work—especially in Node—took me longer than I expected, even after reading the docs.

The scenario: a user is already logged in on their phone and enters a short code into another device to link their session.

Since the authentication was already handled on the phone, our backend issued a Firebase Auth custom token tied to that code. The device where the code is entered would then sign in using this token.

To securely bind the session in RTDB, we needed to:

Check if the session code was valid and unclaimed.
Atomically assign the user ID to it.
Ensure only one session claim succeeds.

The rest of this post dives into how these transactions work specifically in the Admin SDK for Node.js, and how to use them.

The Confusion

Take this transaction example from the official docs:

const upvotesRef = db.ref(
  'server/saving-data/fireblog/posts/-JRHTHaIs-jNPLXOQivY/upvotes'
);
upvotesRef.transaction((current_value) => {
  return (current_value || 0) + 1;
});

This is straightforward: the callback returns a new value, and Firebase writes it.

But when I tried running a similar transaction, the first call to the callback received current_value as null—even though a record already existed. My assumption was that I should have seen the record immediately.

Reading further into the docs, I found this note:

Your transaction handler is called multiple times and must be able to handle null data. Even if there is existing data in your database it may not be locally cached when the transaction function is run.

So this behavior is expected: initially, current_value is null because it's coming from the local cache. Firebase will then fetch the latest state from the server and re-run the callback with fresh data.

Here was my initial transaction logic:

const result = await codeRef.transaction((currentData) => {
  if (currentData === null) {
    return null; // Will delete node if data is truly null
  }

  const code = Code.fromData(currentData);
 
  if (code.isExpired()) {
    return; // Abort transaction, code is expired
  }

  return code.use(uid);
});

There are a few possible paths here:

The code exists — we fetch it and apply the update if it's valid.
The code doesn't exist — currentData comes as null from the server.
The code exists but is expired — we abort the transaction.

In the first case, the initial state is null, triggering the first if-block and returning null. Firebase automatically retries with the fresh server state, and the logic proceeds.

In the second case, the first run returns null, and when Firebase syncs with the server and still finds nothing, the transaction commits the null (effectively a no-op).

In the third case, the same initial null happens, but the second run receives the real data, sees that the code is expired, and aborts.

So what's the confusion?

It was this: what's the difference between returning null vs. undefined? Why does one retry and the other doesn't? What exactly happens under the hood?

Going a Bit Deeper

Understanding how Firebase handles transactions internally clears things up.

In RTDB, the transaction callback may first receive stale or incomplete local data—often just null. Firebase uses optimistic concurrency control: it starts the transaction with local cache data (which may be stale), then automatically retries with fresh server data if needed.

Here's how the return values work:

Returning undefined means: "Abort the transaction."
Firebase immediately exits with committed = false, no retries.
Returning any other value (including null) means: "Commit this value."
If you return null, you're telling Firebase to set the node to null (i.e., delete it).

The key insight: retries are driven by Firebase's optimistic concurrency model, not by what you return.

Back to our code:

if (currentData === null) {
  return null; // This will delete the node if data is truly null
}

This works because:

If the local cache is stale and currentData is null, Firebase automatically retries with fresh server data
If the server data is also null (record doesn't exist), Firebase commits the null value (no-op for non-existent data)
The retry mechanism is built into Firebase's transaction system, not triggered by returning null

No Transactions, Maybe?

After digging into the SDK and internal behavior, I wondered if a simpler design would work.
In my case, I just wanted to:

Check if a record exists
Read it
Possibly update it

So I tried replacing the transaction with a regular read and conditional write.

const snapshot = await codeRef.once('value');

if (!snapshot.exists()) {
  throw new Error('Code does not exist');
}

const code = Code.fromData(snapshot.val());

if (code.isExpired()) {
  throw new Error('Code expired');
}

await codeRef.set(code.use(uid));

This approach:

Uses 1 read (via .once() — which always goes to the server)
Writes only if needed
Avoids the retry logic and potential edge cases with transactions

It's simpler and faster if concurrent modifications aren't a risk — for example, if I've enforced uniqueness at a higher level (like preventing the same code from being used twice). But I hadn't done that. Multiple clients could try to use the same code at once. In that case, the transaction is still the safer and more efficient choice — because it gives atomicity out of the box.

And since RTDB charges by data transferred, not by operation count, the number of reads/writes doesn't matter as much — what I want to minimize is bandwidth, not function calls.

Just thought I'd share this — since getting my head around how Firebase handles transactions took me a while. Hope this saves someone else some time :)

Growing as a software engineer

Sat, 24 Aug 2024 00:00:00 GMT

Many software engineers face a common dilemma at some point in their careers: a feeling of stagnation or lack of growth. I will discuss what I think is helping me go over this. It's not based on science or anything, just my experience.

Prior to starting my first job, I was still a fresh grad, at that time I joined a couple of local and global communities, and this allowed me to be exposed to a set of skills I wouldn't normally have if I just got into a job. Being part of a community, organizing and hosting meetups, speaking and preparing content, leading a team, speaking to sponsors, dealing with different personalities... etc, and many other things I didn't imagine would be required in order to grow a local community group!

As one of the early organizers of a GDG (Google Developer Group) in Saudi Arabia, I learned firsthand the importance of leadership. Our goal was to establish GDGs in major cities, and that required leaders who could inspire and motivate others. The key trait shared by successful leaders in our community was their initiative and leadership skills.

Becoming a leader early in my career boosted my confidence and resilience. It gave me the courage to express my opinions in meetings with experienced professionals. It also teached me the importance of being reselliant in overcoming challenges, hard problems and human conflicts within the workplace.

Many people underestimate the value of activities like building communities or public speaking. They might argue, "What's the immediate return? I'm not being paid to spend that time. I'd rather learn a new language or tool." However, these activities are long-term investments in your career. Just like financial investments, the immediate return may not be significant, but over time, the value can grow exponentially. I personally view everything I do "for free" as an investment in myself, my social skills, my network, and more.

Now, let's talk about the growth you're probably looking for: becoming a senior software engineer. Reaching seniority isn't solely measured by the number of tools you master or projects you've completed. While technical experience is important, the soft skills that differentiate developers are often overlooked.

Who is a "senior" in a team environment?

A senior isn't necessarily the oldest or most technically skilled person. Instead, they are the individual with strong leadership and influence. If you're stuck, a senior should be able to help you, not by solving the problem directly, but by guiding you in the right direction, inspiring new ideas, and pushing you forward. A good senior won't make you feel bad for not being able to accomplish your assigned task.

When a team faces blockers or deadlines, a senior can identify the root cause, reallocate team members, create an action plan, and mitigate risks. These skills are not achieved by isolating yourself.

Having a depth while maintaing breadth

Since I started the first half of my career as a Flutter developer, I will tell this section from that angle, however it applies to everyone no matter the niche you choose. I learned Flutter and got my first job in it, and most of my contributions publicly were related to Flutter. While I admire this tool, and have reached a sufficient depth in it, what about my breadth?

After 2 years of doing mostly Flutter and mobile development, I started venturing into other domains and technologies such as web development, cloud, and even machine learning. This exploration wasn't just about adding new tools to my toolkit; it was about expanding my perspective and understanding how these different domains connect and overlap.

Maintaining a balance between depth and breadth is essential for long-term growth as a software engineer. In essence, as you grow in your career, don’t be afraid to venture outside your comfort zone. Embrace new technologies, explore different domains, and always be on the lookout for how you can integrate these new learnings into your existing skill set. This combination of depth and breadth will make you a more well-rounded, resilient, and innovative engineer.

Final thoughts

Your path will be unique, and while I've covered key aspects, remember that individual experiences and career paths vary. My final advice is to invest in both technical skills and soft skills. The benefits of strong interpersonal skills, communication abilities, and leadership qualities are often underestimated but can significantly impact your career trajectory.

My journey as graduate student with a full-time job

Sat, 17 Aug 2024 00:00:00 GMT

The beginning

In 2019, I graduated with a Bachelor's degree in IT, enthusiastic about the future. However, I was not sure what I wanted to do next. During my graduation project I learnt Flutter and Firebase, Flutter was still relatively new back then, but thanks to its fantastic documentation and supportive community, I was able to pick it up quickly and build a mobile app for my project.

After graduation, I started applying here and there, looking for any opportunity that would help me grow. Unfortunately, I was not able to find a job, so I started looking for something to do on my own that would help me grow and learn new things. Well... that was actually harder than I thought. For the next year and a half, I stayed unemployed, slowly losing hope and motivation.

Eventually, I did find a job, then another, but that's a story for another post. Today, I'm working remotely as a lead software engineer and pursuing my PhD. This brings me to the reason I'm writing this: to share my personal experience managing a full-time job and graduate studies.

Work-life-study balance...

So, did I find that elusive balance? The short answer is no. If you're searching for the magic formula, I'm afraid I don't have it. I'm writing this simply to share my journey. There might be a nugget or two of advice hidden within, but proceed at your own risk.

When I first started my current job, going back to school wasn't even on my radar. But after a year, I decided to apply to some universities in Riyadh, and surprisingly, I got accepted! This threw me for a loop. Should I do it? What would it cost me? Eventually, I decided to go for a Master's in Data Science, all while keeping my full-time job. The program's flexibility was a huge help, with classes starting late in the afternoon. My company was really supportive, and working from home saved me a lot of time, and honestly, my father's confidence in me and his constant support were the biggest reasons I went for it.

Truth be told, I barely studied. It was usually only a few days before exams that I even remembered what courses I was taking. This worked for me because of the years I'd spent in the industry (only 3, btw), mastering languages like Python and Java – skills that were directly relevant to my coursework. My real-world experience made the academic side feel much easier, and made more sense. So, my honest advice: if you're thinking about jumping straight from your bachelor's into a master's program, don't. Get out there and work. Figure out what you enjoy, learn as many languages as you can, master the fundamentals, and work on real projects. Then, and only then, should you consider graduate studies with clear goals in mind.

I graduated a few months ago, and the only truly stressful period was during my thesis. It coincided with some major work deadlines, and let's just say I'm not the best at time management. My procrastination habit put me under immense pressure from both sides. Procrastination... it's my biggest enemy, yet it's also something I've come to accept. My brain seems to function best under pressure, as unfortunate as that may be. If you're curious about what kept me so busy, here's a link to my research project – it was just published! 🎉

This video hits close to home – it's hilarious but also painfully accurate. If any of the points mentioned resonate with you, you'll definitely get a laugh (and maybe a bit of self-reflection) out of it.

Why PhD?

My interest in Machine Learning led me to pursue a master's degree. It's a relatively new and exciting field with lots of research happening, and I wanted to be part of it, to contribute to science in some way, even if it's just a little bit.

So here I am today, starting my PhD journey in just a few weeks! I know this post was a bit all over the place, but I hope you enjoyed reading it nonetheless.