41–50 of 59 posts
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?
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?
> I didn’t want to deal with databases. 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? 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?
> I didn’t want to deal with databases. 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? 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?
My first thought as well. This is the most complicated stack I’ve seen for something so simple. Just convinced me more to avoid using JavaScript as a backend
It seems to me like the underlying issue was ignoring HTTP semantics and making a state-changing link like a logout link a plain (HTTP GET) and not something like a form submission (HTTP POST). Having intuition for the foundational layers of our tools saves so much time and future headaches.
This is a very good example where the HTML extensions that alex proposed here: https://www.youtube.com/watch?v=inRB6ull5WQ (TLDW: allow buttons to make HTTP requests; allow buttons & forms to issue PUT, PATCH & DELETE; allow buttons, forms & links to target elements in the DOM by id instead of only iframes) would improve the web platform. You could have a stand-alone logout button that issues a DELETE to /session or…
Earlier quoted context omitted.
Genuine question: How do you believe one should learn these semantics? This is more something I've been pondering myself recently, because I agree with you that the foundational knowledge for our work in any tech stack is usually the most important for understanding higher abstractions. But with so much to know it feels impossible to 'know it all' so to speak especially if you wear more than one specialized hat. Then…
It requires slowing down. Unheard of.
This seems appropriately relevant today: https://news.ycombinator.com/item?id=41208627
We (the industry) have built up so many layers upon layers and frameworks designed to make things easier that it just seems to attract newcomers to software engineering with this mindset that all it takes is to start with the sample-app for a high level framework, hack on it with trial and error until it does something they want, and then take to social media with proclamations of "Look! I built a thing! You can hire me to build your thing now!"
Earlier quoted context omitted.
> There was no form submission, I'm not sure where you got that. There was also no POST. OP was saying the logout function should have been behind a form submission / POST.
Ah, yes, I mean, agree that would have been technically correct, but like I said, its just not how a lot of the web works. auth0-nextjs seems to react to `GET` by default (though it might also work with `POST` and you certainly can override things)
Earlier quoted context omitted.
Ah, yes, I mean, agree that would have been technically correct, but like I said, its just not how a lot of the web works. auth0-nextjs seems to react to `GET` by default (though it might also work with `POST` and you certainly can override things)
So OP was correct that a proper use of the foundational layer of HTTP would have saved time, yours in particular, right? Also, I didn’t get your ”Claude predicted your tone smiley” thing. OP tone seemed polite and clear. Your tone, on the other hand, seemed defensive and dismissive. Even after you realizing that you initially misunderstood what OP said, adding a “I mean” and a “but I like I said” to reinforce you wer…
My comment about Claude was simply intended to giggle at how much it has us pegged, not to call out the op directly.
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.
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):
- 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).
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
Earlier quoted context omitted.
Why make it a link if you aren't linking to anything?
so you don't have to set "cursor: pointer" in css
Earlier quoted context omitted.
This is a very good example where the HTML extensions that alex proposed here: https://www.youtube.com/watch?v=inRB6ull5WQ (TLDW: allow buttons to make HTTP requests; allow buttons & forms to issue PUT, PATCH & DELETE; allow buttons, forms & links to target elements in the DOM by id instead of only iframes) would improve the web platform. You could have a stand-alone logout button that issues a DELETE to /session or…
I mean, it should just be a submit for a form with a /logout POST action. It’s standard and what web devs have been doing for decades