140 likes | 480 Views
Transitioning Full Trust Code to Client APIs. Architecting SharePoint For The Future Chris Domino December 10, 2015. hi. Chris Domino chris@chrisdomino.com (not so social on the media) Rightpoint SharePoint Architect / Developer / Everything Author Blog: http://chrisdomino.com/blog
E N D
Transitioning Full Trust Code to Client APIs Architecting SharePoint For The Future Chris Domino December 10, 2015
hi Chris Domino chris@chrisdomino.com (not so social on the media) • Rightpoint SharePoint Architect / Developer / Everything • Author • Blog: http://chrisdomino.com/blog • Book: http://www.amazon.com/Deployment-Driven-Design-Chris-Domino-ebook/dp/B00C4V482E
Transitioning full trust code to client apis Microsoft has ushered in a paradigm shift for SharePoint developers. Emerging best practices call for us to start moving away from deploying server code to the farm. Custom solutions should start leveraging the Client APIs. …but…but why?
A brief history of sharepointapis Each new version of SharePoint has added more capabilities to our customization arsenals.
So what’s wrong with server code? • Technically speaking…nothing… • Very powerful • I could do anything • Tooling keeps improving • But… • Too powerful? • Deployments are too impactful • Not future-proof
The paradigm shift • Server code… • Is architecturally monolithic • Does not scale • Requires heavy dev environments • Client code… • Is layered • Scales like a champ • Lightweight and efficient It’s time to start thinking about SharePoint as a modern web platform.
Meet the client apis These are the wireless drills of SharePoint development. • Site collection scoped • Feature parity
The app model (Provided hosted) Provider hosted apps demonstrate the power of CSOM and are great for distributing autonomous functionality across farms. But… • Difficult to configure • Forces our hand a bit architecturally • Introduces an extra layer of security • Uses IFRAMES
Rethinking SharePoint architectures With an understanding of the paradigm shift and client APIs, let’s look at how we can start transitioning our full trust code. Server-based with some client functionality. Client-based with some server functionality. SharePoint as a platform.
1. Server-based architecture This is a largely out-of-the-box SharePoint deployment with very few customizations. Content Query web parts become Content Search web parts. JSOM can be used for light-weight custom functionality. Install third party apps for advanced functionality.
2. Client-based architecture This is a largely custom SharePoint solution that is still on premise. Pages are still served out of SharePoint. All custom code is converted to CSOM and potentially moved off-farm. Blend of WSPs, features, branding, JSOM, REST, etc.
3. Sharepoint as a platform In this architecture, SharePoint acts as a database / asset repository. End users never visit SharePoint. All UI is hosted externally (like a provider-hosted app). No code is deployed to the farm. Search, security, document libraries, image renditions, and any other services can be leveraged.
What should stay the same The Client APIs can’t actually do everything… • Subset of the Server APIs • Beyond site collections… • Web Applications • Service Applications • Cross-site collection functionality • Non code based customizations • Custom Actions • Application Pages