Evaluate Sunsetting Gisida (as a Library) vs Refactoring 2.0

[cKellyDesign]

With the advent of Gisida Views we have rapidly prototyped and shown the value of productizing Gisida by focusing on Sources and Views and streamlining the layer specification process with an inline UI/UX.

This approach (Gisida as a Service) diverges from our current approach (Gisida as a Library), which impacts our current clients (namely: Reveal), which brings the question:

What do we do with Gisida 1.x?

To @mberg's point, Gisida [1.x] is still a useful library so we need to evaluate how to move forward in a way in which to continue supporting our clients and avoiding multi-track development.

[cKellyDesign]

Proposal: Migrate, Consolidate, Deprecate

First proposed here (option 2), what if we do not entirely deprecate the Gisida libraries, and instead repurpose Gisida/-React to be a GIS centric package library similar to OpenSRP Web and JS Tools.

This would constitute a Gisida 2.0 refactor which could migrate (and iterate upon) code directly from Gisida Views, which could then be installed and used in Gisida Views and other React frontend apps (namely Reveal).

Public vs Private

If Gisida (as a Library) and Gisida Views (as a Service) are both either public or private, we could set up the service in the same repo as the package library, exactly how we are doing with OpenSRP Web. Otherwise, if the service needs to remain private while the library remains public, then Gisida (as a Library) should remain exclusively a package library like JS Tools.

@mberg @dmccarey - thoughts on this point?

Migrate

Some of the packages that make Gisida and Gisida React so useful are non-GIS specific components and functionalities, which ultimately should live in JS Tools.

Consolidate

The rest of the GIS specific code is then spread between two repositories, which made sense at the time of 1.0 as we were trying to decouple the dependency of React (though, to @moshthepitt's point, we ended up tightly coupled to Redux). The intention here was that a developer using Gisida with non-React view components would not need to bundle all the Reactful components in order to use Gisida.

However, by the nature of using Lerna to manage components / services / utilities as packages (which are independently installed), we will actually have more code-splitting control by returning to a monolithic repo approach for Gisida (as a Library).

Deprecate

With this approach, the current Gisida/-React 1.x components and functionalities will be deprecated and will not be included in Gisida (as a Library) 2.0, and will be replaced with equivalent components and functionalities brought over from the current Gisida Views repository.

This should go hand in hand with achieving Gisida 1.x feature parity with Gisida Views.

[moshthepitt]

@cKellyDesign this seems to be the right thing to do, according to me. What are the next steps?

[moshthepitt]

@cKellyDesign for me personally, it would be useful to start with a "technical vision" for the proposed Gisida tools that would be made into package(s). For instance, how would it/they compare with something like react-map-gl?

[kahummer]

@cKellyDesign This is really nice. I was looking at gisida-react and I think Most components can move to js-tools here https://github.com/onaio/gisida-react/tree/master/src/lib/components. Do we do away with the Map component we have on gisida-react and embrace react-mapbox-gl ? The other aspect we may need to consider is adding canopy iframes, custom profileviews and dashboards to gisida-views so we have these for current clients who have such setups on gisida

[cKellyDesign]

Technical Vision

Private product repositories (React, Gisida Views, GRP, etc) utilize portable/reusable code from specialized package libraries (js-tools, gisida 2.0, opensrp-web).

Where We're At

Where We're Going (Proposed)

[cKellyDesign]

the proposed Gisida tools that would be made into package(s)

@moshthepitt - Agreed, and I think this level of granularity would amount to roadmap items.

how would it/they compare with something like react-map-gl?

Do we do away with the Map component we have on gisida-react and embrace react-mapbox-gl ?

@moshthepitt @kahummer - One of the Gisida 2.0 packages would be a new Map component which utilizes react-map-gl and is simply passed layers and data. This would probably look like a cross between Reveal's GisidaWrapper and Gisida View's current Map components.

The other aspect we may need to consider is adding canopy iframes, custom profileviews and dashboards to gisida-views so we have these for current clients who have such setups on gisida

@kahummer - Agreed, the more we can generalize the customizations the more we can shift into JS Tools. One piece of this proposal I'm not sure about is how to incorporate those custom components in the SaaS product on a client-by-client basis. Definitely open to suggestions!

Definitely open to suggestions!

cc - @dmccarey @moshthepitt @p-netm @kelvin-muchiri @ciremusyoka @pld

[moshthepitt]

@cKellyDesign nice work putting all this together. 👏🏼

[kahummer]

The design above is a really nice way to explain the architecture. I think the best thing would be to settle on a design that will at least showcase how this will look like before we go into development. That will then inform on what we are missing in terms of components and what we need to work on