Technical Architecture, Runtime Model, Extensibility, Security, Integration, and Enterprise Engineering

SharePoint Framework (SPFx)

Technical Architecture, Runtime Model, Extensibility, Security, Integration, and Enterprise Engineering

1. Introduction

The SharePoint Framework (SPFx) is Microsoft’s client-side extensibility model for building custom experiences that execute within SharePoint Online and selected Microsoft 365 surfaces.

Although SPFx is frequently introduced as a framework for building SharePoint Web Parts, this description is technically incomplete. SPFx is better understood as an extensibility runtime, packaging model, development toolchain, API integration layer, and application lifecycle model for Microsoft 365 client-side solutions.

At a high level:

User
↓
Microsoft 365 Identity
↓
SharePoint Online
↓
Modern Page / Supported Host
↓
SPFx Runtime
↓
Custom SPFx Component
↓
Application / Service Layer
↓
Microsoft 365 or Enterprise APIs
↓
SharePoint / Microsoft Graph / External Systems

The critical architectural characteristic is that custom application code executes primarily in the browser, rather than as custom server-side code inside the SharePoint service.

This is fundamentally different from the historical SharePoint development model based on server-side components deployed directly into the SharePoint farm.

SPFx therefore represents not simply a new Web Part technology, but a fundamental change in the SharePoint application architecture:

from server-side platform customization to governed client-side extensibility.

2. Historical Architectural Context

Traditional SharePoint development historically included technologies such as:

• Farm Solutions;
• WSP packages;
• server-side Web Parts;
• custom application pages;
• event receivers;
• timer jobs;
• custom HTTP modules;
• sandboxed solutions;
• SharePoint Add-ins;
• arbitrary JavaScript injection.

Many of these approaches assumed that custom code could execute inside or very close to the SharePoint server environment.

That model is incompatible with the operational architecture of a multi-tenant cloud service such as SharePoint Online.

Microsoft must be able to update the SharePoint service continuously without allowing tenant-specific server binaries to interfere with the platform.

SPFx therefore establishes a different boundary:

SharePoint Service

↓

Supported Extension Points

↓

SPFx Runtime

↓

Tenant Application

↓

Browser

The tenant controls the custom application.

Microsoft controls the SharePoint service.

The application interacts with the service through supported APIs and extension points rather than modifying the server runtime itself.

This separation is one of the most important architectural principles behind SPFx.

3. SPFx as a Client-Side Extensibility Runtime

SPFx applications are fundamentally browser applications hosted within a Microsoft 365 context.

Consider a simple Project Dashboard.

The execution path might be:

User opens SharePoint page

↓

SharePoint loads page structure

↓

SPFx runtime identifies registered component

↓

JavaScript bundle is loaded

↓

SPFx creates component instance

↓

Component receives execution context

↓

React application is mounted

↓

Application service calls SharePoint

↓

SharePoint returns JSON

↓

React state is updated

↓

Browser renders UI

This architecture contains several independent layers.

Hosting layer

SharePoint provides the page or extension host.

SPFx runtime layer

SPFx initializes and manages the custom component.

Application layer

Custom TypeScript implements business behavior.

Presentation layer

React or another rendering mechanism builds the UI.

Integration layer

SharePoint APIs, Microsoft Graph, or external APIs provide data and operations.

This separation is essential for designing maintainable SPFx applications.

4. SPFx Is Not React

One of the most common conceptual mistakes is treating SPFx and React as interchangeable technologies.

They are not.

SPFx is the extensibility framework.

React is a UI library that can execute inside an SPFx solution.

Conceptually:

SharePoint

↓

SPFx

↓

Application

↓

React

React could theoretically be replaced by another rendering approach while the SPFx hosting architecture remained.

SPFx provides capabilities such as:

• component lifecycle;
• SharePoint context;
• property management;
• extensibility registration;
• packaging;
• deployment;
• API clients;
• authentication integration;
• environment awareness.

React provides:

• components;
• state;
• rendering;
• hooks;
• composition;
• UI lifecycle;
• reusable presentation logic.

This distinction becomes particularly important when troubleshooting.

