• Frist (unregistered)

    Frist backend user.

  • The Mole (unregistered)

    If just disabling the browser caching fixes it then that almost certainly means it is a back-end issue of the application not sending the right cache control headers ( and/or poor api design)

  • Chris (unregistered)

    Gah, that problem when even the boss knows an employee is a problem, but not quite enough of a problem to be worth going through the process of firing them, hiring someone new and training the new person up.

  • (nodebb)

    Eric is a huge back end - for a front end guy.

  • Bubba (unregistered)

    Good to see some new blood on remyporter.com

  • (nodebb)

    As The Mole says, TRWTF is that the evidence described here points unambiguously to this being a backend issue: responses from URLs that serve user-specific content being cached, due to inappropriate caching-related HTTP headers.

  • NoName (unregistered) in reply to The Mole

    For that unique identifiers are placed in the URL to bypass the local browser cache.

  • Brian (unregistered)
    ... while Gary is trying to debug a large Perl regex ...

    Hey, I think I spotted today's WTF.

  • Raj (unregistered) in reply to Cabbage

    You don't know that. Maybe the front-end guy caches everything in localStorage using JavaScript , there's nothing the backend people can do about it.

  • (nodebb) in reply to The Mole

    Do you mean to you, anything server-side is back-end? Cache-control headers are managed by the web-facing code, not the data manipulation code. That's front-end in my book.

  • Andrew (unregistered)

    Eric and Gary have had in a couple danger close incidents.

    Er, what?

  • (nodebb) in reply to Cabbage

    @Cabbage - not at all. Why would a back-end send HTTP headers? Where I currently work, the back-end communicates over TCP/IP directly. It's up to the front-end guys to set their headers.

  • Free Bird (unregistered) in reply to Medinoc

    Your book is wrong. The question you pose in the first sentence should be answered affirmatively.

  • Little Bobby Tables (unregistered) in reply to Free Bird

    Everything from the screen on inwards is back end. The front end starts where the screen stops and the chair begins.

  • Melnorme (unregistered)

    I was expecting him to be fired, boooo

  • Argle (unregistered)

    Here we have a classic case of the Dunning-Kruger effect.

  • JB (unregistered) in reply to The Mole

    Thanks for explaining that Eric.

  • Wizofaus (unregistered) in reply to The Mole

    My first thought too! Even a stopped clock is right twice a day...

  • Wizofaus (unregistered) in reply to Brian

    I thought it was having 10000 lines of code refer to the same variable...

  • Wizofaus (unregistered) in reply to Raj

    Disabling the browser cache (or even restarting the browser) wouldn't help if that were the case. In fact it's hard to think of any way it which it might be the front end developer's fault based on what was described. And as a back end dev I'm always happy to blame the front end if something's not working (like yesterday when I found it was trying to POST to my GET-only endpoint, clearly described as such in the doco)

  • Wizofaus (unregistered) in reply to Raj

    Disabling the browser cache (or even restarting the browser) wouldn't help if that were the case. In fact it's hard to think of any way it which it might be the front end developer's fault based on what was described. And as a back end dev I'm always happy to blame the front end if something's not working (like yesterday when I found it was trying to POST to my GET-only endpoint, clearly described as such in the doco)

  • Matt (unregistered)

    I've been reading TheDailyWTF for years, and this article was one of the hardest to actually read. It's in dire need of an editor.

  • Ray (unregistered) in reply to The Mole

    Not necessarily, I have the issue all the time at work with Internet Explorer when it comes to AJAX. IE caches AJAX GET requests, when it sees a new AJAX GET request, it checks its cache, and if it sees a request already in there that is the same as the new one, it just pulls it from cache.

    To get around that, I do as others undoubtedly do, which is append a random number (I use the current timestamp in milliseconds) to the URL, that forces IE to ignore the cache and fetch new from the server.

    So far, IE (and its derivs, I have detected this problem in IE, Edge, and C# HttpClient) is the only browser to have this issue, Chrome, FF, Opera, Safari, etc... all just go back to the server and never look at cache.

  • (nodebb) in reply to Cabbage

    But there was nothing about the server sending the wrong cache control headers. The front-end guy was just unilaterally caching everything "because the back end is so slow". Knowing how he was managing to do that in the first place I think would be crucial to understanding whose problem it was.

  • Barf4Eva (unregistered) in reply to Mr. TA

    Well, Eric should definitely be the back end of jokes.

  • Olivier (unregistered) in reply to Mr. TA

    Well, I think Eric is also a front end guy, especially the pipe part...

  • linepro (unregistered) in reply to Little Bobby Tables

    PEBKEC

  • Ronny (unregistered) in reply to Ray

    All browsers do this. The trick of adding ?_dc={timestamp in ms} to url's is customary if you absolutely need to have the latest, uncached version.

  • (nodebb) in reply to Little Bobby Tables

    "The front end starts where the screen stops and the chair begins."

    That's usually the bell end.

  • medievalist (unregistered)

    Developers arguing over front vs backend often forget there's a sysadmin piece or two in the middle.

  • Free Bird (unregistered) in reply to medievalist

    What's your point?

  • Chris (unregistered) in reply to Jeremy Pereira

    Nice.

  • Decius (unregistered)

    Is the browser showing cached data? If you were still logged in as a superuser, would you have to refresh the cache to get the current information?

  • (nodebb)

    TRWTF is that they're not all "full-stack" developers.

  • (nodebb)

    Developers arguing over front vs backend often forget there's a sysadmin piece or two in the middle.

    QFT. If the issue has to do with caching headers sent by the webserver, then that's not development at all, it's server configuration.

  • Ashley Sheridan (unregistered) in reply to NoName

    No, NoName, that is not how you handle cache control. That's how front-end devs that don't know how to do cache control handle cache control. Use cache control headers, or E-tags, don't add dummy data to the URL to force bypassing the cache.

  • swati gandhi (unregistered)

    Thanks for doing this detailed tutorial! I hope by the time I will need it, This is a very inspiring post! From my point of view, information expressed in your writing style is superb … Great job!!

  • swati gandhi (unregistered)

    You have written a amazing post. The info provided is just awesome. And the tips which you have shared are really great. By following these tips we can build blogging community easily. Thank you so much.

  • 🤷 (unregistered)

    Huh. Eric sounds like the sysadmins at my old job. For them, everything was a developers problem. Even if the problem was within an application the admins bought from an external company. If something was wrong they'd say "Well, this is a program, right? And developers program. So it's their job to fix it".

Leave a comment on “A Problem in the Backend”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article