8 Replies Latest reply on Nov 4, 2015 6:58 PM by neilg

    PI Web API Architectural Question

    neilg

      Hi All,

       

      I am hoping to get some thoughts on which may be the better approach to take on the below for an ASP.Net website/application talking to PI Web API.

       

      Approach 1:

      We could have JavaScript code talking directly from a client's browser and rendering the page (graphs, dials, static tables, etc) based on the results returned from the PI Web API call. This is purely on the client side. To me this makes it a thick client as the business logic is all driven through JavaScript on the client side.

       

      Approach 2:

      The other approach is to follow the MVC pattern and have the Model (server side) make calls to the PI Web API and return a visual object of some sort to the View. to me this approach makes it a thin client as the business logic is done at the server side and the View/JavaScript is only doing the client side rendering.


      Note that the application has the potential to become complex over time.

       

      My Questions (to all experienced web developers/developers out there):

       

      1. Which do you think is a better approach to take? What are the reasons?

      2. Are there any potential issues that you see with taking approach 1 versus approach 2? Putting a thick client does not appeal to me architecturally, but I am after any additional insights you can provide?

       

      All suggestions and knowledge is greatly appreciated.

        • Re: PI Web API Architectural Question
          bshang

          Great question Neil. I think there are many factors that are involved but for me, the main factor is expected level of user activity client-side.

           

          For web applications that expect a lot of user interaction, I tend to favor Approach 1 and extent it to a single-page application (SPA) in addition to client-side API calls. Also, using a front-end framework like AngularJS is helpful. I find it improves responsiveness and it's easier to manipulate views via AngularJS when lots of user interaction is expected.

           

          For web sites primarily for displaying content, I find Approach 2 is easier. Since there is less requirement for interactivity once the page is rendered, it is easier to just have the web server request the data and serve a mostly static page.

           

          For PI Web API specifically, the server maintains a separate stateful cache for each user. If multi-user support/security is required, then the two approaches would have very different ways of handling this which is something to consider.

          4 of 4 people found this helpful
            • Re: PI Web API Architectural Question
              neilg

              Thank you for your insight Barry. Much appreciated.

               

              Regarding your statement "For web sites primarily for displaying content, I find Approach 2 is easier." - but you could still make it very interactive using JavaScript/jQuery etc. even with this approach right?

               

              Looking forward to other peoples thoughts as well.

                • Re: PI Web API Architectural Question
                  bshang

                  Yes, that's correct. You can use MVC+jQuery. In that case, the jQuery is making the API call, so it is a bit more like Approach 1. I guess there are at least 3 approaches then (full on SPA with AngularJS or another front-end framework, MVC+jQuery, and MVC/full server-side rendering). In the first two, the client still makes the API calls.

                   

                  From what I've seen, the industry is moving more towards thinking of browsers as thick clients, and there seems to be a new front-end JS framework every month (Angular, React, Ember, Meteor just name a few...). I think these tend to be consumer-oriented web apps with lots of user interactivity and it probably helps to keep the logic client-side. These web apps are also making API calls to many different API servers per page load, so it is unfeasible to have the server perform all of them.

                   

                  The SPA approach and MVC+jQuery is what I see the most out in the field (with more momentum towards SPA). The choice between the two seems to come down to level of user-interactivity. Server-side API calls are probably appropriate for hydrating an initial page (i.e. a REST call to document database from a web server on a news website), where it doesn't make sense to return a page with mostly empty content to the client.

                  2 of 2 people found this helpful
              • Re: PI Web API Architectural Question
                pthivierge

                Hello Neil,

                 

                This is an interesting discussion!

                 

                The web technologies, frameworks and techniques are evolving so fast these days that it can be very challenging to select technologies to start with.

                And I believe there are some basic blocks you can work with without too much risks ( Asp.Net MVC + Razor Views, jQuery, JavaScript, html) to create an hybrid application.

                And this is not limited to only this, you can always add some JavaScript frameworks on top of that. 

                 

                In addition to what has already been said there could be other factors that would motivate my choice of a Web Project:

                • The current level of technology knowledge you have and the ease you have with those technologies ( i.g. if you already know C# very well and a bit less JavaScript, then it would make sense to start an ASP.Net MVC application; if you know JavaScript then ... )
                • Support: some technologies have bigger communities than others
                • Do you need to create a database that goes along with your application? Some technologies such as Entity Framework allows you to generate your database from the code: code-first approach.  That can be convenient to generate your database with your Object Model.

                 

                So my personal way of doing web project today could be qualified of an Hybrid between your two approaches.

                Let's assume I want to create an application that contains some business data as well as some information about the interresting objects in the PI System:

                 

                • I would use ASP.Net MVC to start with a functional web site:
                  • That would support authentication out of the box
                  • That has a _Layout.cs that defines the base layout of all my pages.
                  • It has PartialViews: you can use them with JavaScript JQuery Ajax calls to refresh only a part of a web screen
                  • I can create and maintain a database with the code in my web application models.
                • I would use JQuery to make calls to the PI Web API and or others data sources.
                  • Once a page is loaded (from the ASP.NET MVC Web Site) with all the business information, you can query the PI Web API using the PI System Objects information that was loaded on the page.
                  • Javascript and JQuery is used for more dynamic content to avoid page reloads, and make data calls to either APIs or Partial views.  i.g. a trend, a dynamic grid...

                So to me, complexity can be better handled with the usage of the two methods: Server Side + Client Side.  It keeps more doors opened to solve your problems.

                And the server side can provide a nice way to add you own APIs and Partial Views in addition to other APIs such as PI Web API.

                3 of 3 people found this helpful
                • Re: PI Web API Architectural Question
                  Marcos Vainer Loeff

                  Hello Neil,

                   

                  One thing to consider between both of your approaches is the performance. Using the MVC pattern to make calls to PI Web API does not seem to the best option considering speed. In this case, I would rather choose approach 1 since we would be getting rid of this additional layer. Nevertheless, using the MVC pattern with PI AF SDK could be an interesting alternative since the web server will connect directly to the PI System (and not through another application as PI Web API).

                  According to your business logic, approach 1 is a great option since PI Web API is a custom ASP.NET Web API application whose controller/actions/methods are optimized for best performance including cache control and also provides multi-user access. Nevertheless, there are some scenarios where developing your own MVC or MVC + Web API solution might be more interesting:

                   

                  • When you want to take advantage of the Entity Framework Identity for Authentication (credentials are saved on SQL Server) instead of using the Windows credentials used by PI Web API.
                  • When writing your own actions and controllers in order to raise the performance. This depends on your use case. Imagine that you need to get a lot of data from different data sources, make complex calculations in order to return a Boolean. This logic should be on the server-side and not on the client side. Sometimes it cannot be on the client due to security restrictions as all the client-side code is publicly accessible. Currently, PI Web API does not let you develop your own custom actions and controllers. This is why according to your use case, developing a custom ASP.NET project with PI AF SDK might be an interesting alternative.

                   

                  You are able to write actions for AJAX requests on Web API Controllers and MVC Controllers. If you plan to create an app for iOS or Android later, it is better write the actions on the ASP.NET Web API Controllers which integrates better with this type of application. Nevertheless, having an ASP.NET solution with MVC and Web API makes your project more complex to develop and maintain than a solution with MVC only.

                   

                  Here are my conclusions:

                   

                  • If you want to use Windows Authentication and your project does not require creating custom actions in order to raise performance, just use PI Web API with JavaScript. If you don’t have enough time and/or resources available, this for sure the easiest option.
                  • If you want to use Entity Framework Identity and will create mobile apps on the future, create an ASP.NET project with MVC and Web API using PI AF SDK  for communicating with the PI System (and not PI Web API). This is the option you choose if you want to write SPA. In this case, the MVC will be used only to display the main page. Write your actions on the Web API controllers. As Barry has mentioned, SPA works great with AngularJS.
                  • If you want to use Entity Framework Identity and will not create mobile apps on the future, you can create an ASP.NET MVC project with PI AF SDK. This way, you would write your actions on the MVC controllers. Although this option does work, the industry is moving to SPA as it improves the user experience.

                   

                  Hope it helps!

                  6 of 6 people found this helpful