A rendering problem may belong to React.

A property initialization problem may belong to SPFx.

An HTTP authorization problem may belong to SharePoint or Microsoft Graph.

A deployment problem may belong to the App Catalog.

These are different architectural layers.

5. Development Architecture

A typical SPFx development environment contains several components:

Developer Workstation

↓

Node.js

↓

npm

↓

SPFx Toolchain

↓

TypeScript Compiler

↓

Build System

↓

Bundling

↓

SPFx Package

↓

SharePoint App Catalog

The important point is that the development runtime and production runtime are different.

Node.js participates primarily in:

• dependency management;
• compilation;
• development server execution;
• packaging;
• bundling;
• build tasks;
• linting and validation.

Node.js does not normally execute the production Web Part for the end user.

Production execution is closer to:

Browser

↓

SharePoint Page

↓

SPFx Runtime

↓

JavaScript Bundle

This distinction is critical when analyzing dependency, performance, and security problems.

6. TypeScript as the Application Language

TypeScript is the primary language used for SPFx application development.

Its importance goes significantly beyond syntactic convenience.

Enterprise SPFx applications commonly exchange structured data between:

UI components;

services;

SharePoint;

Microsoft Graph;

REST APIs;

application state;

configuration objects.

TypeScript provides a compile-time type system for defining these contracts.

For example:

export interface IProject {
  Id: number;
  Title: string;
  Status: ProjectStatus;
  OwnerId: number;
  Modified: string;
}

A service can then expose:

public async getProjects(): Promise<IProject[]> {
    // implementation
}

The UI consumes an explicit contract rather than an unstructured object.

Conceptually:

External JSON

↓

Mapping

↓

TypeScript Interface

↓

Application Model

↓

React Component

This becomes increasingly important as application complexity grows.

7. SPFx Component Model

SPFx provides several component models for different extensibility scenarios.

The major categories include:

Client-Side Web Parts

Visual components placed on supported pages.

Application Customizers

Extensions that participate in application-level experiences and supported placeholders.

Field Customizers

Extensions that control the rendering of fields in supported list experiences.

ListView Command Sets

Extensions that introduce custom commands into lists and document libraries.

Adaptive Card Extensions

Components associated particularly with Viva Connections scenarios and Adaptive Card-based experiences.

These are not simply different UI controls.

They represent different extension points.

A good architecture selects the extension point based on the responsibility of the solution.

8. Client-Side Web Part Architecture

A Web Part is instantiated by the SPFx runtime inside a page.

A simplified lifecycle is:

Page

↓

Web Part registration

↓

Component initialization

↓

onInit()

↓

Properties and context available

↓

render()

↓

React root

↓

React component tree

↓

User interaction

↓

State updates

↓

Re-render

↓

Disposal

A common architecture separates the Web Part bootstrapper from the React application.

For example:

ProjectDashboardWebPart.ts

↓

ProjectDashboard.tsx

↓

Child Components

↓

Application Services

↓

SharePoint / Graph / APIs

The Web Part class should generally not become the entire application.

Its responsibilities are better limited to concerns such as:

• SPFx lifecycle;
• context initialization;
• property handling;
• service initialization;
• root component mounting;
• cleanup.

Business logic should be moved into more appropriate layers.

9. SPFx Context

One of the most important objects available to an SPFx component is its context.

The context represents information and capabilities associated with the environment in which the component is executing.

Conceptually:

SPFx Component

↓

Context

├── Page information
├── Site/Web information
├── User context
├── HTTP clients
├── Microsoft Graph client capabilities
├── Service scope
├── Environment information
└── Component-related services

The context acts as an architectural bridge between custom code and the Microsoft 365 host environment.

This is preferable to manually reconstructing information such as the current site URL or authentication environment.

10. Web Part Properties

Web Part properties represent persistent configuration for a Web Part instance.

For example:

export interface IProjectDashboardWebPartProps {
  listName: string;
  pageSize: number;
  showArchived: boolean;
  defaultView: string;
}

These values might be configured through the Property Pane.

The architectural flow is:

Developer

↓

Defines property schema

↓

