LabVIEW Web Development Documents

Showing results for 
Search instead for 
Did you mean: 

NIWeek 2016: Develop Distributed Systems of the Future Using the Cloud Session Demo


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:, 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.

NIWeek 2016 Demo Data Flow.png


We start with 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 ' REST API' landed me at the following page:


At time of writing, the only configuration required is a 'thing' name which is globally unique across the 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 API documentation:


  • URL for our request:{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




Security points to keep in mind for

"By default, dweets are public. You can make dweets private by purchasing a lock for your thing." -   src:



Rate limits to keep in mind for

"A dweet payload can be up to 2,000 characters." - source: 

"You can dweet up to once per second" - source:



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:


Information we extract from the docs to create a request to PubNub in LabVIEW:

  • URL for our request: /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:

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:



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:


We can see the URL is composed of several parts which are described as follows:

  • '': The host path for our database. Databases get subdomains of the format
  • '/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:


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:


Don't suppose your figured out how to authenticate from LabVIEW??

Active Participant
Active Participant

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.





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?