Yeah, it does lose something in the more realistic performances. Was still fun to play with though!
895 karma · joined April 14, 2008
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...
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 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.
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.
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.
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.
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.
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.
Or my second question: wait, doesn't this sound an awful lot like Pied Piper's product from the newest season of Silicon Valley?
Otherwise, there aren't enough interview questions in the world to tell you the important stuff.
When 40% of the people in your city want to move away, you know there's a problem.
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 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.
1. Use the Realtime Database as a communication channel to trigger a Cloud Function that then sets up the thing you need.
2. Create an HTTPS function and call it directly from your app, then do the work you need.
Additional languages will come, but we're starting with Node.js. We'd rather take the approach of doing one language really well than a bunch of languages with a poor developer experience.
However, if you go offline and then try to refresh the content, none of it will be persistently stored or accessible until you go back online.
https://events.google.com/io2016/schedule?filters=Firebase&s...