Property Pane controls

↓

Page author configures instance

↓

Configuration is persisted

↓

Web Part receives properties

↓

Application behavior changes

This allows the same implementation to support multiple configurations without recompilation.

11. Property Pane Architecture

The Property Pane provides an authoring-time configuration interface.

This establishes an important separation:

Application implementation

versus

Application instance configuration

For example, one Web Part package could be configured as:

Instance A:

List = ActiveProjects
PageSize = 10

Instance B:

List = ArchivedProjects
PageSize = 50

The code remains identical.

Only configuration changes.

This improves reusability and reduces the number of specialized Web Parts required.

12. SharePoint Data Access

SPFx applications frequently consume SharePoint data.

At the lowest conceptual level:

SPFx

↓

HTTP

↓

SharePoint REST

↓

JSON

A REST request might target resources such as:

Sites

Webs

Lists

Libraries

Items

Files

Folders

Fields

Content Types

Users

Groups

Permissions

Search

The application receives structured responses that must be converted into application models.

A robust architecture should avoid spreading raw REST operations across UI components.

Instead:

React Component

↓

Application Service

↓

SharePoint Service

↓

REST / PnPjs

↓

SharePoint

This isolates data-access concerns from presentation logic.

13. PnPjs

PnPjs provides a higher-level TypeScript/JavaScript API for interacting with Microsoft 365 services.

A SharePoint operation might conceptually resemble:

const items = await this.sp.web.lists
    .getByTitle("Projects")
    .items
    .select("Id", "Title", "Status")();

This abstraction improves:

• readability;
• composability;
• query construction;
• maintainability;
• consistency.

However, PnPjs should not be confused with SPFx.

The relationship is:

SPFx

↓

Application

↓

PnPjs

↓

SharePoint API

PnPjs is a library.

SPFx is the hosting and extensibility framework.

SharePoint REST is the underlying service interface in many SharePoint operations.

14. Service Layer Architecture

For non-trivial applications, a dedicated service layer is highly desirable.

A possible structure is:

src/
 ├── webparts/
 │    └── projectDashboard/
 │         ├── ProjectDashboardWebPart.ts
 │         ├── components/
 │         ├── models/
 │         └── services/
 │
 ├── services/
 │    ├── SharePointService.ts
 │    ├── GraphService.ts
 │    └── ApiService.ts
 │
 ├── models/
 └── common/

Conceptually:

UI

↓

Application Logic

↓

Service Interface

↓

Service Implementation

↓

External Platform

For example:

ProjectDashboard.tsx

↓

IProjectService

↓

ProjectService

↓

PnPjs

↓

SharePoint

This architecture improves testability and reduces coupling.

15. Dependency Injection and ServiceScope

SPFx provides mechanisms such as ServiceScope for managing service dependencies.

The architectural principle is similar to dependency injection:

Consumer

↓

Requests service

↓

ServiceScope

↓

Service implementation

Instead of every component manually constructing dependencies, shared services can be registered and consumed through an application-level mechanism.

This becomes valuable when multiple components require common capabilities such as:

• logging;
• telemetry;
• caching;
• configuration;
• API access;
• user context;
• localization.

For very small Web Parts this may be unnecessary.

For larger applications it can significantly improve architecture.

16. Microsoft Graph Integration

SharePoint is only one part of Microsoft 365.

Microsoft Graph provides a unified API surface for many Microsoft 365 services.

Conceptually:

SPFx

↓

Graph Client

↓

Microsoft Graph

↓

Microsoft 365

Depending on the endpoint and granted permissions, Graph can expose resources associated with services such as:

Users

Groups

Sites

Files

Teams

Mail

Calendar

Directory

OneDrive

A dashboard might therefore combine:

SharePoint List → Projects

Microsoft Graph → Project Owners

Corporate API → Financial Data

into a single UI.

Architecture:

SPFx Dashboard

├── SharePoint Service
│ ↓
│ SharePoint REST
│
├── Graph Service
│ ↓
│ Microsoft Graph
│
└── ERP Service
↓
Corporate API

This is where SPFx becomes particularly powerful as an enterprise experience layer.

