During the Develop Distributed Systems of the Future Using the Cloud session at NIWeek 2016 we walked through a demo that utilized different third party cloud services from a LabVIEW application. The goal of the demonstration was to show that many different cloud services are available that can implement useful utilities for us. We also discussed how many of these cloud services expose RESTful HTTP APIs that are consumable in LabVIEW.
A nice feature of the presented VIs is their ability to run on three very different platforms, a Windows Desktop, a Linux RT myRIO target, and a Raspberry Pi 3. Due to utilization of the cross-platform LabVIEW HTTP Client palette, we created VIs for communicating with LabVIEW cloud services that are portable in a manner similar to LabVIEW Instrument Drivers.
This document will walk through example steps for creating LabVIEW VIs that consume three different cloud services: dweet.io, PubNub, and Firebase. All of these services are used to provide a similar type of utility to our application which in this case is the ability to post quick and small status messages.
We start with dweet.io because the API is transparent and the service has an online playground to experiment with. You don't even need to register an account to get started!
The first thing to do is search for the developer API documentation for the RESTful HTTP API. A search for 'dweet.io REST API' landed me at the following page: https://dweet.io/play/
At time of writing, the only configuration dweet.io required is a 'thing' name which is globally unique across the dweet.io service. You get to come up with any unique name you can think of and publish data to the name as shown in the following animation:
The animation shows the formation of an HTTP request using the online playground as well as an example response. To create this same HTTP request in LabVIEW we extract the following information from the dweet.io API documentation:
With that information we can construct the following VI to post a message to dweet.io:
"By default, dweets are public. You can make dweets private by purchasing a lock for your thing." - src: https://dweet.io/faq
"A dweet payload can be up to 2,000 characters." - source: https://dweet.io/faq
"You can dweet up to once per second" - source: http://buglabs.tumblr.com/post/138921809271/introducing-easy-data-storage-and-querying-for
Similar to the previous example we discover the PubNub developer API documentation by doing a search for 'PubNub REST API' which has us land at the following page: https://www.pubnub.com/http-rest-push-api/
Information we extract from the docs to create a request to PubNub in LabVIEW:
Unfortunately at time of writing the documentation is a little sparse but we are able to work through it with some trial and error. One interesting thing we notice is that the entire request is encoded in the url. The parameters in the url are broken down as follows:
Our VI using this information to publish data to PubNub looks like the following:
It doesn't look like we have any default public publishing going on and all requests need the pub / sub keys. We need to remember to keep these keys private but otherwise I don't see any immediate problems.
"The maximum number of characters per message is 32KB" but take note of the additional comments in the source: https://www.pubnub.com/knowledge-base/discussion/481/what-is-the-maximum-message-size
I didn't find a good source with specific message transmission periods confirmed directly by PubNub, but the following suggests our example is on the conservative side: http://stackoverflow.com/questions/25416918/throttle-pubnub-publish-message
Firebase is a fairly generic database whereas the services we have seen so far have targeted the specific application of receiving messages from devices. While we don't see the effects of this immediately in the API, we should notice that the tooling, visualizations, and analytics provided by each of these services are very different. The ease of use of the tooling and alignment with how you utilize the service are some factors to keep in mind when selecting services.
By now we probably see a pattern emerging for creating VIs to interface with RESTful HTTP cloud services. We go ahead and search for the 'Firebase REST API' and after a bit of navigation we end up at the following page: https://firebase.google.com/docs/reference/rest/database/
We can see the URL is composed of several parts which are described as follows:
Now by default Firebase requires authentication to push data in our database. Firebase authentication is very flexible and makes strong security claims, but as a side-effect there is extra complexity to get it right in the service configuration and LabVIEW VI client. In the demo we disabled authentication for simplicity but that would be highly discouraged for anything beyond experimentation.
To disable authentication for this experiment see the Sample Rules documentation for enabling Public access: https://firebase.google.com/docs/database/security/quickstart#sample-rules
After you create a Firebase database and configure it for Public access, the VI for publishing data looks like the following:
Do not use the Public access rules in any application beyond simple experimentation. Implementing robust security for Firebase may require additional expertise depending on the needs of the application.
No idea. All the documentation on the Firebase describes connections which are long running and streaming. RESTful HTTP requests are short lived and polling so I am not sure how they are counted. There are older discussions as follows saying the REST API has no limit but I'm skeptical of how that applies currently: https://news.ycombinator.com/item?id=8422942
Don't suppose your figured out how to authenticate from LabVIEW??
Hi saphi,
Which service are you trying to authenticate with from LabVIEW?
If you are trying to use Firebase it should be possible to use the Firebase ID Tokens. The difficulty with Firebase ID Tokens is that they expire and creating them takes some effort and other tooling. The alternative is using Google OAuth2 access tokens for authentication which will be require more work as you need to implement JSON Web Token capabilities in LabVIEW.
If your primary goal is using Firebase, unfortunately I'm not aware of any LabVIEW toolkits that make integrating with Firebase much easier right now.
Hi,
I'm very interested too in doing the authentication with Firebase from LabView (i.e. getting a valid ID token from Firebase in a VI).
Does anyone know how to accomplish this?