Sustainable WebGIS architecture: five layers beyond a disposable viewer
Data, service, application, security and operations design that lets a geoportal change its interface without rebuilding rules or sources.
A sustainable WebGIS architecture separates data, rules, services and interface. The web map is a consumer, not the place where critical identifiers, permissions or calculations live. This separation makes it possible to replace the viewer, add a mobile application or publish an API without duplicating the geospatial model. A fifth layer, operations, turns the diagram into a service that can actually be maintained.
The decision this guide supports
The starting point is the system of record: which database holds the authorised version and where rules are enforced. Read or edit services come next, followed by user experience. Choosing a map library first reverses this order and often pushes business logic into the browser. Architecture needs to document which component is replaceable and which contract must remain stable.
Give each layer a clear responsibility. The database preserves identity and relationships; preparation pipelines produce publishable versions; services control query and editing; the interface composes tasks; operations observe availability, cost and security. Define contracts between layers so a viewer can change without rewriting the model or copying critical data into the browser. Include caching, limits, authentication where applicable, backups, traces and recovery from the outset. A useful exit test replaces one component on a sample and confirms that identifiers, permissions, metadata and links still work.
Recommended workflow
- Agree. Model data, identifiers, history and constraints in a governed system of record.
- Structure. Expose queries and changes through documented services with server-side validation.
- Check. Build the application on stable contracts and explicit error states.
- Document. Apply identity, authorisation, audit records and secret handling by layer.
- Operate. Operate with metrics, backup, recovery tests, updates and named owners.
Minimum controls before publishing or delivery
A useful review combines automated checks with expert judgement. At minimum, record:
- versioned API contracts.
- caching that does not hide critical updates.
- an accessible fallback when map or font fails.
- observability from user action to source data.
Limits that must remain visible
Open source does not remove the cost of security, data, support or availability, and a managed product does not remove the need for governance. Not every service should be public either. Geospatial interoperability requires explicit licences, metadata and boundaries. Design should support recoverable degradation: essential content without JavaScript, messages when WebGL fails and downloads that identify source and cutoff.
To apply this method to a concrete project, review the GeoSAT sector service and compare its dependencies with the related service. These links serve different intents: this guide explains the process, while the service pages define scope, evidence and the appropriate commercial next step.