17. Authentication vs Authorization

Security architecture requires a clear distinction between authentication and authorization.

Authentication

Determines:

Who is the caller?

Authorization

Determines:

What is the caller allowed to do?

The user is already authenticated to Microsoft 365 when accessing a normal SharePoint Online experience.

SPFx executes within that authenticated environment.

However:

Authenticated ≠ Authorized for everything.

For example:

User

↓

Authenticated to Microsoft 365

↓

SPFx Web Part

↓

Requests SharePoint document

↓

SharePoint authorization

↓

Allowed / Denied

The same principle applies to Microsoft Graph.

The existence of an SPFx component does not override resource permissions.

18. Delegated Security Context

Many SPFx API scenarios operate in a delegated user context.

Conceptually:

User Identity

↓

SPFx

↓

API Client

↓

Access Token

↓

API

↓

Authorization

The API evaluates the request based on the effective identity and granted permissions.

This is fundamentally different from a backend daemon application using application permissions.

Understanding this distinction becomes especially important when comparing:

SPFx

vs

Azure Function

vs

Daemon Service

vs

Power Automate Connection

vs

Copilot Studio Action

The execution identity can be different in each architecture.

19. API Permission Governance

When an SPFx solution requires additional Microsoft Graph or Entra-protected API permissions, those permissions should be treated as part of the solution’s security architecture.

The lifecycle becomes conceptually:

Developer declares requirement

↓

Package deployed

↓

Permission request

↓

Administrator reviews

↓

Permission approved

↓

SPFx application can request access

This creates an administrative governance boundary.

A developer should not automatically obtain unrestricted Graph access merely because an SPFx package has been deployed.

20. Client-Side Security Boundary

The most important SPFx security rule is:

The browser is not a trusted secret store.

Anything delivered to browser JavaScript should be considered inspectable.

Therefore, the following should not be embedded directly in an SPFx bundle:

• client secrets;
• private keys;
• database credentials;
• permanent privileged tokens;
• administrative passwords;
• privileged API keys.

A user can inspect:

JavaScript bundles

Network requests

Browser memory

Developer tools

HTTP responses

Therefore:

SPFx
   ↓
secret embedded in JavaScript

is fundamentally unsafe.

For APIs requiring confidential credentials, introduce a trusted backend.

For example:

SPFx

↓

Authenticated Backend API

↓

Authorization

↓

Managed Identity / Secure Credential

↓

External Service

The backend becomes the security boundary.

21. Backend-for-Frontend Pattern

A useful enterprise pattern is a Backend for Frontend, or BFF.

Architecture:

Browser

↓

SPFx

↓

BFF API

↓

Authentication / Authorization

↓

Business Services

↓

Database / ERP / External API

The BFF can perform operations that should never occur directly from browser code.

Examples include:

• confidential credential handling;
• privileged API calls;
• server-side validation;
• aggregation;
• complex authorization;
• data transformation;
• audit logging.

This is especially important when integrating SPFx with non-Microsoft enterprise systems.

22. Application Customizers

Application Customizers allow SPFx solutions to participate in application-level extension points.

Conceptually:

SharePoint Application

↓

Application Customizer

↓

Supported Placeholder

↓

Custom UI

Common scenarios may include:

• enterprise notification banners;
• contextual information;
• global navigation integrations;
• support widgets;
• environment indicators.

The critical architectural principle is to use supported extension mechanisms rather than DOM manipulation against undocumented SharePoint internals.

Direct DOM manipulation creates fragile solutions because Microsoft can change internal page structures.

Supported extension points provide a more stable contract.

23. Field Customizers

A Field Customizer changes how field data is presented.

Consider:

Raw value:

Critical

Rendered value:

visual badge + icon + tooltip

The architecture is:

List Data

↓

Field Value

↓

Field Customizer

↓

Custom Rendering

↓

User

The underlying data remains the same.

The customization belongs primarily to the presentation layer.

24. ListView Command Sets

A ListView Command Set introduces commands into supported list and library experiences.

For example:

Document Library

↓

Select document

↓

Custom command

↓

