Wrong about laravel being unreliable

I just want to apologise to this community. I recently made a post where I claimed laravel was unreliable for enterprise.

It turns out it was me, not laravel.

I spent days going through server logs, checking configs, checking environment settings, checking php and laravel logs, doing extensive tests.

I found out that some of the data was "dissapearing" because:

1. the api throttling was turned on
2. the api request validation sometimes failed because of user input. as in, people entered decimals and the validation was expecting an whole integer.

This is why I couldn't find anything in the logs. It turns out that no actual error needed to be logged because I am a fucking idiot.

28 thoughts on “Wrong about laravel being unreliable”

  1. I had a suspicion that it might have been throttling, but I didn’t get a chance to post it (and figured it would show up in the logs).

    I’m glad you got it sorted! Moving forward, will you be adding logging to catch these sort of issues?

  2. > the api throttling was turned on

    I do kind of wish throttling wasn’t on be default. Let me set limits like this if I need them vs enabled with a rather arbitrary default…

    (But good front end logging should catch the API call failures.)

  3. My dude, I want to thank you for posting this. Not only is it uncommon and commendable these days for someone to admit to being wrong, this post could lead people having similar problems to your first post to the solution. Well done!

  4. This is a sign of maturity. Good for you to be able to accept your mistakes. As a developer, these things can only be solved through experience. Good luck with your journey.

  5. This is what I call the middle level ego. As junior you’re kind of like, “all of this stuff is amazing, I want to know more”. Then you learn a lot and think “I can do all of this now, I know all the tools” but when something goes wrong it’s like “I can do all of these things, I don’t need X thing holding me back”.

    Eventually you hopefully humble and realise you were good at playing with tools and you eventually start to make your own and realise how hard it is to make good tools that satisfy real requirements, how you have to make decisions about trade offs. Then you’re at a senior level.

  6. Good on you for posting this.

    It’s like I was telling a friend the other day: My code does exactly what I tell it to. Sometimes that leads to a misunderstanding between me and the computer.

  7. I mean, it could be worse. You could just say that “Laravel sucks” and come up with no arguments even for it (my outsource client).

  8. Admitting your mistake… you sure you belong on reddit šŸ™‚

    That is awesome!

    I too have fallen for the throttling and in a first time product rollout.

    This was probably 5.2 or so. And in my case it wasn’t the API throttling but with rate limiting.

    Unit tests – pass.

    Simulated stress test – pass.

    Live action group participation showing the product to a group of 200 in the same room on the same connection / IP and face plant.

  9. Good on you to admit this. Would love to hear how you discovered/diagnosed the problem if it wasn’t showing up in logs…. Reading after action reports is kind of my favorite!

  10. If you’re wanting to push the server even further, there’s also swoole, though it can cause headaches with db pooling, and sessions if not setup correctly.

    Alternately think out of the box when dealing with slow api requests. Maybe use go or rust for a few endpoints. Also learn to use explain to diagnose queries. Eloquent is great but some queries are better done using raw sql.

    Laravel isn’t the most performant, but it’s full of bells and whistles that make building solutions easier and faster. For reddit and Facebook scale apps you’re gonna hit headaches scaling but even most enterprise apps serve a lot less users, and with good devops you can scale out to multiple servers, load balancers, etc.


Leave a Comment