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).
The problem with MCP resources is someone needs to stand up a server. That’s enough overhead and infrastructure that it slows down creating these kinds of resources and linking. Do any of the popular forge sites have like a GitHub pages but it’s MCP kind of capability? I think that would lower the hurdle for standing up such tooling so it would be much more appealing to actually do.
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.
> 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
The creator of REST, Roy Fielding, literally said this loud and clear:
> REST APIs must be hypertext-driven
> What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period.
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.
I love Firebase Hosting probably just as much as Netlify. Even more if you consider the various services besides hosting that Firebase offers. Thank you for making a great product! And if you're hiring, my email is in my profile :D
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.
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.
I'd guess a forward commitment, like a LTS version? That would probably have an adverse effect though, since you'd be the only provider that goes (e.g.) "We will support this product for at least three years from now", implying (to people making Decisions) you'd pull the plug after three years.
Maybe publish a long term (5+ year) plan / roadmap? idk.
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.
>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,
the issue is the inverse is also true: If you folks don't use it, we don't make money, and we deploy these resources elsewhere. See Parse
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.