“Request Legal Review”

↓

SPFx Command Set

↓

API / Power Automate / SharePoint operation

This is an excellent example of combining UI extensibility with backend workflow.

SPFx controls the user interaction.

Power Automate or another service may execute the actual business process.

25. Separation of UI and Workflow

SPFx should not automatically contain all business process logic.

Consider an approval process.

A poor architecture might attempt to implement the complete approval engine inside browser JavaScript.

A more appropriate architecture is:

User

↓

SPFx

↓

Submit request

↓

SharePoint / API

↓

Power Automate

↓

Approval

↓

Business Rules

↓

Notification

↓

Persist status

↓

SPFx displays status

Responsibilities remain clear:

SPFx = interaction and presentation

SharePoint = content/data

Power Automate = workflow

This separation generally improves reliability and maintainability.

26. State Management

As SPFx applications grow, state management becomes increasingly important.

Possible categories include:

Component state

Temporary UI state.

Application state

Shared state across multiple components.

Persistent configuration

Web Part properties or external configuration.

Server state

Data stored in SharePoint, Graph, Dataverse, APIs, or other systems.

These categories should not be mixed unnecessarily.

For example:

React State

≠

SharePoint List

A selected tab belongs in UI state.

A purchase request belongs in persistent enterprise storage.

27. Asynchronous Programming

SPFx applications perform extensive asynchronous I/O.

Examples include:

• SharePoint REST calls;
• Graph requests;
• external REST APIs;
• file operations;
• dynamic module loading.

Modern TypeScript typically uses:

Promise<T>

and:

async / await

Conceptually:

UI Event

↓

Async Function

↓

HTTP Request

↓

Await Response

↓

Process JSON

↓

Update State

↓

Render

Correct asynchronous architecture is important for:

• error handling;
• loading states;
• concurrency;
• cancellation;
• performance;
• user experience.

28. Error Handling

Enterprise SPFx applications should not assume that API operations always succeed.

Possible failures include:

HTTP 400

HTTP 401

HTTP 403

HTTP 404

HTTP 429

HTTP 500

Network failure

Timeout

Invalid JSON

Permission changes

Deleted resource

Unexpected schema

A robust architecture handles failures by layer.

For example:

API

↓

Service catches technical failure

↓

Application maps technical error

↓

UI receives meaningful state

↓

User receives actionable message

Instead of:

Unhandled Promise Rejection

the user might see:

You do not have permission to access the selected project library.

The technical error can separately be logged for diagnostics.

29. Throttling

Microsoft 365 services enforce service protection and throttling mechanisms.

Applications should therefore avoid architectures such as:

For each item:

↓

Call Graph

↓

Call SharePoint

↓

Call Graph

↓

Call SharePoint

A page displaying 500 records could accidentally generate hundreds or thousands of HTTP requests.

Better strategies include:

• batching where supported;
• selecting only required fields;
• pagination;
• caching;
• aggregation;
• avoiding duplicate requests;
• lazy loading;
• server-side aggregation where appropriate.

Performance architecture begins with reducing unnecessary network traffic.

30. Query Optimization

A poor SharePoint query might request complete objects when the UI needs only three properties.

Instead of retrieving everything:

Project object with dozens of fields

we may request:

Id

Title

Status

This reduces:

Network Payload

↓

JSON Parsing

↓

Memory Usage

↓

Rendering Cost

The same principle applies to Microsoft Graph and external APIs.

Only retrieve what the application requires.

31. Caching

Caching can significantly improve SPFx performance when used carefully.

Possible caching locations include:

• component memory;
• service-level memory;
• browser storage;
• session storage;
• distributed backend cache.

But caching introduces another problem:

staleness.

Therefore every cache strategy must answer:

What is being cached?

How long is it valid?

Is the information user-specific?

Could it contain sensitive information?

How is invalidation handled?

Can permissions change during the cache lifetime?

Caching authorization-sensitive information requires particular care.

32. Bundle Size

SPFx solutions ultimately deliver JavaScript to the browser.

Therefore dependency size matters.

Architecture:

Dependencies

↓

Bundling

↓

JavaScript

