As you probably have seen, yesterday saw the public unveiling of the new Office 2013 and SharePoint 2013 products and online services.  The SharePointsphere has gone nuts and everyone is blogging and tweeting as they find stuff out about the products.  Very exciting stuff!  Some people like Andrew Connell are doing a fine job of articulating some of the new stuff for developers and designers like the new App model and the new WCM capabilities.  There really is so much new stuff for us developers out there that I think it will take a good few months for it all to really sink in.

There is one part of all this that I am personally pretty excited about.  You may jump to the conclusion that its Apps … it’s not … you might think it’s the Marketplace … it’s not …

What am I excited about?

Plumbing.

That’s right … I’m excited about plumbing … why? Well …

To enable these new capabilities like Apps and the Marketplace there has been A LOT of work done in the platform that makes up SharePoint.  Features like OAuth for integrating with APIs, new Client Side Object Model capabilities & Remote Event receivers.  Plus loads more.

These things all culminate in features like Apps … but also play a significant part on their own.  These are the platform building blocks that we as developers need to unlock a whole new slew of scenarios.

Take for example this simple scenario:
Programmatically uploading files from on prem to Office 365. 

You might want to do this for a multitude of reasons.  Possibly as part of a workflow that runs on prem that pushes documents out to partner sites you host in Office 365 for example.

Today this is possible in Office 365, but requires a bunch of extra work around authentication (like Headless Authentication)

With the addition of OAuth for in Office 365 you will be able to simply deploy an App to the 365 site that gives your code running on prem or in Azure the ability to seamlessly “log in” and use APIs like the Client Side Object Model without all the auth “goo” (see how politely I said that) you need today.

Or take for example the opposite scenario:
Programmatically pulling files down from Office 365 when they are uploaded

Today when someone/something uploads a file into Office 365 you don’t currently have a way to catch that “event” and push the document out externally to another system.  You can have event receivers, but code in the Sandbox cant talk to anything external.  So what do people do today?  They “poll”.  They have some code that sits and spins every minute or so looking for new documents … then they “pull” it when one arrives.  This is not a great solution for a variety of reasons, but its pretty much all they can do.  In 2013 you have the ability to have Remote Event recievers where SharePoint will call your remote end point when an event fires so you can respond.  No more polling required 🙂

Or take the scenario I demoed in the keynote at SharePoint Conference 2011:
Pushing content into SharePoint Online from an Azure based web application.

In that scenario we had the NetHope voting application we had developed and hosted in Azure pushing vote data into NetHope’s Office 365 based intranet.  We needed to use Headless Auth to do that.

The list goes on and on and on…

Just like how OAuth opens up authentication scenarios the Client Side Object Model (CSOM) and REST APIs open up programmatically callable functionality remotely.

In SP 2010 the CSOM only really covered Foundation data APIs for getting at things like List Data in sites. In 2013 that has been widely expanded to things like Search, Profiles & Taxonomy (personal favorite of mine).  This makes working with SP remotely so much easier than having to cobble together calls using a combination of CSOM, Web Services, FPRPC & REST.  So so much easier.  If you are building code that isnt .Net or JS then you can call the Client.svc service with REST/OData to call the endpoints manually.

Between OAuth, Remote Event Receivers and the expanded CSOM developers are unlocked to build a plethora of solutions that are either hard to do today … or impossible today.

That’s why I am personally excited about the plumbing.

Being able to build your solutions and monetize them through Apps and the Marketplace is extremely cool too … but I’ll save up another post for how I think people should be approaching how to decide what “style” off App to build (like Provider Hosted vs. SharePoint hosted vs. Auto Hosted).  Lots to think about and consider before jumping in there.

In the mean time take a look at some of the great SharePoint developer training videos available here:  http://msdn.microsoft.com/en-us/office/apps/fp123626

Thanks,

-Chris.

Update: changed the title … i like this one better