From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW Web Development Documents
Overview
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.
dweet.io
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:
- URL for our request: https://dweet.io/dweet/for/{thing}
- Method for the request: POST
- Header(s) needed for the request: Content-Type with value application/json
- Body with the data is encoded as a JSON string
With that information we can construct the following VI to post a message to dweet.io:
Security points to keep in mind for dweet.io
"By default, dweets are public. You can make dweets private by purchasing a lock for your thing." - src: https://dweet.io/faq
Rate limits to keep in mind for dweet.io
"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
PubNub
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:
- URL for our request: http://pubsub.pubnub.com /publish /pub-key /sub-key /signature /channel /callback /message
- Method for the request: GET
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:
- publish: The action being done, this will be unchanged for our VI
- pub-key: By registering with PubNub, creating a new app, and creating a keyset we can find the Publish Key
- sub-key: Similar to the pub-key, by registering, creating a new app, and creating a keyset we get the Subscribe Key
- signature: This appears to be optional for this rest API endpoint as leaving the value at 0 seems to work. Not sure if that applies to all the other actions for the REST API but if anyone finds more information please mention it in the comments.
- channel: It looks like each keyset can have multiple channels of data and you can enter in a string for the channel name.
- message: The actual message data string. We will publish this as JSON data.
Our VI using this information to publish data to PubNub looks like the following:
Security points to keep in mind for PubNub:
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.
Rate limits to keep in mind for PubNub:
"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
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/
- URL for our request: https://samplechat.firebaseio-demo.com/users/jack/name.json
- Method for our request: PUT
We can see the URL is composed of several parts which are described as follows:
- 'samplechat.firebaseio-demo.com': The host path for our database. Databases get subdomains of the format mydatabase.firebaseio.com
- '/users/jack/name': The path into a certain spot in the database we want to write to.
- '.json': The format of the data which seems to be used in favor of specifying the Content-Type as an additional Header
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:
Security points to keep in mind for Firebase:
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.
Rate limits to keep in mind for Firebase:
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
