It seems to me like the underlying issue was ignoring HTTP semantics and making a state-changing link like a logout link a plain <a> (HTTP GET) and not something like a form submission (HTTP POST).<p>Having intuition for the foundational layers of our tools saves so much time and future headaches.
> I didn’t want to deal with databases.<p>So instead I used a third party authentication service, store some data in JSON files, and also threw up a lamda gateway to store some more data in Google Sheets?<p>It's not relevant to the bug hunt, but I'm genuinely intrigued. Is this approach considered easier to work with than using a regular ol' DB?
> It is wild how decisions made in one part of a technical stack can manifest at another point in time, in another place in the stack, and in such a convoluted manner.<p>While this isn't something that _only_ happens in modern javascript, it certainly is a pattern. These bugs are convoluted and difficult to debug because the technologies are convoluted, stacked on top of each other compounding the bugs, and devs do not understand the underlying platform.<p>Honestly, it's once-again a good case study for why I'd stay from NextJS or "modern JS" devs (despite being in this ecosystem myself, Node/React/RN):<p>- NextJS, one of the most modern techs in wide use, makes debugging _harder_ than vanilla JS?? This is crazy
- Reimplementing browser behaviour in JS is _exactly_ what I would expect to be the root cause of various difficult-to-debug-and-to-fix bugs down the line
- Using GET for a logout is a misunderstanding of HTTP semantics. This could have broken in other ways (eg integrating turbolinks in the app).<p>Well done for debugging and fixing this, but honestly... this doesn't speak to the strength of the technology choices or the author's understanding of the platform
Authentication is a major hurdle. Back in the days of desktop software, there was no authentication. Mobile apps can often avoid authentication too. Despite decades of web coding, and lots of "this authentication system will make life easy" claims, it is still hard and easy to mess up.
OP learnt about idempotency in http the hard way. However the post reminded me that I don't particularly like this hydration step of NextJS apps where there is javascript executing that is difficult if not impossible to step debug.
So, in summary, because you added a whole bunch of stuff that didn't need to be there, it broke. Colour me surprised.<p>It sounds like this could be implemented almost completely without any of that, especially as you were using JavaScript for the data.<p>All I can hope is that you've learnt a lesson about unnecessary overcomplication.