by Joche Ojeda | Mar 12, 2025 | dotnet, http, netcore, netframework, network, WebServers
Last week, I was diving into Uno Platform to understand its UI paradigms. What particularly caught my attention is Uno’s ability to render a webapp using WebAssembly (WASM). Having worked with WASM apps before, I’m all too familiar with the challenges of connecting to data sources and handling persistence within these applications.
My Previous WASM Struggles
About a year ago, I faced a significant challenge: connecting a desktop WebAssembly app to an old WCF webservice. Despite having the CORS settings correctly configured (or so I thought), I simply couldn’t establish a connection from the WASM app to the server. I spent days troubleshooting both the WCF service and another ASMX service, but both attempts failed. Eventually, I had to resort to webserver proxies to achieve my goal.
This experience left me somewhat traumatized by the mere mention of “connecting WASM with an API.” However, the time came to face this challenge again during my weekend experiments.
A Pleasant Surprise with Uno Platform
This weekend, I wanted to connect a XAF REST API to an Uno Platform client. To my surprise, it turned out to be incredibly straightforward. I successfully performed this procedure twice: once with a XAF REST API and once with the API included in the Uno app template. The ease of this integration was a refreshing change from my previous struggles.
Understanding CORS and Why It Matters for WASM Apps
To understand why my previous attempts failed and my recent ones succeeded, it’s important to grasp what CORS is and why it’s crucial for WebAssembly applications.
What is CORS?
CORS (Cross-Origin Resource Sharing) is a security feature implemented by web browsers that restricts web pages from making requests to a domain different from the one that served the original web page. It’s an HTTP-header based mechanism that allows a server to indicate which origins (domains, schemes, or ports) other than its own are permitted to load resources.
The Same-Origin Policy
Browsers enforce a security restriction called the “same-origin policy” which prevents a website from one origin from requesting resources from another origin. An origin consists of:
- Protocol (HTTP, HTTPS)
- Domain name
- Port number
For example, if your website is hosted at https://myapp.com, it cannot make AJAX requests to https://myapi.com without the server explicitly allowing it through CORS.
Why CORS is Required for Blazor WebAssembly
Blazor WebAssembly (which uses similar principles to Uno Platform’s WASM implementation) is fundamentally different from Blazor Server in how it operates:
- Separate Deployment: Blazor WebAssembly apps are fully downloaded to the client’s browser and run entirely in the browser using WebAssembly. They’re typically hosted on a different server or domain than your API.
- Client-Side Execution: Since all code runs in the browser, when your Blazor WebAssembly app makes HTTP requests to your API, they’re treated as cross-origin requests if the API is hosted on a different domain, port, or protocol.
- Browser Security: Modern browsers block these cross-origin requests by default unless the server (your API) explicitly permits them via CORS headers.
Implementing CORS in Startup.cs
The solution to these CORS issues lies in properly configuring your server. In your Startup.cs file, you can configure CORS as follows:
public void ConfigureServices(IServiceCollection services) {
services.AddCors(options => {
options.AddPolicy("AllowBlazorApp",
builder => {
builder.WithOrigins("https://localhost:5000") // Replace with your Blazor app's URL
.AllowAnyHeader()
.AllowAnyMethod();
});
});
// Other service configurations...
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env) {
// Other middleware configurations...
app.UseCors("AllowBlazorApp");
// Other middleware configurations...
}
Conclusion
My journey with connecting WebAssembly applications to APIs has had its ups and downs. What once seemed like an insurmountable challenge has now become much more manageable, especially with platforms like Uno that simplify the process. Understanding CORS and implementing it correctly is crucial for successful WASM-to-API communication.
If you’re working with WebAssembly applications and facing similar challenges, I hope my experience helps you avoid some of the pitfalls I encountered along the way.
About Us
YouTube
https://www.youtube.com/c/JocheOjedaXAFXAMARINC
Our sites
Let’s discuss your XAF
https://www.udemy.com/course/microsoft-ai-extensions/
Our free A.I courses on Udemy
by Joche Ojeda | Mar 8, 2024 | Uncategorized
Navigating the Challenges of Event-Based Systems
Event-based systems have emerged as a powerful architectural paradigm, enabling applications to be more scalable, flexible, and decoupled. By orchestrating system behaviors through events, these architectures facilitate the design of responsive, asynchronous systems that can easily adapt to changing requirements and scale. However, the adoption of event-based systems is not without its challenges. From debugging complexities to ensuring data consistency, developers must navigate a series of hurdles to leverage the full potential of event-driven architectures effectively. This article delves into the critical challenges associated with event-based systems and provides insights into addressing them.
Debugging and Testing Complexities
One of the most daunting aspects of event-based systems is the complexity involved in debugging and testing. The asynchronous and decoupled nature of these systems makes it challenging to trace event flows and understand how components interact. Developers must adopt sophisticated tracing and logging mechanisms to visualize event paths and diagnose issues, which can significantly increase the complexity of testing strategies.
Ensuring Event Ordering
Maintaining a correct sequence of event processing is crucial for the integrity of an event-based system. This becomes particularly challenging in distributed environments, where events may originate from multiple sources at different times. Implementing mechanisms to ensure the orderly processing of events, such as timestamp-based ordering or sequence identifiers, is essential to prevent race conditions and maintain system consistency.
Complex Error Handling
Error handling in event-driven architectures requires careful consideration. The loose coupling between components means errors need to be communicated and handled across different parts of the system, often necessitating comprehensive strategies for error detection, logging, and recovery.
Latency and Throughput Challenges
Balancing latency and throughput is a critical concern in event-based systems. While these architectures can scale effectively by adding more consumers, the latency involved in processing and reacting to events can become a bottleneck, especially under high load conditions. Designing systems with efficient event processing mechanisms and scaling strategies is vital to mitigate these concerns.
Mitigating Event Storms
Event storms, where a flood of events overwhelms the system, pose a significant risk to the stability and performance of event-based architectures. Implementing back-pressure mechanisms and rate limiting can help control the flow of events and prevent system overload.
Dependency Management
Although event-based systems promote decoupling, they can also introduce complex, hidden dependencies between components. Managing these dependencies requires a clear understanding of the event flow and interactions within the system to avoid unintended consequences and ensure smooth operation.
Data Consistency and Integrity
Maintaining data consistency across distributed components in response to events is a major challenge. Event-based systems often require strategies such as event sourcing or implementing distributed transactions to ensure that data remains consistent and accurate across the system.
Security Implications
The need to secure event-driven architectures cannot be overstated. Events often carry sensitive data that must be protected, necessitating robust security measures to ensure data confidentiality and integrity as it flows through the system.
Scalability vs. Consistency
Event-based systems face the classic trade-off between scalability and consistency. Achieving high scalability often comes at the cost of reduced consistency guarantees. Finding the right balance based on system requirements is critical to the successful implementation of event-driven architectures.
Tooling and Monitoring
Effective monitoring and management are essential for maintaining the health of an event-based system. However, the lack of visibility into asynchronous event flows and distributed components can make monitoring challenging. Selecting the right set of tools that offer comprehensive insights into the system’s operation is crucial.
Conclusion
While event-based systems offer numerous advantages, successfully implementing them requires overcoming a range of challenges. By understanding and addressing these challenges, developers can build robust, scalable, and efficient event-driven architectures. The key lies in careful planning, adopting best practices, and leveraging appropriate tools and technologies to navigate the complexities of event-based systems. With the right approach, the benefits of event-driven architecture can be fully realized, leading to more responsive and adaptable applications.
by Joche Ojeda | Mar 7, 2024 | C#, dotnet, netcore, netframework
Understanding AppDomains in .NET Framework and .NET 5 to 8
AppDomains, or Application Domains, have been a fundamental part of isolation and security in the .NET Framework, allowing multiple applications to run under a single process without affecting each other. However, the introduction of .NET Core and its evolution through .NET 5 to 8 has brought significant changes to how isolation and application boundaries are handled. This article will explore the concept of AppDomains in the .NET Framework, their transition and replacement in .NET 5 to 8, and provide code examples to illustrate these differences.
AppDomains in .NET Framework
In the .NET Framework, AppDomains served as an isolation boundary for applications, providing a secure and stable environment for code execution. They enabled developers to load and unload assemblies without affecting the entire application, facilitating application updates, and minimizing downtime.
Creating an AppDomain
using System;
namespace NetFrameworkAppDomains
{
class Program
{
static void Main(string[] args)
{
// Create a new application domain
AppDomain newDomain = AppDomain.CreateDomain("NewAppDomain");
// Load an assembly into the application domain
newDomain.ExecuteAssembly("MyAssembly.exe");
// Unload the application domain
AppDomain.Unload(newDomain);
}
}
}
AppDomains in .NET 5 to 8
With the shift to .NET Core and its successors, the concept of AppDomains was deprecated, reflecting the platform’s move towards cross-platform compatibility and microservices architecture. Instead of AppDomains, .NET 5 to 8 emphasizes on assembly loading contexts for isolation and the use of containers (like Docker) for application separation.
AssemblyLoadContext in .NET 5 to 8
using System;
using System.Reflection;
using System.Runtime.Loader;
namespace NetCoreAssemblyLoading
{
class Program
{
static void Main(string[] args)
{
// Create a new AssemblyLoadContext
var loadContext = new AssemblyLoadContext("MyLoadContext", true);
// Load an assembly into the context
Assembly assembly = loadContext.LoadFromAssemblyPath("MyAssembly.dll");
// Execute a method from the assembly (example method)
MethodInfo methodInfo = assembly.GetType("MyNamespace.MyClass").GetMethod("MyMethod");
methodInfo.Invoke(null, null);
// Unload the AssemblyLoadContext
loadContext.Unload();
}
}
}
Differences and Considerations
- Isolation Level: AppDomains provided process-level isolation without needing multiple processes. In contrast,
AssemblyLoadContext provides a lighter-weight mechanism for loading assemblies but doesn’t offer the same isolation level. For higher isolation, .NET 5 to 8 applications are encouraged to use containers or separate processes.
- Compatibility: AppDomains are specific to the .NET Framework and are not supported in .NET Core and its successors. Applications migrating to .NET 5 to 8 need to adapt their architecture to use
AssemblyLoadContext or explore alternative isolation mechanisms like containers.
- Performance: The move away from AppDomains to more granular assembly loading and containers reflects a shift towards microservices and cloud-native applications, where performance, scalability, and cross-platform compatibility are prioritized.
Conclusion
While the transition from AppDomains to AssemblyLoadContext and container-based isolation marks a significant shift in application architecture, it aligns with the modern development practices and requirements of .NET applications. Understanding these differences is crucial for developers migrating from the .NET Framework to .NET 5 to
