Any time something is adopted as broadly as JavaScript it's going to be a mess. Even outside the world of computing. Take... city planning. Cities are a mess. In fact human civilization is one big freakin' mess.
Wouldn't it be nice if we could start over and apply all the lessons we've learned over the generations? The world would be a much better place!
Or would it?
We'd end up with yet another mess. It'll be a different mess but it'll be a mess nonetheless. Or worse - we'll end up with two big messes instead of one big mess!
> Also, since you’re probably deploying containers to production, it’s useful to have a similar environment for local development so that you know what will actually happen in production.
This such a complete and utter lie and I'm surprised people in 2022 still believe it.
You do know what's happening when you run Docker on your Macbook, right? Right?
Ignoring your tone, here’s a concrete example: I was debugging a HTML-to-PDF service that was crashing for some payloads, but I couldn’t reproduce the problem locally.
I used Docker to run the application using the exact same image that was deployed to production, and was able to replicate the issue.
Why? Because the PDF renderer depended on loads of finicky dependencies (e.g. linked libraries), and it turns out that the default fonts in our base image didn’t support the Unicode code points in the example payload. I couldn’t replicate this outside of Docker because I have a completely different set of linked libraries and don’t stack.
you always have that option though and i assumed it was a fairly common debug thing to have to do if you use docker enough. not just for the times it works (ie you find a bug between the layers) but for all the times it isn't the culprit.
the other post mentioned setup, so i thought he meant they imposed presetup containers for developers to use?
Your frontend team needs an API call that retrieves only friend requests with user names/avatars because the current API call is too heavy.
Normally they'd go to the back-end team and ask them to add an endpoint or modify an existing endpoint to give them the exact data they need. The problem with that is global API surface area becomes more complicated. Complexity is bad because more mistakes are made.
With this model your front-end team can implement the endpoint themselves in the BFF and model the response data exactly as they need it.
They also don't need to deal with that one zealot on the back-end team that gives everyone a hard time about tiny irrelevant issues.
Not really. When you turn off recommendations, the app icons are hidden but the space for recommendations stays there! Yes, just a big ol' block of whitespace with a prompt to turn recommendations back on. It takes up like 30%+ of the start menu.
Yeah, unless you have it earmarked for something today it isn’t worth having cash lying around except for buffer funds. It’s a bad time all around right now. Best off sitting on investments for the foreseeable future.
Right, I was just pointing out the flaw in the parent commenter's statement. You can't do "code version is tied to your database version" - that's just not a thing.
It really is a lot more practical. Most webapp devs using SQL databases spend a bunch of time engineering some notional failover into their app that's completely undermined by using a non-HA datastore, a bunch more time mapping data to and from square tables where it doesn't really fit, and end up with a system that's still last-write-wins at the user-facing level. And the ones where it isn't aren't because they used those SQL transactions, but because they wrote their own versioning layer on top.
so there's that