↓

Network

↓

Browser parsing

↓

Execution

A large dependency tree can increase:

• download time;
• parse time;
• memory consumption;
• startup latency.

Developers should therefore avoid adding large libraries merely for trivial functionality.

Performance is an architectural concern, not simply a final optimization step.

33. Lazy Loading

Some application capabilities do not need to load immediately.

For example:

Dashboard

↓

Initial view

but:

Advanced Report

may only be required when the user opens a specific section.

Lazy loading allows parts of the application to be loaded on demand.

Conceptually:

Initial Bundle

↓

Fast startup

↓

User opens advanced feature

↓

Load additional module

This can improve initial application performance.

34. Packaging

SPFx solutions are packaged as SharePoint solution packages.

Typical artifact:

.sppkg

Conceptually:

Source

↓

Compile

↓

Bundle

↓

Package Solution

↓

.sppkg

↓

App Catalog

The package contains metadata describing the solution and its components.

Deployment therefore differs from simply copying JavaScript files to a document library.

SPFx participates in an application deployment model.

35. App Catalog

The SharePoint App Catalog is an important governance component.

Architecture:

Development Pipeline

↓

SPFx Package

↓

App Catalog

↓

Administrative Deployment

↓

Tenant / Site Availability

↓

SharePoint Pages

This provides an organizational boundary between:

software creation

and

software availability.

In mature organizations, production App Catalog deployment should normally be part of a controlled release process.

36. Versioning

A production SPFx solution should have a deliberate versioning strategy.

For example:

1.0.0

↓

Initial production release

1.1.0

↓

Backward-compatible feature

1.1.1

↓

Bug fix

2.0.0

↓

Breaking change

Versioning becomes particularly important when multiple sites depend on the same package.

A small change can potentially affect many SharePoint sites.

Therefore SPFx deployment should be treated as software release management rather than page customization.

37. CI/CD

SPFx integrates naturally into modern DevOps pipelines.

A conceptual pipeline is:

Git Repository

↓

Pull Request

↓

Code Review

↓

Install Dependencies

↓

Compile

↓

Lint

↓

Tests

↓

Bundle

↓

Package

↓

Artifact

↓

Deploy DEV

↓

Integration Tests

↓

Deploy TEST

↓

Approval

↓

Deploy PROD

This can be implemented using platforms such as Azure DevOps or GitHub Actions.

The important architectural principle is repeatability.

Production packages should ideally be reproducible from source control.

38. Environment Configuration

Enterprise applications typically have multiple environments:

DEV

TEST

UAT

PROD

Hardcoding production URLs inside source code creates unnecessary deployment coupling.

Configuration may include:

• API URLs;
• site URLs;
• list identifiers;
• feature flags;
• telemetry endpoints;
• environment names.

A mature architecture externalizes environment-specific configuration wherever practical.

39. Logging and Telemetry

A production application needs observability.

Useful information may include:

• application version;
• component name;
• operation;
• duration;
• correlation identifier;
• API endpoint category;
• HTTP status;
• exception type;
• environment.

Conceptually:

SPFx

↓

Telemetry Service

↓

Central Monitoring

↓

Operational Analysis

However, logging must not accidentally expose:

• access tokens;
• secrets;
• sensitive document content;
• personal data unnecessarily.

Observability itself must follow security and privacy requirements.

40. Accessibility

SPFx solutions execute inside enterprise productivity environments and should therefore consider accessibility as part of engineering quality.

Areas include:

• semantic HTML;
• keyboard navigation;
• ARIA;
• screen readers;
• focus management;
• color contrast;
• accessible form labels.

Using Fluent UI components can help, but accessibility is not automatically guaranteed by using a component library.

The final application behavior must still be tested.

41. Fluent UI

Fluent UI provides Microsoft-aligned UI components.

Examples include:

Button

TextField

Dropdown

Dialog

Panel

DetailsList

Persona

MessageBar

CommandBar

Using Fluent UI can improve visual consistency with Microsoft 365.

The architecture becomes:

SPFx

↓

React

↓

Fluent UI

↓

Microsoft 365-like UX

