Uploaded image for project: 'ui-eholdings'
  1. ui-eholdings
  2. UIEH-643

Spike: Approach to integrations with other Folio modules/plug-ins



    • eHoldings Sprint 58
    • 2
    • Spitfire


      eholdings app is designed completely different from any other Folio app. eholdings uses:

      • data layer versus stripes-connect
      • json+api versus json
        As a result the app has challenges when integrating with other apps (e.g. tags). For Q1 2019 and Q2 2019, the eholdings app will integrate with several modules/plug-ins, Agreements, Notes. And in the future other integrations will focus on Licenses, Orders, etc.

      Spike needs to address the following:

      • How can we address Q1 2019 (March)/Q2 2019 (June) integrations of Agreements and Notes?
      • Do we need to refactor tags implementation given approach(es) under consideration.
      • Which approach is optimal? What is estimated timeframe?
      • Which approach will ensure we have Agreements and Notes integration available by Q2.
      • please consider reaching out to Matt Jones

      Spike Timebox: 12 hours

      • Have options for how to implement Agreements integration as defined in backlog user stories. Provide benefits and challenges to these options
        • Consider option for mod-kb-ebscojava to be a proxy and work with backend team on estimates
      • Provide estimates for options
      • Present to team
        1. SPIKE RESULTS:

      Currently UI-eholdings Data layer was build taking into account that all the communication with the back-end is performed through mod-kb-ebso.
      The ui-eholdings data layer expect that the response payload follow the JSON API format.

      Only mod-kb-ebsco follow the JSON API specification. All other back-end modules follow the POJO format.

      In order to be able to communicate with the other module there are two approaches could be taken:
      1) This approach is similar to the applied one.

      • Add new model
      • Add the deserializer
        Deserrializer could be added in the '/redux/data.js' extending the 'resolve' action creator, modifieng the payload to fit the JSON API structure.
      • Customize serializer
        Serializer should be added to the model to fit the required payload structure of the POST/PUT requests.


      • Less code modifications/refactoring


      • Less flexible approach than elaboration of specific for the request/ side effect epic/actions/reducers
      • wired t the current setup of resolver
        The described above approach was used in ui-eholdings for the requests to mod-tags.
        This was implemented in the following PR: https://github.com/folio-org/ui-eholdings/pull/748

      2) Add new epic/actions/reducers

      • Data should change through small actions, which are responsible for the small piece of logic.
      • Create Epic(RX middleware) which subscribe on needed action and does the request for fetching or updating the data.
      • Create Reducer for updating a piece of global App Store.
      • Write tests for actions, epics, reducers


      • Is flexible. Doesn’t depend on the data type.
      • Clear and simple. Is a common React approach for managing the data in the app. The low learning curve for new React Front-End devs.
      • Easy to test and debug
      • No dependencies and inheritance like in models. The composition is preferable.


      • Requires to write boilerplate plate code every time


      TestRail: Results


          Issue Links



                kgambrell Khalilah Gambrell
                kgambrell Khalilah Gambrell
                0 Vote for this issue
                3 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases