Google Shuts Down the Google Feed API | Hacker News Reader

Google Shuts Down the Google Feed API

developers.googleblog.com

90 pointsalanfranzoni84 comments

From [1]:

> What is the Google Feed API?

> With the Feed API, you can download any public Atom, RSS, or Media RSS feed using only JavaScript, so you can mash up feeds with your content and other APIs with just a few lines of JavaScript. This makes it easy to quickly integrate feeds on your website.

"To quickly integrate feeds on your website".

The latest API deprecations and product removals (everywhere, not just at google) are part of what I believe to be a growing trend to take away the ability for the end users to be publishers and to bring them back to be passive consumers (like in the old radio / TV days).

[1] https://developers.google.com/feed/

Reminds me of a rant I read recently, on why Apple killed HyperCard.

> The reason for this is that HyperCard is an echo of a different world. One where the distinction between the “use” and “programming” of a computer has been weakened and awaits near-total erasure. A world where the personal computer is a mind-amplifier, and not merely an expensive video telephone. A world in which Apple’s walled garden aesthetic has no place.

> (...)

> The Apple of Steve Jobs needed HyperCard-like products like the Monsanto Company needs a $100 home genetic-engineering set.

http://www.loper-os.org/?p=568

Personally, I've lost my faith in Google, Apple and other "hip" IT companies long time ago. They feed us toys, instead of tools. Not sure if they do that on purpose or because they think Moloch/Market demands it, but they do so nonetheless.

Serious question: Why would Apple then create Swift and Swift Playgrounds for iPad in order to get more people to program? Seems like they are giving us some tools.

My current theory: they need more programmers making stuff they can sell for iOS. Popularizing Swift is beneficial to them because it still technically keeps people locked in the Apple ecosystem (a kind of soft lock-in - they've opened the language, but it's still primarily supported by Apple).

Increasing the pool of hirable developers does not otherwise exclude selling computing toys to the general population.

I haven't heard of Swift Playgrounds for iPad before. I've just finished watching its demo - I must say, it looks nice and has some cute solutions for entering code via touch interfaces (like that for-loop dragging thing) that I hope will spread around to other applications. That said, it's an educational app - I can learn some Swift with it. But what can I actually program with it? Can I use it to make my calendar talk with my SMS app? Or with my Bluetooth headset?

That's the thing I complain about when I say that mobile devices are developed as toys, not tools. You're always limited to some functionality provided by the vendor and third party apps. Apps that don't talk to each other, that restrict your choices to few operations their authors thought about. Not to mention apps that increasingly want to suck out and monetize all your data, but that's beside the point. On Android we have Tasker, which is something that I believe should be a default component of Android (albeit it could use some ideas from Swift Playground to make UX better). But it isn't, and the current trends in mobile, web and desktop suggests it'll never be - the end user is forbidden from using the computer, they must only ask their apps for services.

Yes you can.

Swift Playground has full access to the iOS APIs.

https://developer.apple.com/videos/play/wwdc2016/408/

I applaud Apple for this, as it makes the developer experience closer to the Xerox PARC ideas.

EDIT: typo have => has.

I think rather than assuming malice, assume either incompetence or different goals.

The saying I've heard is that most people want elevators, but we've been selling them helicopters and blaming them when they crash.

Someone who is largely computer illiterate can download and run apps without any fear of messing things up. There is essentially no malware for iOS. They can always exit the app. They can always delete the app. If the app wants to get the user's location, or email, or documents, or pictures, it has to ask for permission from the user. The app will not mess with things that the user can't figure out - there are easy ways to check (and in some cases limit) space usage, bandwidth usage, and battery usage. Apps are now safe.

This is an amazing achievement!

However, apple has not yet figured out how to safely enable development at the same time. They're getting closer, but they're not there yet. It is obvious that that was not their top goal. There are already lots of general purpose computing devices, and if you want development access to your device, you can get it as a developer.

Think of tools as apis to use and integrate existing services in their ecosystem into your own. A programming language is not that.

I'm not an iPad user, but hasn't Apple had a long-running policy of forbidding any app which includes an interpreter?

I've seen this being mentioned for years by various programming communities (e.g. Squeak Smalltalk), where the only work around is to buy a Mac, buy OSX, buy the Apple developer tools ("Xcode"?) and pay a $99 subscription fee in order to transfer your own app to your own iPad.

> I'm not an iPad user, but hasn't Apple had a long-running policy of forbidding any app which includes an interpreter?