However, Fluent UI remains a presentation library.

It should not contain business logic.

42. SharePoint Lists as Application Data Stores

SharePoint Lists can act as lightweight application data stores.

Example:

SPFx Request Application

↓

SharePoint List

Columns:

RequestId

Title

RequestedBy

Department

Status

Created

Modified

This architecture can be highly effective for moderate business applications.

However, SharePoint should not automatically be treated as a relational database.

Complex transactional requirements may justify Dataverse, SQL, or another dedicated data platform.

The architecture should follow the data model rather than forcing every application into SharePoint Lists.

43. Document-Centric Applications

SPFx is particularly strong for document-centric solutions because it operates directly inside SharePoint.

For example:

Engineering Document Portal

↓

SPFx

↓

Document Library

↓

Metadata

↓

Search

↓

Preview

↓

Approval Status

↓

Permissions

↓

Document Actions

This is a scenario where SPFx often provides substantial value compared with a completely separate application.

44. Search Applications

SPFx can also provide specialized search experiences.

Architecture:

User Query

↓

SPFx Search UI

↓

Search API

↓

Query Processing

↓

Results

↓

Custom Rendering

↓

Filters / Refiners

↓

User

A custom search experience may combine:

• SharePoint search;
• Microsoft Graph;
• taxonomy;
• metadata;
• external APIs.

Search is a good example of SPFx operating as an aggregation and presentation layer.

45. SPFx and Power Apps

SPFx and Power Apps solve overlapping but different classes of problems.

Neither is universally superior.

The correct choice depends on the problem.

46. SPFx and Power Automate

The distinction is even clearer:

SPFx = user experience

Power Automate = process automation

Example:

Employee

↓

SPFx

↓

Create Request

↓

SharePoint

↓

Power Automate

↓

Manager Approval

↓

Update SharePoint

↓

SPFx displays new status

This is generally preferable to implementing the approval orchestration entirely inside browser code.

47. SPFx and Copilot Studio

Copilot Studio introduces another architectural layer.

SPFx is primarily concerned with deterministic application experience.

An Agent is concerned with capabilities such as:

• natural-language interaction;
• generative reasoning;
• Knowledge;
• Retrieval;
• Grounding;
• Orchestration;
• Tools;
• Actions.

A useful separation is:

SPFx

=

Experience Layer

Copilot Studio Agent

=

Conversational / Reasoning Layer

Power Automate

=

Workflow Layer

SharePoint

=

Content / Collaboration / Lightweight Data Layer

Microsoft Graph

=

Microsoft 365 API Layer

This distinction is particularly important as organizations begin introducing Agents into existing SharePoint architectures.

An Agent should not replace a deterministic SPFx application simply because conversational AI is available.

48. SPFx + Agent Architecture

A future enterprise portal could contain:

User

↓

SharePoint Portal

↓

SPFx Application

↓

Business UI

and separately:

User

↓

Agent

↓

Knowledge / Tools

↓

Business Systems

These architectures can also converge:

SharePoint

↓

SPFx Experience

↓

Agent Interaction

↓

Copilot Studio

↓

Knowledge

↓

SharePoint

and:

Agent

↓

Action

↓

Power Automate

↓

SharePoint List

The important point is that each technology retains a clearly defined responsibility.

49. Deterministic UI vs Generative UI

Consider a request:

“Display all invoices with Status = Overdue.”

This is deterministic.

SPFx can execute a query and display the exact results.

Now consider:

“Explain why these overdue invoices may represent a risk.”

That is potentially generative.

A future architecture could therefore combine:

SPFx

↓

Retrieve deterministic invoice data

↓

Agent / AI capability

↓

Generate contextual analysis

The deterministic application provides facts.

The generative layer provides interpretation.

This separation is extremely important in enterprise AI architectures.

50. SPFx and Microsoft Graph vs Copilot Actions

Another important architectural distinction concerns API execution.

SPFx can directly call an API from the browser when the security model supports that approach.

An Agent can call a Tool or Action.

Power Automate can call a Connector.

A backend can call an API using application identity.

These execution models are not equivalent.

