Power Pages Code Sites: 10 Limitations and Lessons from Building an Enterprise React SPA
Power Pages Code Sites make it possible to combine React, TypeScript, Dataverse, and Power Platform to build modern enterprise applications.
On paper, that combination looks straightforward.
Build the frontend in React. Connect it to Dataverse. Use Power Pages for authentication and security. Deploy through your Power Platform environments.
In practice, there are important architectural differences between building a Power Pages React SPA and building a traditional React application.
I learned many of these lessons while working through real enterprise requirements involving authentication, external identity providers, Dataverse APIs, ALM, CI/CD, security, environment configuration, and custom user experiences.
This isn’t a list of reasons to avoid Power Pages Code Sites.
It’s a list of things I wish I had understood before designing an enterprise application around them.
Here are the 10 lessons that had the biggest impact.
1. Power Pages Code Sites Are Not Just React Apps Hosted on Power Pages
This was my first and most important realization.
When developers hear React SPA, it’s natural to think about familiar architectures involving:
- Azure Static Web Apps
- Azure App Service
- Azure Front Door
- API Management
- Backend APIs
- Environment-specific frontend configuration
That mental model doesn’t completely translate to Power Pages Code Sites.
Your frontend might be React and TypeScript, but it still operates within the wider Power Pages platform architecture.
Power Pages can remain responsible for important platform concerns such as:
- Authentication
- Authorization
- Dataverse connectivity
- Site configuration
- Power Platform ALM
React gives you control over the experience, but it doesn’t replace the underlying platform.
What I wish I knew
Don’t start your architecture with:
Where should I host my React application?
Start with:
Which responsibilities should React own, and which responsibilities should Power Pages own?
That question leads to a much cleaner architecture.
2. Don’t Assume Traditional Power Pages Features Work the Same Way in an SPA
If you already know Power Pages, this can be surprisingly easy to overlook.
A Power Pages Code Site isn’t simply a traditional Power Pages website with React added to it.
There are differences in the development model and available capabilities.
For example, Microsoft currently documents considerations or limitations involving areas such as:
- Out-of-the-box lists and forms
- Progressive Web App configuration through the setup experience
- Built-in unit and integration testing
- Extensive direct HTML editing
- SEO with client-side rendering
- How source code and compiled files participate in source control
That means a requirement that sounds simple in a traditional Power Pages implementation may need a different approach in a React SPA.
What I wish I knew
Build a capability matrix during solution design.
For every major requirement, classify it as:
- ✅ Supported out of the box
- 🔧 Requires custom implementation
- ⚠️ Requires architectural consideration
- ❌ Not currently supported
Do this before estimating the project.
It can prevent significant rework later.
3. Authentication Is an Architecture Decision, Not Just Configuration
Authentication initially looks like a setup activity.
Then enterprise requirements begin appearing.
You might need:
- An external identity provider
- Different identity configurations across environments
- Local development authentication
- Deep linking
- Custom redirects
- Logout handling
- Role-aware navigation
- Secure access to downstream APIs
Authentication quickly becomes one of the most important architectural decisions in the solution.
One lesson from my own experience was particularly important:
Don’t automatically treat every authentication challenge you encounter as a permanent Power Pages limitation.
There may be multiple supported architectural approaches available, and the correct option depends heavily on the identity scenario.
Questions to answer early
Before building significant UI functionality, document:
- How does authentication start?
- Where does authentication occur?
- How are sessions managed?
- How does logout work?
- What changes between environments?
- How does authentication work locally?
- How is authorization enforced?
- How are downstream APIs secured?
What I wish I knew
Identity architecture should be part of your solution blueprint, not something you solve immediately before production.
For enterprise Power Pages implementations, getting this decision right early can save considerable complexity later.
Authentication deserves a deeper discussion, particularly when external identity providers and enterprise SSO are involved.
4. Local Development Doesn’t Always Mean Production-Like Development
React developers naturally expect a workflow resembling:
Clone → npm install → npm run dev → localhost → start coding
You can absolutely develop a modern frontend locally.
But there’s a more important question:
Does your local development environment reproduce the authentication, authorization, configuration, and data-access behavior of production?
Those are two different things.
This becomes particularly important when you’re working with external enterprise identity providers or environment-specific authentication configuration.
The UI may work perfectly on localhost while an identity or authorization problem only appears in another environment.
What I wish I knew
I now separate local development into two questions.
Question 1: Can developers run the application locally?
That’s the basic developer experience.
Question 2: Can developers reproduce production behavior locally?
That’s the enterprise engineering question.
For complex projects, the second question matters much more.
5. Your Dataverse Web API Strategy Matters Earlier Than You Think
Dataverse integration is one of the most attractive reasons to use Power Pages.
For straightforward user experiences, consuming data through the appropriate platform APIs can work extremely well.
But enterprise applications rarely remain straightforward.
Eventually you may encounter:
- Larger data volumes
- Complex queries
- Related tables
- Business transactions
- High-volume operations
- Sophisticated authorization requirements
- External system integration
If every requirement automatically becomes another frontend API call, your architecture can become difficult to maintain.
A simple decision framework
When designing a data operation, I now ask three questions.
Is this primarily a UI data operation?
Use the appropriate Power Pages and Dataverse capabilities.
Is this business logic?
Consider whether the responsibility belongs closer to Dataverse or another server-side boundary.
Is this an enterprise integration?
Evaluate whether an integration layer or asynchronous architecture is more appropriate.
What I wish I knew
Convenient API access shouldn’t eliminate your application’s service boundaries.
Keeping UI logic, business logic, and integration logic separate becomes increasingly valuable as the application grows.
6. Power Pages Security Is an Advantage. Don’t Accidentally Rebuild It in React.
One temptation with a code-first frontend is to start rebuilding everything yourself.
Authentication.
Authorization.
Role management.
Data filtering.
API security.
That can quickly eliminate one of the main advantages of choosing Power Pages.
A custom React experience doesn’t mean your security architecture also needs to become completely custom.
What I wish I knew
My preferred principle is:
Use React to build the experience. Use the platform to enforce security boundaries wherever appropriate.
The less security-critical functionality you unnecessarily reproduce in frontend JavaScript, the better.
This doesn’t eliminate the need for security design.
Tokens, configuration, external APIs, authorization, redirects, and identity flows still require careful architecture.
The key point is simpler:
Using React isn’t a reason to discard the Power Pages security model.
7. ALM Gets More Important When You Introduce React
Adding React to Power Pages introduces conventional software engineering practices into the Power Platform delivery lifecycle.
Suddenly you’re dealing with both worlds:
- Git repositories
- Branching
- Pull requests
- npm packages
- TypeScript compilation
- Build artifacts
- Power Platform solutions
- PAC CLI
- Environment configuration
- CI/CD pipelines
This is where teams can get into trouble if ALM isn’t designed upfront.
There are also important distinctions between your actual application source code and the compiled artifacts deployed to the platform.
Define these before production
Your ALM strategy should clearly answer:
- Where does the authoritative source code live?
- What gets compiled?
- What is the deployment artifact?
- What belongs inside Power Platform solutions?
- How is configuration different between environments?
- How are deployments promoted?
- How do you perform rollback?
What I wish I knew
Don’t let your first production deployment define your ALM strategy for you.
For enterprise implementations, ALM should be part of the architecture from the beginning.
8. Your React Application May Become More Coupled to Power Pages Than You Expect
At the beginning, the architecture may look very simple:
React UI → API → Data
But over time, the application can naturally start depending on platform capabilities such as:
- Power Pages authentication
- Power Pages configuration
- Dataverse Web APIs
- Platform security context
- Dataverse server-side extensibility
- Environment configuration
That isn’t necessarily bad architecture.
In fact, platform integration can eliminate infrastructure you would otherwise have to build, secure, deploy, monitor, and operate yourself.
But there is a trade-off.
Suppose someone later says:
Let’s move this React application to another hosting platform.
That may not be a simple hosting change.
It could become an architectural migration.
What I wish I knew
Document every major frontend dependency and classify it as:
- Portable
- Power Pages-specific
- Dataverse-specific
This creates a much clearer picture of your application’s actual platform dependency.
9. A Custom React UI Means Owning the Entire User Experience
Why choose React in the first place?
Usually, the answer is control.
You can create:
- Rich interactions
- Custom components
- Sophisticated navigation
- Complex workflows
- Tailored state management
- Highly customized user experiences
But additional control also means additional responsibility.
With a custom React application, your team may need to own much more of the experience, including:
- Loading states
- Validation
- Error handling
- Accessibility
- Responsive design
- State management
- Navigation
- Caching
- Performance optimization
- Component design
- Reusability
These items are easy to miss during estimation because they’re often not visible in a wireframe.
What I wish I knew
Don’t estimate a React application by counting screens.
Estimate the behaviors behind those screens.
The visible UI can represent only a portion of the actual engineering effort.
10. The Best Power Pages Architecture Works With the Platform, Not Against It
This is my biggest lesson.
Many frustrations happen when we expect Power Pages to behave exactly like a conventional web application hosting platform.
It doesn’t.
And it doesn’t need to.
Power Pages brings its own platform capabilities into the architecture.
React brings modern frontend engineering and flexibility.
Dataverse provides the business data platform.
Azure and external services can then be introduced where the requirements justify them.
My architecture principle today
I would summarize the approach like this:
Let React own the experience.
Let Power Pages own platform concerns where appropriate.
Let Dataverse own business data and suitable domain logic.
Introduce Azure or external services when the use case genuinely requires them.
That separation of responsibilities creates a much cleaner architecture than attempting to recreate a traditional web application stack inside Power Pages.
So, Should You Use Power Pages Code Sites for an Enterprise React SPA?
Yes, for the right use case.
This article isn’t an argument against Power Pages Code Sites.
Quite the opposite.
The combination becomes particularly interesting when your requirements involve:
- A highly customized external-facing experience
- React or TypeScript development
- Dataverse-centered business data
- Enterprise authentication
- Power Platform governance
- Custom frontend interactions
- Existing Power Platform investments
But I would evaluate a Power Pages Code Site very differently today than when I first started.
Before committing to the architecture, I would investigate these eight areas:
Power Pages Code Site Architecture Checklist
- [ ] Authentication architecture
- [ ] Local development strategy
- [ ] ALM and CI/CD
- [ ] Dataverse access patterns
- [ ] React and platform boundaries
- [ ] Environment configuration
- [ ] Security responsibilities
- [ ] Enterprise integration architecture
If your team has clear answers to those questions, you’re in a much better position to make an informed architecture decision.
Final Thoughts: Power Pages + React Requires Both Skill Sets
Power Pages Code Sites represent an interesting evolution of Power Pages.
They give professional developers more freedom to create modern frontend experiences while remaining within the broader Power Platform ecosystem.
But adopting React doesn’t make Power Pages disappear.
That may be the single most important lesson from my experience.
Building an enterprise-grade solution requires knowledge of both worlds.
You need software engineering discipline to build a maintainable React application.
But you also need to understand:
- Power Pages
- Dataverse
- Authentication
- Security
- Power Platform ALM
- Environment management
- Enterprise integration patterns
Teams that understand only the React side may underestimate the platform architecture.
Teams that understand only traditional Power Pages may underestimate the engineering responsibilities of a custom SPA.
The real opportunity is where those two worlds meet.
And that’s where Power Pages Code Sites become genuinely interesting.
What Has Your Experience Been with Power Pages Code Sites?
If you’ve built a React SPA using Power Pages Code Sites, I’d love to compare notes.
What limitation, architectural decision, or unexpected behavior surprised you the most?
I’m particularly interested in experiences around authentication, ALM, local development, Dataverse integration, and enterprise deployments.
Share your experience in the comments.
This article reflects practical lessons from enterprise implementation experience. Power Pages Code Sites continue to evolve, so always validate important architectural decisions against the latest Microsoft documentation.