131–138 of 138 posts
In response to people's complaints about the usability of the HN Firebase API: yes. We're going to eventually have a new API that returns a simple JSON version of any HN URL. At that point we'll phase out the Firebase API, with a generous deprecation period. I'd be curious to hear people's thoughts about what a generous deprecation period might be.
How difficult would it be to host the same Firebase API on top of whatever will be driving the new JSON stuff?
Earlier quoted context omitted.
How difficult would it be to host the same Firebase API on top of whatever will be driving the new JSON stuff?
If you mean the documented API, it shouldn't be hard. If you mean reimplementing Firebase, that would be another matter.
Earlier quoted context omitted.
How difficult would it be to host the same Firebase API on top of whatever will be driving the new JSON stuff?
If you mean the documented API, it shouldn't be hard. If you mean reimplementing Firebase, that would be another matter.
Earlier quoted context omitted.
So is that to say it's just an unintended consequence of the data being hosted on Firebase? That's wild. Especially as I'd be surprised if most integrations aren't using this feature (IMO it's by and far the best feature of the API). To demonstrate, here's an example in 18 lines of code that v. efficiently listens to live updates to a profile (yours): https://codepen.io/theprojectsomething/pen/xxWBOWN?editors=1...
It was certainly an unintended consequence of the data being hosted on Firebase. I'm not saying it isn't a valuable feature! And if people are doing interesting and useful things with it, I'm open to implementing something to keep that going—as long as it's simple and there's a clear line between it and "reimplement Firebase", which would be a foolish thing for us to try to undertake.
To that point there's definitely a few OSS solutions out there that provide this kind of functionality out of the box (recent YC alumni among them). But then who knows what problem you're trying to solve. Sounds like this is just rain on the tip of the iceberg.
Earlier quoted context omitted.
The great thing about the Firebase API is that it's live, so you can subscribe to updates to a post/comment/profile and see them as they're made (no polling, just websockets). I'd hope any future version would retain this feature. I'm reluctant to lose it as I'm about to release a browser extension that relies on it pretty heavily :) [Edit]: this feature is undocumented in the link above, but it's a standard feature…
Hmm. I'm sorry but I can't promise that. It isn't part of the HN API, though I can understand why people use it since Firebase offers it.
Earlier quoted context omitted.
Hmm. I'm sorry but I can't promise that. It isn't part of the HN API, though I can understand why people use it since Firebase offers it.
Oh, does that mean the /v0/updates endpoint will disappear in the new API? I found it to be quite valuable.
In response to people's complaints about the usability of the HN Firebase API: yes. We're going to eventually have a new API that returns a simple JSON version of any HN URL. At that point we'll phase out the Firebase API, with a generous deprecation period. I'd be curious to hear people's thoughts about what a generous deprecation period might be.