This is a draft vision statement for GeoNode 3.0 provided for community discussion and collaboration. It is purely for guiding discusion and not fixed. The vision consists of the following reinforcing principles:
- Django
- Minimal core
- Behavior Driven Development
- Fresh Start
- Web UI Framework Agnostic
- API First & API Gateway
- Support for multiple data providers
Essentially:
- GeoNode 1 was a proof of concept.
- GeoNode 2 is a working product.
- GeoNode 3 is a working product based on Python 3 and Django 2.
- GeoNode 4 is a scalable product.
GeoNode 4.0, as the previous versions, will continue to be built on Django. However, it's usage of Django will adapt to the modern software environment. The community-supported GeoNode version will continue to use PostGIS as the recommended database for Django.
The future core Django python library of GeoNode should be minimal and consist of only support for database models and GeoNode centric API views. Front-end code, assets, etc. will be independent of the core Django application codebase. This core will include at least layers, maps, and documents and define the concept of a dataset.
GeoNode 4.0 should adopt a behavior driven development approach. All features are described as behavioral tests using Python Behave or similar library. These behaviors, all together, describe the entire API surface.
GeoNode 4.0 codebase should be it's own separate repo. Code, including core database models, will be ported over to the new codebase as needed. Fresh CSW, security, etc. sub-systems will be incorporated over time.
GeoNode 4.0 should support Angular, React, Preact, or Vue.js by being web UI agnostic. All interaction with the GeoNode app server should take place via well documented (REST) APIs - based on the OpenAPI specification. Common front-end components should be managed within their own relevant ecosystem (React Components, Angular Modules, etc.) rather than as Django apps. They'll be no community support for instances based on Django html templates.
Rationale
When Geonode 1 was initially developed, the web was a very different place. Modern web frameworks like Angular and React did not exist. For GeoNode 1, the benefit of using shared Django html templates made great sense as developing and maintaining web pages had a high cost. Shared templates were necessary to deliver a turnkey solution. GeoNode 2 reduced the cost of deployment even further by switching to using Bootstrap. HTML templates also allowed customization by organizations.
Today, modern websites are built on one of the common web UI frameworks and REST web APIs rather than server rendered html pages. Additionally, organizations usually want to have a unifying "brand" and user experience that encompasses their web presence, rather than just a logo. By being web UI framework agnostic, GeoNode can support a wider variety of user experiences and be tailored to fit an instituion's needs.
The core codebase will take an API-first approach likely using Django REST Framework (DRF) w/ support for Swagger UI. Hereby two seperate but interoperable APIs will be delivered:
a) GeoNode REST API for GeoNode centric objects, like identity management, dashboard, datasets and there alike
b) OGCAPI based API for example delivered by pygeoapi
Both APIs coexist and are loosely coupled.
Since GeoNode 4.0 will be web UI agnostic, a common gateway will be used to interact with the GeoNode backend (based on the API first approach) rather than APIs for specific web UI frameworks. Since there are two APIs (OGC and GeoNode) the developed clients could pick the needed interfaces as their need.
GeoNode should be built to support multiple data providers, including:
- GeoServer,
- QGIS Server,
- Tegola,
- Solr,
- Elasticsearch/ElasticGeo, and
- GeoMesa.
Implementation
Django's PostgreSQL contrib app may provide flexibility we can leverage to avoid overly complicated database models while still covering multiple data providers. For example, we could use a single HstoreField to store a dict of backend authentication parameters.