Data transfer to web app, api or not api

Id like some clarification of my understanding about data transfer and the particle api.
When sending or receiving data, we have web hooks which I believe ALWAYS goes through the particle api and is subject to bandwidth limiting.
There is also an example of a Serial to IP convertor (serial uart over the internet) which uses TCP client and server objects.

Does the data transfer using these objects also go through the particle api or is the photon then communicating DIRECT to the remote application or service?

Notably, I can communicate to the photon locally using its local ip address given by my router, using putty for example. But to connect to it remotely at a distance, we need it’s real internet address, which we can get from say dyndns. Hopefully avoiding particle api and bandwidth issues.?

Hi @rowifi

I think what you wrote above is basically correct. You will have to point out exactly which Serial to IP convertor you are talking about, but Particle devices are certainly capable of non-cloud, direct TCP and UDP connections.

The Particle cloud is:

  • Easy to use
  • Able to bridge services that use https (TLS/SSL) connections via Web Hooks
  • Web hooks also allow for parsing for data reduction and formatting, preserving your device RAM
  • Uses an outward bound connection from device to cloud, so you home router or firewall does not have to have any extra open ports: the COaP port is open by default on most routers
  • Is intentionally rate limited on publishing, but not on variables or functions. Web hooks have special rules too to avoid slamming someone else’s host on the net

If you roll your own communications using TCP or UDP on the device:

  • You have more complete control
  • You don’t have any rate limits other than your bandwidth and the device’s speed
  • You will have to figure out your own scheme for dynamic DNS and firewall/router configuration
  • You have to supply your own bridge to do https (TLS/SSL) or use the newly created https library
  • You have to have a working knowledge of networking protocols to communicate effectively.

Both options are good and there are times when you want to use both at the same time even.

Great, thanks for clarifying that.