Living APIs, and the Case for GraphQL
It’s hard to read exactly where GraphQL stands in the API world right now. Available publicly since 2015, trends in APIs aren’t obviously moving in its favor, but not obviously moving against it either. Interest from the developer community has been steady throughout even if the technology isn’t spreading like wildfire. Its biggest third party proponent is GitHub, who released the fourth version o
Reflections on Rust, and the sand castle metaphor — brandur.org
A month ago, I wrote about how I was frustrated with my progress in Rust. These days, I’m still no expert, but I’ve made progress. Programming languages get easier to learn the more of them you know. A lot of this is just pattern matching: syntax changes, but there’s a lot of overlap in features, and the similarities get more apparent. Some of my recent acquisitions have been very fast to learn –
Touring a Fast, Safe, and Complete(ish) Web Service in Rust
For years now, I’ve been having a crisis of faith in interpreted languages. They’re fast and fun to work in at small scale, but when you have a project that gets big, their attractive veneer quickly washes away. A big Ruby or JavaScript (just to name a few) program in production is a never ending game of whack-a-mock – you fix one problem only to find a new one somewhere else. No matter how many t
Scaling Postgres with Read Replicas & Using WAL to Counter Stale Reads — brandur.org
Scaling Postgres with Read Replicas & Using WAL to Counter Stale Reads A common technique when running applications powered by relational databases like Postgres, MySQL, and SQL Server is offloading read operations to readonly replicas 1, helping to distribute load between more nodes in the system by re-routing queries that don’t need to run on the primary. These databases are traditionally single
Implementing Stripe-like Idempotency Keys in Postgres — brandur.org
In APIs idempotency is a powerful concept. An idempotent endpoint is one that can be called any number of times while guaranteeing that the side effects will occur only once. In a messy world where clients and servers that may occasionally crash or have their connections drop partway through a request, it’s a huge help in making systems more robust to failure. Clients that are uncertain whether a
Using Atomic Transactions to Power an Idempotent API
The software industry as a whole contains a lot of people doing a lot of different things, but for every developer working on new embedded firmware, there’s about ten building the linchpin of modern software – CRUD apps that serve requests over HTTP. A lot of these apps are backed by MVC frameworks like Ruby on Rails or ASP.NET, and backed by ACID-compliant relational databases like Postgres or SQ
The Limits of Copy-on-write: How Ruby Allocates Memory
Anyone who’s run Unicorn (or Puma, or Einhorn) may have noticed a curious phenomena. Worker processes that have been forked from a master start with low memory usage, but before too long will bloat to a similar size as their parent. In a big production installation, each worker can be 100s of MBs or more, and before long memory is far and away the most constrained resource on servers. CPUs sit idl
How Postgres Makes Transactions Atomic
Atomicity (in the sense of “ACID”) states that for a series of operations performed against a database, either every one of them commits together, or they’re all rolled back; no in between states are allowed. For code that needs to be resilient to the messiness of the real world, it’s a godsend. Instead of bugs that make it to production changing data and then leaving it permanently corrupt, those
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