The architecture must explicitly determine:

Who is actually executing the operation?

This question is fundamental to security.

51. When SPFx Is the Correct Choice

SPFx is particularly appropriate when the requirement includes:

• custom SharePoint UI;
• rich document experiences;
• custom navigation;
• dashboards;
• complex interactive interfaces;
• custom list/library commands;
• Microsoft Graph aggregation;
• specialized search;
• custom metadata experiences;
• high-control React applications;
• Microsoft 365-integrated pro-code experiences.

52. When SPFx Is Not the Correct Choice

SPFx may be unnecessary when the requirement is:

“Send an email when an item changes.”

Use Power Automate.

“Add a field to a list.”

Use SharePoint.

“Build a simple business form quickly.”

Consider Power Apps.

“Answer questions about HR policies.”

Consider an Agent with SharePoint Knowledge.

“Expose a secure server-side API.”

Use a backend service.

“Execute a scheduled integration every night.”

Use an automation or backend workload.

Good architecture includes knowing when not to use SPFx.

53. Enterprise Reference Architecture

A mature Microsoft 365 solution might look like:

                    Microsoft Entra ID
                           │
                           ▼
                         User
                           │
                           ▼
                    SharePoint Online
                           │
                           ▼
                     SPFx Application
                           │
          ┌────────────────┼────────────────┐
          │                │                │
          ▼                ▼                ▼
     SharePoint        Microsoft        Corporate
       APIs              Graph             API
          │                │                │
          ▼                ▼                ▼
 Lists/Libraries      Microsoft 365       Backend
                                           │
                                           ▼
                                      ERP / CRM / SQL

A process layer may also exist:

SPFx
 │
 ▼
SharePoint
 │
 ▼
Power Automate
 │
 ├── Approval
 ├── Teams
 ├── Outlook
 └── External Systems

And an AI layer can be introduced independently:

User
 │
 ▼
Copilot Studio Agent
 │
 ├── Knowledge → SharePoint
 ├── Tool → Power Automate
 ├── Tool → REST API
 └── Tool → Enterprise System

This illustrates an important architectural principle:

SPFx does not need to become the entire enterprise application architecture.

It can specialize in the experience layer while other components specialize in their respective responsibilities.

54. Technical Reference Table

55. Architecture Decision Table

56. Final Technical Summary

Conclusion

SharePoint Framework should not be understood merely as Microsoft’s technology for creating custom SharePoint Web Parts.

From an enterprise engineering perspective, SPFx is a governed client-side application and extensibility model positioned between the Microsoft 365 user experience and enterprise service layers.

Its fundamental architecture is:

User

↓

Microsoft 365 Identity

↓

SharePoint / Microsoft 365 Host

↓

SPFx Runtime

↓

Custom TypeScript Application

↓

React / Presentation Layer

↓

Application Services

↓

Integration Services

↓

SharePoint / Microsoft Graph / Enterprise APIs

This architecture establishes several important boundaries.

The browser owns presentation and interaction.

SPFx provides the Microsoft 365 extensibility context.

TypeScript implements application behavior.

React can provide the component model.

Service classes isolate integration logic.

SharePoint provides content, documents and lightweight business data.

Microsoft Graph provides Microsoft 365 service APIs.

Power Automate provides deterministic workflow.

Backend services provide trusted server-side execution.

Copilot Studio Agents provide natural-language interaction, generative reasoning, Knowledge, orchestration and Tools.

Microsoft Entra ID provides identity and participates in the authorization architecture.

The resulting enterprise architecture should therefore not ask:

“Can SPFx do this?”

In many cases, technically, it can.

The more important architectural question is:

“Should this responsibility execute in the browser, in SharePoint, in Power Automate, in an Agent, in Microsoft Graph, in Dataverse, or in a trusted backend?”

That question represents the transition from simply being an SPFx developer to becoming a Microsoft 365 solution architect.

SPFx is strongest when it is allowed to perform the role for which it is architecturally suited:

building rich, governed, pro-code user experiences deeply integrated with SharePoint and the Microsoft 365 ecosystem without moving custom application code into the SharePoint server runtime.