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.
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 of FB and works as expected in all client libraries https://firebase.google.com/docs/database
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.
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.
Thanks, appreciate the insight! I think client pub/sub is the feature request, not firebase clone :)
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.
Oh, does that mean the /v0/updates endpoint will disappear in the new API? I found it to be quite valuable.
It depends on how hard it is for us to implement something like that in HN's software. I'm sorry not to have a clear answer for you guys, but we haven't had a chance to think carefully about this and it will be a while before we do.
I'd say it depends on how straightforward the new API will be. The app I use (Materialistic) is both free and ads-free. So I don't expect the developer to drop everything they are doing to update it if will require a lot of work. So 6 months minimum if everything is well documented, a year if it will be a hassle.
I use materialistic also, but as far as I'm aware that hasn't been an update to the app in years. In addition I believe the materialistic app listing on Google Play is also been removed.
Do you have some updated version that I'm unaware of?
I would say a full calendar year is "generous" from the announcement date
Can you allow login and write operation via the API?
I want to build a HN web client but it's not possible without scrapping the site which won't scale.
Im typing this from the iOS app HACK which somehow allows for writing comments and upvoting etc.
They have to scrape the site in the background to work. While this is doable, any such client will need to follow the HN bot policy which limits the scrapping speed.
Another issue is browser only client. If HN has set proper cors (I didn't check if it is the case), then you cannot build a web client through scrapping without proxy.
Probably not in the first release, but hopefully after that.
6 to 12 months AFTER we have dark mode.
I'd say about 6 months.
Honestly, it would be nice if the Firebase API were updated. You could even build the former on the latter, so JSON urls pull from the API.
Just being able to get an entire thread in a single request alone, and filter queries would make things much easier.
How difficult would it be to host the same Firebase API on top of whatever will be driving the new JSON stuff?
Yes. At the very least some kind of pub/sub interface? Also worth noting that, if it's the data depth issue that's looking to be resolved, the Algolia API is often useful in places the Firebase structure falls short.
If you mean the documented API, it shouldn't be hard. If you mean reimplementing Firebase, that would be another matter.
Id do the opposite, Id build the new json stuff on top of the firebase api.
Just keeping the old API functional for its clients, really.
As a dev who has built a Hacker News client app, I would say at least 12 months.