Skip navigation

developer-icon-crop-png.png

When Aron Racho first had the idea for a Jive SDK using Node.js back in 2013, he did an exceptional job at building a solid platform for Jive developers to build add-on solutions.  It's been a while since the original Jive SDK (Node.js) has received any substantial love.  If you've used it anytime in the past 1.5 years, you've probably seen the growing list of deprecation warnings, even the SDK worked just fine.  So we thought it was time to change the perception of this awesome tool.  But this update wasn't just about a fresh coat of paint, we also wanted to apply some of the feedback we've gathered over the years to work to try and make things a better.

 

We hope you like the work we've put into improving the SDK, and hope it will help get many of your started on many of the Common Jive Add-On Use-Case Patterns we've identified for the Jive platform.

 

Thanks for being such awesome developers to work with, and happy coding!

If you have questions about the SDK, you can ask them below in the comments ... or here:

Questions about the Jive-SDK v0.2 Release

To install the SDK, check out this document
Getting Started > Installing the Jive Node SDK

or, if you already have npm installed

npm install -g jive-sdk

 

Updated Node v4.4.7 - 6.3.1 Support

In the previous version, we ran Node v0.10.32, which is a bit dated.  As part of this upgrade, we want to make sure that the SDK would work on modern Node.js production environments.  As such, we did some digging and re-worked some of the dependencies, and we are now functional (and tested) on Node v4.4.7, v6.0.0 and v6.3.1.  Support for versions in-between the is possible (and in some cases likely); however, we have not extended the testing beyond these two versions for the time being.  If you have feedback around supported environments or issues, please us know and we will do our best to address.

Note:  We are currently testing 6.3.x but have noticed a few issues ... stay tuned for updates.

Note:  The last version of the original Jive SDK v0.1.219 will only work on Node v0.10.32

 

Updated to Express x4.0

One of the biggest issues we faced in this upgrade were the massive changes between Express 3.x and 4.x.  Given that express is such a critical piece of the SDK, touching it meant affecting the entire SDK.  Thankfully, the differences weren't too crazy to map out and we are now running the latest version of Express and should be good to go!

 

Changed community.json ID ID Key

In previous versions of the Jive SDK, when a community registered with Jive, it stored the information in the db/community.json file (or equivalent persistence structure).  While we still do this, we have changed the key on the community entity from the jiveUrl to the tenantId to be more resilient.  We still offer the same methods to locate the community data, such as jive.community.findByJiveURL and jive.community.findByTenantID ...

 

However, if you are using either of the following snippets:

  • jive.community.findByID or jive.persistence.findById('community','xxxxx')
    Your results will be different see the table, below.

 

Old Result
New Result

"https://sandbox.jiveon.com" : {

   "jiveUrl" : "https://sandbox.jiveon.com",

   "tenantId" : "xxx-xxx-xxx-xxxx-xxx",

   ....

}

"xxx-xxx-xxx-xxxx-xxx" : {

   "jiveUrl" : "https://sandbox.jiveon.com",

   "tenantId" : "xxx-xxx-xxx-xxxx-xxx",

   ....

}

 

Simplified Jive App and Custom View Tile Boilerplates

For those of you that have seen the Introducing the Jive Developer App Reference "App" on the Developer Sandbox and have followed the tutorial Getting Started > Creating an App with the Jive Node SDK, you'll notice that the code it creates was a bit daunting.  While OpenSocial does a good job at abstracting integrations, it is a bit cumbersome to grok the first time out.  So we put some work into making a better re-usable abstraction JavaScript file to simplify developers access to the Apps and Custom Tile environments.  By no means are developers required to use these abstractions, but they are easy to get started and tweak as needed.

At a high-level, we've boiled down App and Custom View Tile development down to it's core.  The ability to know Who is the Viewer, Where is the View (and How is it being Viewed) and Any Data/Configuration which might be needed to render a solid embedded experience in Jive.  Now to get started, simply follow the pattern from the SDK and use the following JS methods ... and you should be good to go!

 

Apps (Simplified).js
Custom View Tiles (Simplified).js

var ACTION_IDS = [

  "example.app.content.document.action",

  "example.app.content.discussion.action

];

function onReady(env) { ... }

function onViewer(viewer) { ... }

function onView(context) { ... }

function onAction(context) { ... }

function onData(data) { ... }

 

See these files for the full source code:

function onReady(tileConfig,tileOptions,viewer,container) { ... }

function onConfig(tileConfig,tileOptions) { ... }

function onContainer(container) { ... }

function onViewer(viewer) { ... }

 

 

 

 

 

 

See these files for the full source code:

jive-sdk create app

Getting Started > Creating an App with the Jive Node SDK

jive-sdk create tile-app-external

Creating Custom View Tiles

 

Added Automatic Cache Busting Timestamps

This is pretty straight forward.  Whenever you do a build with the jive-sdk build add-on command, the SDK will timestamp every tile and the app.xml reference URL.  This should help developers working with instances that may cache harder than normal, and make it easier to iterate development between builds.

 

Old Tile Definition (Easily Cachable)
New Tile Definition (Cache Busted per Build)

{ ....

    "action": "http://localhost/test/action

    "id": "a289e089-c9eb-4fad-9842-89d1ac0d0356",

    "definitionDirName": "test",

    "config": "http://localhost/test/configure

    "unregister": "http://localhost/unregister",

    "register": "http://localhost/registration"

}

{ ....

    "action": "http://localhost/test/action?ts=1469731909988",

    "id": "a289e089-c9eb-4fad-9842-89d1ac0d0356",

    "definitionDirName": "test",

    "config": "http://localhost/test/configure?ts=1469731909988",

    "unregister": "http://localhost/unregister",

    "register": "http://localhost/registration"

}

 

 

Easier Explicit Service Route Definitions

If you've ever defined an explicit route using the SDK, such as here.  You'll notice that the exported object only supports a singular verb; however, now that object also supports an array of HTTP verbs to register multiple verbs to using a single reference.  The old way will still work as well.

 

Old
New

exports.myservice = {

   verb : "post",

   jiveLocked : true,

   path : '....',

   route: function (req,res) {

       ....

   }

}

exports.myservice = {

   verb : [ "post", "get", "put", "delete" ],

   jiveLocked : true,

   path : '....',

   route: function (req,res) {

       ....

   }

}

 

Added Default HTTP Method Override Support

The problem of having a platform only being able to use limited HTTP verbs (perhaps only GET/POST), but needing to invoke some of the newer ones (such as PATCH) is quite common.  As such, we've added in some standard support for known method-override headers coming from some of the following platforms.

 

  • X-HTTP-Method (Microsoft)
  • X-HTTP-Method-Override (Google)
  • X-Method-Override (IBM)

Note: If you'd like to submit additional method overrides headers to be included into the SDK, please contribute here.

I'm sure there are some more general improvements we've made, but this is a pretty good starting point.

Filter Blog

By date: By tag: