Reusable frontend architecture proposal

Features

We build features, not pages or apps. A feature is a self-contained piece of customer-facing functionality, owned by one team. The idea is build once, reuse often: you build a feature a single time, and it gets reused across channels instead of being rebuilt for each place it needs to appear.

A feature can be realised in multiple ways

Depending on where a feature needs to show up, it can be realised as:

Realisation	What it is	Where it's used
Web application	Self-contained app with its own page	Visited directly, e.g. on ns.nl
Widget	Embedded into another team's web page. See the widget documentation section for more details	Inside a host application's web page
Webview	The web implementation shown inside the native app	In the NS app, via a web view
Native plugin	Fully native implementation	In the NS app, only when web can't do it

Frontpack helps teams build to multiple targets from a single feature codebase, so you write the feature once and ship it to every place it needs to run.

Still unsure which realisation fits your feature? Reach out to us.

Sharing components between teams/features

Besides sharing features, it's also important to share components between teams and features. Understanding the key differences between sharing features and sharing components matters:

Concept	What it is	Example	Integration	Owner release cycle
Feature	The reusable unit of functionality	Journey planner	Run-time	Feature team
Shared component	Reusable component via Nexus	Generic form components	Build-time	Consuming team

Widgets are integrated at runtime and remain owned and deployed by the feature team, so updating a widget updates every host that uses it without the host redeploying.