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).
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.
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.
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.
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.
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.
The Firebase Realtime Database has been around for ~5 years (and is still fully supported after this launch).
Cloud Datastore has been around in some form (started as App Engine Datastore) since 2008.
Cloud Firestore was a massive multi-year joint effort between Firebase and Google Cloud. Google is investing heavily in both, and this is a big deal for our teams.
I'm surprised the FAQ doesn't answer the question that immediately came to mind: why should I risk my data with an untested startup when the only benefit is claimed performance/price?
Or my second question: wait, doesn't this sound an awful lot like Pied Piper's product from the newest season of Silicon Valley?
If you need to ask them these questions that's an employee, not a cofounder. Maybe it's an employee with a big chunk of equity, but in general you should have a pre-existing professional relationship.
Otherwise, there aren't enough interview questions in the world to tell you the important stuff.
This author seems to be afflicted by a crippling short-sightedness. I stopped reading when I hit the sentence about autonomous cars being "just a new type of car".
TypeScript isn't higher level than JavaScript. It is JavaScript, just with a lightweight type system. It doesn't make things "easier" than JS, it makes the process of building large JS apps less error-prone.
I (barely) tolerate the bay area to get to do the work I love. It's a permanent game of weighing pros and cons and doesn't feel sustainable long-term even working at one of the best-compensating companies on the planet.
When 40% of the people in your city want to move away, you know there's a problem.
Is it possible things will change? Of course. I was just trying to illustrate that, unlike Parse and Facebook, Firebase has a clear relationship with core Google businesses.
We will never be able to fully dispell these worries, but I think there's pretty strong evidence in support of Firebase's prospects. Our developers will have to judge if the value we deliver is higher than the small-but-non-zero chance of it going away.
I certainly think it is, but I'm pretty biased. :)
Firebase engineer here. We recognize the anxiety that comes with a hosted solution. That being said, Firebase has seen enormous and growing investment from Google (see e.g. Fabric acquisition).
Firebase feeds directly into two huge businesses that Google cares deeply about: Cloud and Ads. I can't predict the distant future, but unless Google's core business shifts drastically Firebase isn't going anywhere.