Shows well why you likely don't want to use GraphQL. The chances you need the extra complexity and caveats are very slim.
Since this particular fad apparently doesn't want to die... this is a good reminder about why you want to do something simpler.
Definitely this. We tend to like complexity too much as a profession and field. It's also a good reminder that the complexity of the problem and the complexity of the solution shouldn't be conflated.
Keep things as simple as possible, they might turn out to be robust too.
With some tuning SQLite can go a long way, even for server type workloads. There are still a few caveats but in some case this can reduce complexity and cost quite a bit.
This is about a Rust library but equally applies to any ecosystem which allows to easily pull a dependency. As soon as you pull them, you need to monitor their health for the sake of your own project.
When guidelines contradict each other. You need a proper way to communicate where a piece of code stands.
Interesting how feeling stupid can actually push you toward good engineering practices, isn't it?
Interesting thinking about constraints and their rough classification as restrictive or enabling. I also liked how they're tied to complexity.
Definitely this, mind the complexity you introduce in your code. Looking smart is not the goal here...
Nice ode to simplifying web projects, to great effects. You can go a long way serving millions of requests if you choose your tools properly.
Word of caution on how we tend to reason about complex systems. They don't form a chain but a web, and that changes everything to understand how they can break.
Good reminder that the raw UNIX timestamps have interesting properties and often are enough not necessarily needing to rely on something more complex. Also gives nice criteria for picking between said timestamps and higher level types.
Interesting statistics, this show how important it is to have well structured and focused change sets as much as possible.
Things could indeed be more convenient... if this was the case we'd probably have less security breaches. Making super complex tools and then complaining that people are holding them wrong isn't gonna help.
Another testament to the fact that it's probably better to have minimal dependencies on your webpages. This is especially true for documents if you're aiming for longevity. If you're making an actual application the trade-off will be different.
Mind how you pick your dependencies and how they fare over time. You might need to reevaluate and let go some of them.
Maybe you don't need to pull even more dependencies. Think of the operational costs and the complexity.
Good reasoning, multi-page applications should be the default choice for web frontends architecture. The single page applications come at a cost.
Looks like the morbid fascination for microservices is fading. This is very welcome. This piece is a good criticism of this particular fad and gives an interesting theory of why it came to be.