That policy was rescinded almost 6 years ago: http://daringfireball.net/2010/09/app_store_guidelines and had been instituted only a few months earlier: http://daringfireball.net/2010/04/why_apple_changed_section_...

IIRC there's a policy against running downloaded code (at least automatically downloaded code) in anything but the bundled JS runtime, but bundling an interpreter in an application and running user-provided code is not an issue. You can run a Python app on iOS (e.g. via Kivy) and there are Python interpreters in the appstore.

> buy the Apple developer tools ("Xcode"?)

That's free (with a mac and OSX obviously): https://itunes.apple.com/app/xcode/id497799835

> and pay a $99 subscription fee in order to transfer your own app to your own iPad.

The developer account is only necessary to publish in the store, since Xcode7 and iOS9 you can sideload applications with a regular appleid: http://www.howtogeek.com/230225/how-to-sideload-apps-onto-an...

To be clear, you can sideload to a device without paying, but you still can't use all the features. If you want to make an app that uses App Groups, for example, you have to have a paid account. There's no way to even test it without paying your annual Software Development Tax.

I don't understand why this has been downvoted so aggressively. I didn't say anything inaccurate. You can't develop an app that uses App Groups without a paid developer program account. You can't even test such an app locally on a simulator without a paid account.

I think your info is a bit outdated (and some incorrect). Buy a mac (or ignore the Eula and run OS X in a VM), install the dev tools (free), install the app on your iPad (free). If you want to publish, there's a fee (per year).

They don't forbid interpreters. But they forbid downloading code into these interpreters.

Ie running what the user types is OK.

(At least as far as I remember.)

Your free to down load code now, many of the interrperters come with build in support for version control now.

This is the downside of free services. They can be easy to get started. But will bite back when they go out. It has been hard to trust Google after they took reader down.

Sounds kind of like Yahoo Pipes. Is that still around?

Pipes was shut down in fall of 2015.

relevant HN article [1]

[1] https://news.ycombinator.com/item?id=9660682

Is that all it does? I'm sure there are other services out there that do exactly this. Does anyone know of any?

Check out riko [1]. It was developed to programmatically replicate Yahoo Pipes (without the UI). But as it stands, I'm pretty sure it can do most of what google feeds does.

[1] https://github.com/nerevu/riko

