Reliable way to send an http request from device

[mhelvens]

From my watch app I would like to send an http request and receive the response. It would need to basically work like `fetch`, but with some sensible and predictable failure modes regarding device-companion communication.

What is the recommended way to do this?

My current understanding

Since only the companion can send http requests directly, my understanding is that I need to do something like this:

• The watch encodes an http request, sends it to the companion via Messaging and waits for a return message;
  • The companion receives the message and decodes it to an http request; 
  • The companion sends the http request;
  • The companion receives the http response;
  • The companion encodes that response and sends it to the watch via Messaging;
• The watch receives the message and decodes it to the http response

And I'm not yet sure I've cracked it, because Messaging is peer-to-peer, and I would have to come up with a protocol on top of that to allow client-server type communication. This introduces a whole new set of complications, like matching requests to their corresponding responses, and handling communication failures.

I've implemented a crude version of this, but I'm pretty sure it would fail under less than ideal circumstances (like the watch being too far away from the phone).

Conclusion

This seems like a lot of work for a seemingly simple operation. Am I missing something obvious? Or has this work already been done by someone, available for reuse?

Thanks!

[JonFitbit]

There are a number of complications with messaging. Devices being out of range is definitely one issue, but the companion can also go to sleep, or the Fitbit mobile app might be terminated.

In most cases, sending a message from the device should be enough to wake the companion or mobile app, but you would need to add your own validation.

The only similar thing I've seen was a device fetch() implementation by Remy Sharp. https://gist.github.com/remy/2f5dbe7032004a5dd09bd57733d30ab6

This was before the device had support for promises, so you can probably simplify it.

[mhelvens]

That's pretty close to my own implementation. Unfortunately, neither can gracefully handle failure yet. I don't see a way to know whether a sent message was received by the other side, except by expecting a response to come back within a certain amount of time. I guess that might be the only way, though it would complicate the code.

This reminds me, this ecosystem could use a more streamlined way to share and bundle packages. It might be a good idea to start supporting npm at some point, and the package.json `engines` field. Anything like that on the roadmap?

If I write a module for this, I'll probably publish it to npm. But I don't expect many FitBit app developers are looking there yet.

[JonFitbit]

There are some open source libraries listed in our Github repo but proper modules would be great. Perhaps when the CLI tools arrive, we'll be in a better place to support that.

[mhelvens]

Sure. In fact, once the CLI tools arrive, I expect we won't require further explicit support from FitBit to get proper modules. I intend to transpile, bundle and minify the code locally, and effectively end up with two javascript files. One for the device and one for the companion, with npm modules inlined. (Let me know if I'm making any unwarranted assumptions about the CLI tools.)