locked
Joe Binder's Build 2013 LightSwitch Talk: Unhappy with where Joe placed SharePoint on his "Happy Path" slide RRS feed

  • Question

  • The whole talk (video and PPTX) can be found here: http://channel9.msdn.com/Events/Build/2013/3-310

    First, Joe's talk is a great presentation - one of the most comprehensive, easy to follow LightSwitch talks and demos available.   But... :-)

    Slide 8 in the PPTX is Joe's Happy Path slide and I can't figure out why he placed SharePoint half-way between the App client and the Logic tier?

    One of the things I like best about LightSwitch is the elegance of it's overall architecture and it's selection of OData as a core protocol and its use of the latest HTML5/JQuery/etc technologies for the HTML client UI.

    But slide 8 messes this all up!  :-)  At best, shouldn't SharePoint to positioned in the Logic tier? ...or perhaps a better solution is to have SharePoint positioned as a box that spans the Logic and Data tier?

    Dropping SharePoint into a no-man's land between the App client and Logic tiers doesn't make sense, IMHO.  Perhaps I'll get a chance to redraw a Happy SharePoint Architect Path.

    @jbinder: Your thoughts?

    Michael Herman
    SharePoint Architect


    Xpert Search Agents for Microsoft web sites: http://www.parallelspace.net/MicrodeX



    Sunday, June 30, 2013 1:27 AM

Answers

  • Hi All,

    Thank you for taking the time to pass along the feedback--I very much appreciate it.  I agree that the slide in question could use some refinement :).  My intention for showing it was simply to assert that there are some scenarios in which the client is best-served by talking directly to SharePoint and scenarios in which the middle-tier should broker the communication between the client and SharePoint.  

    For example, if you're retrieving the contents of a document, user profile, etc that you intend to show only intend to show in the UI, it's generally going to be simpler, faster, and cheaper--from a bandwidth perspective--to have the client talk to SharePoint directly via the JavaScript object model or REST apis. If you're using SharePoint as a data source for app data (i.e., attached SP list) or writing save pipeline business logic then it's best to stick with the default pattern of having the middle-tier handle communication between the client and SharePoint.

    As concrete examples of this, the demo we showed in the keynote--and to a lesser extent in my session--used the middle-tier to authenticate against SharePoint, attach and communicate with the SP list, and retrieve the AD and SharePoint user info.  However, the document control(s) and user presence controls in the client talked directly to SharePoint because the middle-tier would not have provided any value in those situations and going through the middle-tier would have been pretty unnatural: we'd have to open up a bunch of new service endpoints just to enable the UI scenarios

    In general, the developer won't have to worry about this distinction because the LightSwitch runtime makes the choice by default.  But if you ever do want to consume additional service in SharePoint or Office 365, you have the option to have the client consume those services directly because--unlike in Preview 2--the client is now authenticated with SharePoint.  Any Office-specific controls we introduce will likely use this model; and any you write yourself will likely want to consider it also.  But if you're writing business logic that entails SharePoint or Office services, going through the middle tier is always the best choice.

    I hope this helps!

    Thanks.

    Joe

    Sunday, June 30, 2013 4:52 PM

All replies

  • Hi Michael,

    I agree, Joe's presentation was excellent.

    I think sharepoint has a first class citizen place in the  LightSwitch space and this can not be influenced by the place where it gets on a simple drawing.

    The provider-hosted model means, in the context of a LightSwitch app,  that sharepoint is used for auth, but that the app itself is living in his own azure service and own azure sql database. But, it can speak as well with "the sharepoint artefacts".  That's exactly what Joe's drawing depicts, I think.

    Obviously, the end user will not notice this, and that's great, for her, the app is just part of the sharepoint site she is using.  Obviously, drawing this standpoint would give another picture.


    paul van bladel

    Sunday, June 30, 2013 7:38 AM
  • The issue is how to position SharePoint in the diagram (targeting other architects) that visually depicts SharePoint as:

    1. Auth provider

    2. Data store

    3. OData/REST services provider

    4. UI/CSS provider for SharePoint apps

    5. Separate host provider web site for the SharePoint app

    Michael

    p.s. If anyone knows of a great diagram that already exists that does this, plse post a link here.


    Xpert Search Agents for Microsoft web sites: http://www.parallelspace.net/MicrodeX

    Sunday, June 30, 2013 2:14 PM
  • Hi All,

    Thank you for taking the time to pass along the feedback--I very much appreciate it.  I agree that the slide in question could use some refinement :).  My intention for showing it was simply to assert that there are some scenarios in which the client is best-served by talking directly to SharePoint and scenarios in which the middle-tier should broker the communication between the client and SharePoint.  

    For example, if you're retrieving the contents of a document, user profile, etc that you intend to show only intend to show in the UI, it's generally going to be simpler, faster, and cheaper--from a bandwidth perspective--to have the client talk to SharePoint directly via the JavaScript object model or REST apis. If you're using SharePoint as a data source for app data (i.e., attached SP list) or writing save pipeline business logic then it's best to stick with the default pattern of having the middle-tier handle communication between the client and SharePoint.

    As concrete examples of this, the demo we showed in the keynote--and to a lesser extent in my session--used the middle-tier to authenticate against SharePoint, attach and communicate with the SP list, and retrieve the AD and SharePoint user info.  However, the document control(s) and user presence controls in the client talked directly to SharePoint because the middle-tier would not have provided any value in those situations and going through the middle-tier would have been pretty unnatural: we'd have to open up a bunch of new service endpoints just to enable the UI scenarios

    In general, the developer won't have to worry about this distinction because the LightSwitch runtime makes the choice by default.  But if you ever do want to consume additional service in SharePoint or Office 365, you have the option to have the client consume those services directly because--unlike in Preview 2--the client is now authenticated with SharePoint.  Any Office-specific controls we introduce will likely use this model; and any you write yourself will likely want to consider it also.  But if you're writing business logic that entails SharePoint or Office services, going through the middle tier is always the best choice.

    I hope this helps!

    Thanks.

    Joe

    Sunday, June 30, 2013 4:52 PM