(full disclosure: I'm the lead dev.)

Writing a system that (correctly) interprets the zillion flavors of "RSS" out there and presents them with a common API is non-trivial. An 80% solution is pretty easy, and a 90% solution isn't that hard, but a near-100% solution will take you into some very dark and ugly places.

I don't know of any service that does this as well as the Google Feed API did. If someone else does, please share.

Well, start the service, state you use RSS library X and that you will keep it updated and send people over to it for bug reports and contributions.

Ah but RSS is a standard, so where's the problem? One method to recode them all surely?

I jest, I'm the author of http://www.weegeeks.com - I know only TOO well, how there is no such thing as a 'standard' RSS feed... (sigh)

So yeah, I get your point.

Superfeedr https://blog.superfeedr.com/google-feeds-api-welcome/

That theory is nonsense. This API is a tiny thing compared to YouTube and Android app store, two services that provide publishing opportunities to millions.

Publishing on third-party platform, with content limited to what those platforms allow, with monetization limited to what those platforms allow, with constant exposure to random nonsense DMCA takedowns.

But I guess the primary culprits of limiting people's ability to be publishers are NATs.

Even crappy home routers can port-fwd, the real barrier here is the ubiquitous (in America at least) prohibition on "hosting a server" on a residential internet connection.

You think everyone serving their own services from their residential networks is the solution? Have you thought through the security implications of that?

I can just imagine the technical support hours I'd have to log when my dad calls me up because his email server is down or his home storage is encrypted by ransomware.

Of course I have, that's why I run pfSense, a separate host for my DMZ, a reverse proxy, an IPS, and don't have DNS pointing to it (marginal benefit, but I don't need it so it's off).

I'm not arguing that people should do this, I'm arguing that the "NAT is a barrier" position espoused by the "evil ISPs are trying to keep us down, man" camp is incorrect.

NAT being necessary because of IPv4 has lead to this really useful low barrier to self-hosting. People who grok security and want to do it can, but it's just arcane enough that lots of people who shouldn't self-host are scared off and go to AWS.

How does that work with WebRTC, e.g. as used in messaging apps?

You've lost me, what's the connection between "people's ability to be publishers" and WebRTC messaging apps?

If you want to publish a WebRTC service, port forwarding will work fine and then you'll be bitten by the no servers restriction.

A messaging app doesn't have to require port forwarding, it can use a central server to broker the connection between endpoints. In that scenario, the "server" is on the internet, not the residential connection, but data comes from the endpoints.

I would only use a Google, Microsoft, _whoever_ API if I was paid for integrating and maintaining it. I would never rely on such a thing in a personal project/venture. Time and again paid and free web services are getting shut down without a replacement. The reputation is already such that nobody can trust a service to be there in 2 years. Another reason to build more decentralized solutions while we can. I was delighted to read that Berners-Lee and Cerf advocated just that recently.

Google actually deprecated this over four years..

I know, but not all software is written and maintained such that this is enough to adapt. Whether that's good or bad is a different question.

Four years? Any software that assumes that a networked third party service will be up (any unchanged) for years later is ridiculous, and it's development is bad.

Is it bad? Yes. Does this happen? Also yes. Maybe you're assuming that there isn't software which gets written and installed but only touched sporadically. Web services will be integrated in some web site and forgotten about. Sometime after the service is shut down some user of the site might notice. It's not the case that all users of a web API are developers like the HN crowd and in the loop of things. To be clear, I'm not saying people should expect different support times, just that one shouldn't rely on a third party when it's all over the network and you have no local copy of the code to potentially operate for longer than officially supported.

> one shouldn't rely on a third party when it's all over the network and you have no local copy of the code to potentially operate for longer than officially supported

Agreed.

You mean like Parse was paid for ? It's not necessarily a silver bullet.

Relying on third parties is never safe. I think these services are great for fast prototyping, but eventually you should move on to build your own stuff.

I agree. We need a shift away from the whole SaaS idea. It plays nicely with ultra-short-term market thinking, so people buy into that, but it is bad long-term. Any service you use is giving away control to a third party. It's true in life as well. Some services are easily replaceable - if the barber shop next to you closes down, there's always another few streets away. But some services are not so easily replaceable, and it's the case of most of them on-line due to the very bad state of software-software integration (i.e. having people to write complicated translation layers). If you depend on such services for your business and they decide to shut down, you're screwed.

If we want to move computing forward, we need more products and less services. More software that one can download and host themselves.

SaaS is not bad at all, but when it's misused.

Current example is ticketing. Two of my clients need a solution to manage ticketing and subscribers. They went with Eventbrite, even tough it's a bit expensive. It saves them tons of time and money. Sometimes it makes little sense to develop such a system for somebody if they have 2 events / year.

Often, third parties are much better in quality, than an in-house dev could create. I would only pick a third party service if it has many competitors, so easily disposable.

I've been screwed by this before, I built on an API before and the legal team shut down my API key for bullshit reason. 1 year of devtime went down the drain :) Long story short, SaaS is bad for mission critical features, otherwise great helpers on the short / mid run.

The distinction of core/critical and non-critical aspects of your business is a good one. I'm not saying "don't use SaaS at all" (even though I dislike the world of short-lived, data-siphoning services we've created). But betting the life of your business on a third-party service makes sense only if the expected life of your business is shorter than the expected life of the service you want to use. And I think we could all use more longer-living solutions.

To quote Joel Spolsky "If it's a core business function -- do it yourself, no matter what"

http://www.joelonsoftware.com/articles/fog0000000007.html

For lots of businesses the choice isn't between SAAS and download+install, but SAAS and not having an app at all.

It's a real cost+risk to maintain, update, secure, backup and troubleshoot an application internally and in most bottom line terms is less expensive as a SAAS than an internal application.

Yeah, but the end result is a string of services depending on services depending on services, and a very fast-moving ecosystem of fragile, throw-away solutions.

Sure, it makes some people some money, and there's a perfectly rational short-term market reasoning to do your product this way, but is this the world we want to live in? I think this is one of those cases where to make real progress, you have to go against the gradient of economic considerations.

I guess it depends? Consider, for example, payment processing - super hard to do properly by yourself.

Which is why this is only done by large companies with lot of funds, e.g. Paypal, Stripe, etc. The chances of them going titsup are low. If they do, you switch to another one.

A special case is a special case. Payment processor going "titsup" would be a literal disruption of market; if they'd all close down, I'd be worrying about getting more shotgun ammo to protect my canned food.

But besides that thing that's to a living company like a heart to a living body, I think we could do with using less services and more products just fine.

I wrote "paid and free web services", so Parse would be a similar risk. To force someone to operate a paid service as long as you want it, you either need a really good contract or laws, but that's not a generally applicable solution. The better solution is to lessen reliance on services like that and prefer stuff we can run independently.

I think he meant unless he was being paid by someone else. As in, he would avoid a google API unless some sort of client or employer was paying him to use it.

Google need to learn that providing a free service and then retracting it is quite damaging to their reputation. I know many developers who are incredibly reluctant to build on Google APIs because the danger of them being shut down feels high.

However, interest and use of the API has waned over time, and it is running on API infrastructure that is now two generations old at Google.

I wonder if there's a correlation between the downturn in interest in RSS and Google Reader being closed.

The correlation is backward. RSS usage had flatlined as Twitter/Facebook took over the use cases of RSS for most people; with RSS in decline, Reader was killed... and now, years later, so is this Feed API.

Yes, you like RSS. So do I. But most people never used it. Feedly has 15 million users, and they estimated that they captured 85% of Google Reader's user base when it shut down. Twitter is 20x larger. Facebook is 100x larger.

> I wonder if there's a correlation between the downturn in interest in RSS and Google Reader being closed.

Google Reader was a great app, I didn't believe Google one second when they basically said that nobody used it anymore.

RSS is still the best way for me, personally, to get my news from the internet on a whole range of subjects. I don't like Twitter or Facebook which are mostly noise and spam. With RSS I get my news right from the source, without a third party.

I also use RSS in APIs I write for pub-sub endpoints.

Google could have integrated RSS in Gmail for instance,the same way they integrated a chat inside the email client. They didn't because they don't believe in open tech that much anymore. It's all about messaging apps with proprietary protocols these days. Yet RSS is part of the web.

Reader user base wasn't really growing (in terms that Google is used to).

But more importantly, the technology was creaking, and nobody at Google wanted to maintain it.

(Disclaimer: I ended up working for the team that shut down Reader.)

Amen to the RSS love. It's either that or write a spider that scrapes the websites you want to follow, looking for changes.

> Google need to learn that providing a free service and then retracting it is quite damaging to their reputation.

Let's say someone invites you to a party for free, and offers chips and snacks. If, eventually, the snacks run out and the bowl is empty, should you be justified in being mad at them? You got free snacks, after all. You just didn't get an infinite supply of them.

> I know many developers who are incredibly reluctant to build on Google APIs because the danger of them being shut down feels high.

If you get invited to a party with free chips and snacks, and the host even says it's fine for you to take those snacks and sell them to other people, it seems the height of entitlement to me to get mad when the bowl runs out eventually.

Sure, you might have to figure out how to adapt your business to a new post-free-snacks world, but you still got several years of free chips that you could then use in your own business before then.

I'm having a hard time understanding how this makes Google look at all bad.

3 years to figure out another option isn't enough time for your developer friends? It's not like they're just pulling the rug out from anyone without warning. They require a promise that the free service will be maintained for them forever?

Seriously.

This isn't Google shutting down something out of the blue, this is them shutting down the service 4 years after they announced it would be shut down in 3 years...

Does everyone here really expect every company to keep every service running indefinitely?

Does everyone here really expect every company to keep every service running indefinitely?

No, but if a company wants developers to build things on top of those services (or any other service they offer) then they need to make sure it doesn't feel like they might close down a service on a whim.

Take Facebook as a counter-example. Their APIs change with irritating frequency, but I've never heard of them shutting anything down. That's not to say they don't, but I'm not of the opinion that there's any danger to my business in building services that reply on Facebook's infrastructure. I can't the same of Google. I know Google shut things down, so I avoid building on Google APIs.

To Google's credit the way that they sunset services is very good.

Well, they did shut down Parse. And that was even a paid offering.

> However, interest and use of the API has waned over time, and it is running on API infrastructure that is now two generations old at Google.

That's funny. This is software, not nuclear reactor maintenance. It costs very little to let old software run, especially in case of a Google-sized company. If beancounters complain, then budget it as a marketing expense!

> It costs very little to let old software run, especially in case of a Google-sized company.

The cost model is actually the reverse of what you may think. Because of security concerns, every existing service is a vector for attack waiting to happen; under-maintained services doubly so, as they won't have the passive eyes-on that minimize the chances of something slipping through the cracks.

At a company the size of Google, it's not just the passive cost of maintaining the API; it's the active cost of maintaining the API, maintaining the servers its implementation is running on, and doing the security concern analysis to make sure someone can't use the feeds API to crack into a user's GMail account, multiplied across all services Google runs, etc.

Little to keep the API running indefinitely, but not the infrastructure.

I meant both, actually. Keeping the API running == keeping its infrastructure running. And I can't imagine this costs them very much.

You imagine wrong, it takes teams of people to keep running the infrastructure that Google is built on. And keeping running infrastructure that's multiple generations old is wasteful.

What you should be arguing is that it's worth it for Google to port the API to current infrastructure. But porting it is not as simple as saying "Leave it up!"

As I pointed out last time, RSS for real news is doing fine. RSS for social crap is dead.

Space News has an RSS feed.[2] The Senate Democrats have an RSS feed covering what's happening on the Senate floor.[3] (The GOP discontinued their feed.[4]) The House Energy and Commerce Committee has a feed with markup in embedded JSON.[5] Not sure what's going on there. Even The Hollywood Reporter has an RSS feed.[6]

So for real news, RSS is in good shape. RSS seems to be doing fine for sources that have something important to say.

[1] http://feeds.reuters.com/reuters/topNews [2] http://spacenews.com/feed/ [3] https://democrats.senate.gov/feed/ [4] http://www.gop.gov/static/index.php [5] https://energycommerce.house.gov/rss.xml?GroupTypeID=1 [6] http://feeds.feedburner.com/thr/news

Does anyone have a good replacement for this? I somehow missed the original announcement and am now realizing that I'm one of those (apparently few) people who actually does use the API.

See my comment above [1]. Also view a list of alternatives here [2 - 4].

[1] https://news.ycombinator.com/item?id=12016815

[2] http://www.makeuseof.com/tag/12-best-yahoo-pipes-alternative...

[3] https://news.ycombinator.com/item?id=9662035

[4] https://news.ycombinator.com/item?id=9667004

Google is throwing new API's without commitment and trying to find if one of them becomes popular. This is good way to limit the risk.

Developers wait to see if Google commits to API before fully adopting it. This is good way to limit the risk.

Don't you end up with a catch 22 where developers won't write apps against an API because it may disappear, and Google gets rid of an API because nobody is writing apps against it?

I'm pretty sure that is the point nabla9 is making.

Is there any alternative API ? This one was quite handy for RSS feed discovery.

See my comment above [1]. Also view a list of alternatives here [2 - 4].

[1] https://news.ycombinator.com/item?id=12016815

[2] http://www.makeuseof.com/tag/12-best-yahoo-pipes-alternative...

[3] https://news.ycombinator.com/item?id=9662035

[4] https://news.ycombinator.com/item?id=9667004

I'm confused about the use case of the Google Feed API.

It let's you download a feed by Javascript. But why is this a web service?

Is there no Javascript framework that does the same without having to roundtrip to an external service?

They also stored longer history for feeds than what you get by fetching it yourself.

https://developers.google.com/feed/v1/reference#includeHisto...

No, because JavaScript is not allowed to contact multiple hosts other than the one where the page was downloaded from or Cross-origin resource sharing is enabled.

Google really hates RSS, don't they?

They seem to be actively killing anything that they have that once supported it

I know, I'm just waiting for the day they announce the shutdown of FeedBurner. That's going to create a LOT of broken feeds if they do...

Here's a theory: Google kills Reader. Not because they hate RSS, but because they want to drive people to Google+ or some other unrelated reason. Web at large understands this move as a sign that Google doesn't see a future for RSS feeds. Old websites start pushing alternative things (used to be Twitter, Facebook, now newsletters and mailing lists). New websites launch without feeds. Google sees lack of interest in the rest of its services connected to RSS feeds and starts shutting them down as well.

They need to make a Google Shuts Down ___ API. Every time you call it, something else gets shut down.

I think we need to make a SV Drinking Game.

You drink one whenever Google shuts down an API or a service.

You drink one whenever someone says we're in a bubble.

You drink one whenever Techcrunch writes another X is Uber/AirBnB for Y article.

You drink two whenever we get another unicorn.

etc.

Not too late to consider a switch to Superfeedr https://blog.superfeedr.com/google-feeds-api-welcome/

Google, making the web less transparent one day at a time. And meanwhile they complain Facebook is eating the open web, while they're dismantling it themselves

Embrace, Extend, Extinguish? I.e. we wouldn't care about Google shutting down another useful product if we weren't allowing ourselves to be dependent on it in the first place.

Reply on news.ycombinator.com