Backends
PortalJS is decoupled by default: the frontend is independent from the backend and talks to it over an API. The same portal frontend can sit in front of a catalog system, a Git repo, plain static files, or a backend you already run — and you can start with static files and point at a real catalog later without rewriting the frontend. See Core concepts for the model.
Start static, connect later
The default — no backend — reads CSV/JSON from
/public/data/. When you're ready,
wire a real catalog with a skill like/connect-ckan.
The pattern (fetch server-side ingetStaticProps/getStaticPaths, pass plain props
to components) is the same for any backend.
CKAN
The first-class, skill-supported path. /connect-ckan
installs @portaljs/ckan, lists datasets from package_search, and renders each from
package_show, with CSV/TSV resources previewed through the template's <Table />.
Calls run server-side so the CKAN bundle never reaches the browser. See the
CKAN integration page and the
examples/ckan and
examples/ckan-ssg
examples.
DKAN
DKAN exposes a CKAN-compatible API (/api/3/action/...). Point the same
@portaljs/ckan client (or plain fetch) at a DKAN instance's API root and the
catalog/dataset pattern carries over. Confirm package_search/package_show
availability on your DKAN version first.
OpenMetadata
OpenMetadata is a metadata catalog with its own REST API. Fetch tables/datasets and their metadata server-side and render them with the same plain-props pattern. See the OpenMetadata blog walkthrough for an end-to-end example of fronting OpenMetadata with PortalJS.
Microsoft Purview
Purview is Microsoft's data governance and catalog service. Query its REST API (authenticated) on the server side, map the entities you want to surface into the portal's dataset shape, and render them — the frontend never needs to know it's Purview behind the API.
DataHub
DataHub exposes both a GraphQL and a REST API. Fetch the datasets/entities you want to
publish server-side, normalize them to the portal's dataset shape, and render. As with
every backend, keep the client lean by querying only in
getStaticProps/getStaticPaths.
GitHub
Treat a GitHub repo as the catalog: data files (CSV/JSON/GeoJSON) live in the repo, and
the portal reads them at build time. This is the simplest "backend" — no service to run.
See examples/github-backed-catalog.
Frictionless
Frictionless Data packages (a datapackage.json plus
data files) describe datasets in a portable, validated way. Read the package descriptor
to drive dataset metadata and resource lists. See
examples/dataset-frictionless.
Custom backend
Any system with an HTTP API works. The recipe is always the same:
- Fetch from your API server-side in
getStaticProps/getStaticPaths(orgetServerSidePropsfor always-live data). - Map the response into the portal's dataset shape (
slug,name,description, resources). - Pass plain serializable props to the page; render with
<Table>,<Chart>,<Map>, or your own components.
Because the output is plain editable code, there's no framework wiring to fight — and
you can model a new backend skill on /connect-ckan; see
Authoring skills.
Where to go next
- Connect a CKAN backend — the worked example.
- Authoring skills — package your backend integration as a reusable skill.