Using Node.js as an access point for mobile application API

I'm not sure if I've quite grokked node.js yet, but I really want to implement it, cause what I do understand is pretty friggen sweet.

I've got a mobile application that uses an API from a third party. Users typically open it up to see if anything is new. It occurred to me that so long as I respect the third party API's polling limits (and other restrictions) I could simulate a push based system and allow the user to be notified once something is new.

Basically implement all the API polling from a Node.js server on some sort of interval, and make the mobile app point to my Node.js server instead of the end point API.

I figure that this will be good for a number of reasons:

• Takes load off the phone's data usage (since I can cache things on both the phone and the server). This is a huge win for users who have a pay-per-byte data plan
• Allows a central location for storing / accessing all the data
• Lets me do some optimization on the server side (if two users happen to subscribe to the same feed I can get that in one request.

I figure this could be bad for a number of reasons:

• If my server goes down, then all my apps die. By acting as a go-between my Node.js implementation may very well introduce a higher number of fail points.
• When the third party releases additions to the API, it requires me to implement the changes in two places, instead of one.

My question is this: In general, is this good practice? If not, why?