Shared Validation Logic Across Angular and React Native Using API Contracts

In banking applications, validation is not a minor concern. It is part of the domain. Every input—payment amount, IBAN, customer data, transaction limits—must be validated consistently and correctly. A mismatch between frontend and backend validation is not just a UX issue. It can lead to failed transactions, inconsistent behavior across channels, and in some cases, compliance risks. 

Yet in many systems, validation logic is duplicated: 

once in the backend  

once in the web frontend (Angular)  

once in the mobile app (React Native)  

Over time, these implementations diverge. A rule changes in one place but not the others. Edge cases are handled differently. Error messages become inconsistent. 

The result is what teams often underestimate: validation drift. The way out of this is not better discipline. It is better architecture—specifically, contract-driven validation using shared schemas. 

The Root Problem: Duplication of Business Rules 

In traditional frontend-backend architectures, validation is implemented independently in each layer. The backend enforces rules to guarantee correctness. The frontend reimplements them to provide immediate feedback. Mobile applications do the same. 

At first, this seems reasonable. In practice, it creates multiple sources of truth. 

A simple rule such as: “payment amount must be between 1 and 10,000” ends up implemented three times, often with subtle differences. 

Over time, systems accumulate: inconsistent validation ranges, different interpretations of required fields, mismatched error handling. This is not a tooling issue. It is an architectural one. 

API Contracts as the Single Source of Truth 

The core idea behind contract-driven validation is simple: Validation rules should be defined once and reused everywhere. 

API contracts—defined using OpenAPI, JSON Schema, or GraphQL schemas—already describe the structure of requests and responses. With the right approach, they can also define validation rules. 

For example, a payment request schema: 

 1 { 
 2   "type": "object", 
 3   "properties": { 
 4     "amount": { 
 5       "type": "number", 
 6       "minimum": 1, 
 7       "maximum": 10000 
 8     }, 
 9     "currency": { 
10       "type": "string", 
11       "enum": ["EUR", "USD", "RON"] 
12     } 
13   }, 
14   "required": ["amount", "currency"] 
15 } 

This schema is not just documentation. It becomes the contract that both backend and frontend must follow. The backend enforces it at runtime. The frontend uses it to validate user input before submission. 

There is no duplication. There is one definition.  

Schema-Based Validation in Angular and React Native 

Modern frontend frameworks can consume these schemas directly. In Angular, libraries such as reactive forms can be wired to schema-based validation. In React Native, similar approaches can be implemented using validation libraries that interpret JSON schemas. 

The result is that validation logic is no longer handwritten. It is generated or derived from the contract. 

This enables: 

• consistent validation across platforms  
• automatic updates when contracts change  
• reduced maintenance overhead  

Instead of writing validation rules in multiple places, teams focus on maintaining the contract. 

Schema-Driven Form Generation 

Once validation rules are defined in schemas, they can also drive form generation. A form can be constructed dynamically based on: field types, required attributes, validation constraints, enumerations. 

For example: 

• a numeric field becomes an input with min/max constraints 
• an enum becomes a dropdown  
• required fields are marked automatically  

This approach reduces boilerplate and ensures that forms always reflect the underlying domain rules. It also enables faster development of new features, especially in systems with many forms, such as onboarding or loan applications. 

Avoiding Drift Between Frontend and Backend 

Drift occurs when different parts of the system evolve independently. Contract-driven validation prevents this by enforcing a shared dependency. 

When a rule changes: the schema is updated > frontend applications consume the new version  > backend validation remains aligned.

Versioning becomes critical here. Contracts must be versioned and backward-compatible to avoid breaking existing clients. 

For example new optional fields can be added safely and existing constraints should not be tightened without coordination  

This introduces discipline into how validation evolves across the system. 

Handling Complex Validation Logic 

Not all validation can be expressed in simple schemas. Some rules depend on context: 

• conditional fields (e.g., required only if another field is set)  
• cross-field validation (e.g., date ranges)  
• domain-specific logic (e.g., account eligibility)  

In these cases, the contract still plays a role. 

Basic validation is handled through schemas, while complex rules are enforced through: backend domain logic, 

explicit API responses, validation endpoints when needed. 

The key is to keep simple rules in the contract and complex rules centralized, rather than duplicating them across clients. 

Integration with Backend Validation 

Even with contract-driven validation, the backend remains the final authority. Frontend validation improves user experience by catching errors early. Backend validation ensures correctness and security. 

Both must rely on the same contract. This creates a layered validation model: 

1. frontend: fast feedback, contract-based  
2. backend: authoritative validation, contract-enforced  

This approach eliminates inconsistencies while maintaining system integrity. 

Benefits in Financial Systems 

In fintech and banking platforms, the impact of this approach is significant. 

It reduces: 

• inconsistent user experiences across web and mobile  
• bugs caused by mismatched validation  
• duplicated effort across teams  

It improves: development speed, maintainability, alignment between teams.

Most importantly, it ensures that business rules are applied consistently, which is critical in financial operations. 

Organizational Impact 

Adopting contract-driven validation requires alignment across teams. Backend teams must treat API contracts as first-class artifacts. 

Frontend teams must consume and trust these contracts. Business Analysts must ensure that validation rules are correctly captured in the schema. This shifts the focus from implementation to definition and governance. 

The contract becomes the shared language between teams. 

Takeaways 

Validation is often seen as a technical detail. In financial systems, it is a core part of the domain. Duplicating validation logic across frontend and backend inevitably leads to drift. The solution is not stricter processes, but a shared foundation. 

By using API contracts as the single source of truth, and driving validation and forms from schemas, teams can eliminate inconsistencies and build systems that behave predictably across platforms. 

In the end, consistency is not just about code reuse. It is about ensuring that every part of the system enforces the same rules—every time, everywhere.