mbleigh
Joined 18 years ago
Karma
895
Submissions
194
Member since
Apr 14
Firebase engineer, former founder of Divshot.
View on Hacker NewsRecent submissions
Comment · 11 months ago
Yeah, it does lose something in the more realistic performances. Was still fun to play with though!
Comment · 11 months ago
FWIW I actually agree that the original is funnier in its delivery!
Comment · 1 year ago
Fair, but the person who coins a term generally doesn't ultimately decide how it's going to be used, see vibe coding for a more recent example.
REST API became colloquially defined as "HTTP API with hierarchical URL structure, usually JSON". I wrote about the very phenomenon 15 years ago! https://www.mobomo.com/2010/04/rest-isnt-what-you-think-it-i...
Comment · 1 year ago
Heh, the problem with having a half drafted post on your machine for a few weeks is the industry moves fast!
I had the post pretty much done, went on vacation for a week, and Claude Skills came out in the interim.
That being said Skills are indeed an implementation of the patterns possible with linking, but they are narrower in scope than what's possible even with MCP Resources if they were properly made available to agents (e.g. dynamic construction of context based on environment and/or fetching from remote sources).
Comment · 1 year ago
Totally agree, the web itself is absolutely HATEOAS, but there was a type of person in the 2000s era who insisted that APIs were not truly RESTful if they weren't also hypermedia APIs, but the only real benefit of those APIs was to enable overly generic API clients that were usually strictly worse than even clumsily tailored custom clients.
The missing piece was having machines that could handle enough ambiguity to "understand" the structure of the API without it needing to be generic to the point of uselessness.
Comment · 2 years ago
TL;DR GraphQL isn't really the problem, untrusted clients executing arbitrarily complex queries is the problem. This is why authz is hard, why rate-limiting is necessary, why "query complexity" calculations are necessary...
At Firebase we chose GraphQL as the basis for our new Data Connect PostgreSQL product (https://firebase.google.com/products-data-connect) despite acknowledging pretty much all of the issues outlined in this article as correct.
GraphQL is an excellent IDL (interface definition language). It's compact, it's flexible (through directives), and there's literally no better way I'm aware of to rapidly construct complex nested relational queries. But the promise of "clients can fetch whatever they want" adds an enormous burden to backend developers because you have to secure yourself against queries of arbitrary shape and complexity.
In reality you don't want clients to "fetch whatever they want" because clients can't be trusted. The path we took is that developers can predefine the queries that are needed for their client, and then only those queries can be executed from an untrusted client.
This approach provides a surprising number of benefits - you get the flexibility of nested queries and field selection, the end-to-end strongly typed structure of a schema-driven API, and the ability to reason about security like it's a custom backend.
Comment · 8 years ago
FWIW providing access logs is something we're exploring (though it's still a ways out).
I certainly hope that you don't feel the need to move to something else when your application scales / gets more complex -- our whole mission is to make it so you don't have to. Feel free to reach out to me on Twitter (@mbleigh) if you have specific questions/concerns.
Comment · 8 years ago
Founder of Divshot here, and engineering manager of the Firebase Hosting team. Thanks for the shoutout! :)
Comment · 9 years ago
Yeah, unfortunately this is pretty much an unsolvable problem.
Roadmaps are subject to change and even more subject to be delayed, publishing them tends to disappoint more than reassure. If we gave a forward commitment the questions would just be "why not longer?" or "what happens in X + 1 years?".
All we can do is say what I'm saying now: we stand behind this product 100%, we think it solves real problems for developers, and we really hope people will try it out and find it useful.
I get the doubt, truly I do. But Google's incentives are clearly aligned with Cloud Firestore's success: if you folks use it and grow your app to be successful, we make money. If you use it and really like it, you're more likely to use Firebase and Cloud's other products, which will make us even more money.
Comment · 9 years ago
We announced the product, that's a loud public commitment. Once it reaches general availability, it will be covered by the Cloud deprecation policy requiring a minimum of one year notice for deprecation.
I'm not sure what other guarantees would even make sense to offer. If anything, I'd look at this announcement as ongoing proof in the magnitude of investment Google is making in Firebase and Cloud.