mbleigh

Yeah, it does lose something in the more realistic performances. Was still fun to play with though!

FWIW I actually agree that the original is funnier in its delivery!

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...

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.

Founder of Divshot here, and engineering manager of the Firebase Hosting team. Thanks for the shoutout! :)

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".

What effect does a transfer protocol have on the average user? If they knew, why would they care? Genuinely curious.

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.

v6.9.1

Well, Cloud Functions for Firebase isn't the only thing we're working on... ;)

You can definitely do this! There are two ways that readily come to mind:

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.

Firebase engineer here.

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.

Firebase engineer here -- what don't you like about the Firebase Console? Any specific things that we could improve?

A solution is under active development. We don't communicate timelines, but it's a high priority for the team.

Firebase Storage launched today and is perfect for things like storing video! https://firebase.google.com/docs/storage/

The Firebase JS SDK currently supports non-persistent offline. So long as you keep the tab open, Firebase works great offline!

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.

Check out my I/O talk on Friday (Progressive Web Apps on Firebase). While the Firebase Web SDK doesn't support persistent offline just yet, we do have some new ways to get the job done.

https://events.google.com/io2016/schedule?filters=Firebase&s...

Firebase projects are deeply integrated with Google Cloud, so you can spin up backend resources such as Google Cloud Functions, App Engine, and Compute Engine. Using the Node.js server SDK you can watch for changes in the Firebase Database and act on them. We're thoughtfully considering more holistic ways we can help here.

The console was deprecated in favor of a new console that lives in the larger Cloud console.