Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-8867

Applications access data via Rest services versus via direct database access

    Details

    • Epic Link:
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      Security
    • Application Requirement:
      KS
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      For CRUD operations.

      Based on conversations with Garey, we would like this to focus on Rest services and how they can be better integrated with KRAD.

        Attachments

          Issue Links

            Activity

            Hide
            wwashington William Washington (Inactive) added a comment -

            Ability to write a screen only using XML and noting what the service is and the method to call. This would allow the more easily creation of CRUD screens for things like code tables (e.g. Org admin, Academic Time Period.).

            Rationale/Background - KS currently has to write controller logics that translates and update button to call the update method in the service for the object. The workaround has been to write the glue code for each controller (using maintainable & lookable). KS doesn't want to have to maintain all that code. But in some cases, KS screens are so complex that we need custom controllers anyway.

            Show
            wwashington William Washington (Inactive) added a comment - Ability to write a screen only using XML and noting what the service is and the method to call. This would allow the more easily creation of CRUD screens for things like code tables (e.g. Org admin, Academic Time Period.). Rationale/Background - KS currently has to write controller logics that translates and update button to call the update method in the service for the object. The workaround has been to write the glue code for each controller (using maintainable & lookable). KS doesn't want to have to maintain all that code. But in some cases, KS screens are so complex that we need custom controllers anyway.
            Hide
            gtaylor Garey Taylor added a comment -

            I believe KRAD has been looking into having the client call directly to REST/JSON services. I'd be interested in hearing Rice's thoughts on that possible path. This might allow more of a decoupling of the front end, designed with krad beans and the backend.

            Show
            gtaylor Garey Taylor added a comment - I believe KRAD has been looking into having the client call directly to REST/JSON services. I'd be interested in hearing Rice's thoughts on that possible path. This might allow more of a decoupling of the front end, designed with krad beans and the backend.
            Hide
            jcoltrin Jessica Coltrin (Inactive) added a comment -

            We need more info here since it's not clear what's wanted here. Peter and Garey should meet and generate user stories so we know what's needed. Also if the estimate is over 200 hours this needs to go to KRRM queue.

            Show
            jcoltrin Jessica Coltrin (Inactive) added a comment - We need more info here since it's not clear what's wanted here. Peter and Garey should meet and generate user stories so we know what's needed. Also if the estimate is over 200 hours this needs to go to KRRM queue.
            Hide
            lsymms Larry Symms added a comment -

            please include me in any conversations on theis topic

            Show
            lsymms Larry Symms added a comment - please include me in any conversations on theis topic
            Hide
            gilesp Peter Giles (Inactive) added a comment - - edited

            I chatted with both Garey and Larry this week on this issue.

            Garey's take was, in a nutshell, that they want to be able to author pages with KRAD that work more like angular.js pages in that all the back end interaction is done via RESTful services. The wins would be:

            • a stronger separation of concerns that frees front end developers from writing custom controllers.
            • faster development of new screens
            • improved performance and scalability

            Talking to Larry, the heart of this request is that instead of dealing with data objects and persistence in KRAD, they would like to be able to configure a screen (e.g. a maint doc) to utilize a RESTful service to handle the CRUD operations on the data. They specifically want to use JSON data formats and client side data binding. This will help KS to achieve its architectural objectives and allow them to develop screens in a way that meets their needs.

            A key issue that Larry brought up is one of timing. Currently, 2.6 is the last version of Rice that KS is definitely going to take. After that they will be making their upgrade decisions based on impact that they are willing to accept. That imposes an aggressive time line on us to deliver this functionality if they are going to be able to take advantage of it.

            Show
            gilesp Peter Giles (Inactive) added a comment - - edited I chatted with both Garey and Larry this week on this issue. Garey's take was, in a nutshell, that they want to be able to author pages with KRAD that work more like angular.js pages in that all the back end interaction is done via RESTful services. The wins would be: a stronger separation of concerns that frees front end developers from writing custom controllers. faster development of new screens improved performance and scalability Talking to Larry, the heart of this request is that instead of dealing with data objects and persistence in KRAD, they would like to be able to configure a screen (e.g. a maint doc) to utilize a RESTful service to handle the CRUD operations on the data. They specifically want to use JSON data formats and client side data binding. This will help KS to achieve its architectural objectives and allow them to develop screens in a way that meets their needs. A key issue that Larry brought up is one of timing. Currently, 2.6 is the last version of Rice that KS is definitely going to take. After that they will be making their upgrade decisions based on impact that they are willing to accept. That imposes an aggressive time line on us to deliver this functionality if they are going to be able to take advantage of it.
            Hide
            jkneal Jerry Neal (Inactive) added a comment -

            Is client side binding an absolute requirement for this? That requires KRAD to shift to a client side MVC framework, which even if we determined today we wanted to do would take a lot of time. We can get the benefits of Rest services with the server side binding. In fact, you can get 2 of the three mentioned benefits today. The back end can be provided with Rest services that your front end connects to (over the service bus). The only difference is currently you need to translate the data from the Rest services to data objects that KRAD can work with, so it is extra work for developing the screens. However, in general data from the backend needs to be transformed (for the presentation) in some way anyhow, with the exception of Maintenance, Lookup, and Inquiry. The real win I see would be allowing those frameworks to connect directly do a service for its CRUD operations, which is a long standing enhancement we have talked about.

            Show
            jkneal Jerry Neal (Inactive) added a comment - Is client side binding an absolute requirement for this? That requires KRAD to shift to a client side MVC framework, which even if we determined today we wanted to do would take a lot of time. We can get the benefits of Rest services with the server side binding. In fact, you can get 2 of the three mentioned benefits today. The back end can be provided with Rest services that your front end connects to (over the service bus). The only difference is currently you need to translate the data from the Rest services to data objects that KRAD can work with, so it is extra work for developing the screens. However, in general data from the backend needs to be transformed (for the presentation) in some way anyhow, with the exception of Maintenance, Lookup, and Inquiry. The real win I see would be allowing those frameworks to connect directly do a service for its CRUD operations, which is a long standing enhancement we have talked about.

              People

              • Assignee:
                Unassigned
                Reporter:
                wwashington William Washington (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated: