typically if we need to lazy load parts of the data model we make multiple calls to the backend for those pieces. And our redux state has indicators for loading/loaded so we can show placeholders. Is the idea that that kind of setup is inefficient?
That is true, there's a lot of "magic" that comes with boot. It can be helpful to take a look at what all of that auto-configuration code is actually doing, but reading that stuff is pretty difficult as well.
Interesting to see that fragmentation in versions being used. I guess that’s to be expected with a faster release cycle. 75% still on Java 8 is surprising though, isn’t it already EOL?
Linux Mint 20, which is based on Ubuntu 20.04, ships without any snaps or snapd, and has some kind of mechanism to prevent snapd from being installed by apt. Might be a good option for folks that like Ubuntu but want to avoid the snap fiasco.
that’s the whole point of the article though. Why should the “huge burden on the teams who maintain the stuff” be shifted to the customer who has less resources than Google to manage that burden. 12-15 months is not a long time. If you have to rebuild things that already work every year, you’re wasting a lot of time that could be spent building value for your customers.
the main thing here though is the older things you’re moving away from in those cases are still around. AWS didn’t remove classic load balancers and force you onto application load balancers.
> There were lots of reasons this needed to be done, one being tech debt. We realized that the original daily table structure wasn’t ideal. If we needed to query something over several days or months, it was terrible — lots of UNION ALLs or loops to crawl through days or even months at a time was slow.
Maybe i'm missing it, but there doesn't seem to be any discussion of the result. _How_ much faster was it after the change? Was it 11-months-worth-of-dev-time faster?
Shopify’s REST API returns 402s when the shop whose data you’re interacting with hasn’t paid its Shopify bill. Always thought it was an interesting usage cause the payment-required relationship is between the shop and Shopify, as opposed to the shop and the application hitting the API.
I'd recommend using an APM product off the shelf to get a lot of the mentioned functionality in the article (Monitoring, Tracing, Anomaly Detection). I would definitely _not_ recommend trying to roll all that yourself, unless you have a ton of time and resources.
There's a few good ones out there, we use Instana and it's working really well.
I really like the Cypher query language from Neo4j. Really hoping that Dgraph will have support for it in near future (it's on their roadmap: https://github.com/dgraph-io/dgraph/issues/1966 )