When building our new website there was a requirement to display the latest articles from our BrightStarr SharePoint LinkedIn group. We also wanted to display the articles on our intranet and an internal native mobile application.
LinkedIn provides an API that you can integrate to pull off filtered and ordered posts, so integration wasn't a worry. It uses OAuth and again, building this into a SharePoint component wasn't an issue. What bothered me was that we were going to reuse this at least three times. There was also a caching requirement and our website receives more hits than the daily threshold permitted by the LinkedIn API.
My thoughts naturally went towards a common app where I could cache once and then feed the three individual implementations. The more I thought about this, the more it made sense. I effectively set up a proxy to the LinkedIn API. My proxy caches the latest posts for say, a couple of hours, and my intranet webpart, website server control and native app can all consume from that service. It also meant that configuration was in a single place.
I then had to consider hosting. Where would I put this app? BrightStarr have a robust and redundant website hosting environment, but I felt I was being biased towards the website. I needed somewhere more central and at least as reliable. Where better than Microsoft Windows Azure; scalable, redundant and simple to deploy to. From there the build was simple:
- From there the build was simple:
- Proxy service: RESTful service deployed to Azure, used OAuth to connect to LinkedIn RESTful service.
- Website server control: simple control that consumes XML from the proxy service, transforms it and renders it to the page.
- Intranet webpart: inherits from the same component as the website server control, just renders it as a webpart.
- Native app: again, consume web service and perform simple transformation.