DEV Community: Shreyans Padmani

Different Between of MVC controller and APIController

Shreyans Padmani — Sun, 08 Mar 2026 11:21:42 +0000

In ASP.NET Core, both MVC Controllers and API Controllers handle HTTP requests, but they serve different purposes and are used in different application architectures. (Link — https://shreyans.tech/computer-vision-development-freelancer)

MVC Controller(ASP.Net MVC)

1️⃣ Handles HTTP Requests
Receives incoming browser requests and decides how to respond.

2️⃣ Returns Views (HTML)
Primarily used to return Razor Views (.cshtml) to render UI pages.

3️⃣ Inherits from Controller Class
Provides built-in support for views, model binding, TempData, and ViewBag.

4️⃣ Part of MVC Pattern
Acts as the middle layer between Model (data/business logic) and View (UI).

5️⃣ Supports Action Methods
Public methods inside the controller are called action methods and respond to routes.

6️⃣ Model Binding Support
Automatically binds form data, query strings, and route values to model objects.

7️⃣ ViewData, ViewBag & TempData
Used to pass data from Controller to View.

8️⃣ Supports Filters
Allows use of Action Filters, Authorization Filters, and Exception Filters.

9️⃣ Routing Integration
Works with ASP.NET routing to map URLs to specific controller actions.

🔟 Best for Server-Rendered Applications
Ideal for traditional web applications where the server generates HTML pages.

API Controller(ASP.Net Web API)

1️⃣ Designed for RESTful APIs
Handles HTTP requests and returns data (JSON, XML) instead of HTML views.

2️⃣ Inherits from ControllerBase
Lightweight base class optimized for API scenarios without view support.

3️⃣ Uses [ApiController] Attribute
Enables automatic model validation, binding, and better API conventions.

4️⃣ Returns Action Results or Data Objects
Common return types include IActionResult, ActionResult, or raw objects serialized to JSON/XML.

5️⃣ Supports Routing via Attributes
Uses [Route("api/[controller]")] and [HttpGet], [HttpPost] for endpoint mapping.

6️⃣ Automatic Model Binding & Validation
Request bodies are automatically bound to models, and invalid models trigger HTTP 400 responses.

7️⃣ Supports HTTP Methods Explicitly
Action methods can handle GET, POST, PUT, DELETE, PATCH using attributes.

8️⃣ Ideal for Frontend & Mobile Integration
APIs are consumed by Angular, React, mobile apps, or other services.

9️⃣ Stateless by Nature
API Controllers generally do not maintain session or state, following REST principles.

🔟 Supports Filters & Middleware
Can use authentication, authorization, exception handling, and logging filters for API behavior.

Conclusion

In ASP.NET, MVC Controllers and API Controllers serve different purposes. MVC Controllers are designed to render UI views for traditional web applications, while API Controllers are optimized for data-centric RESTful APIs, returning JSON or XML.

Official Website — shreyans.tech

How to build Multi-Tenant app with EF Core

Shreyans Padmani — Sun, 08 Mar 2026 11:14:00 +0000

Build a multi-tenant app with EF Core by adding TenantId to entities, applying global query filters, resolving tenant per request, isolating data via shared or separate databases, and enforcing secure dependency injection configuration.

EF Query Filters

Global Filtering
Automatically apply conditions to all queries for an entity (e.g., soft delete, multi-tenancy).

Defined in OnModelCreating
Configured using HasQueryFilter() inside the DbContext model builder.

Soft Delete Support
Commonly used to filter out records where IsDeleted = true.

Multi-Tenant Isolation
Filters data by TenantId to ensure users access only their tenant’s data.

Automatically Applied
No need to manually add Where clauses in every query.

Can Be Disabled Temporarily
Use IgnoreQueryFilters() when you need to bypass global filters.

**Supports Parameters
**Filters can use context-level variables (e.g., current tenant or user ID).

Improves Security & Consistency
Reduces risk of accidental data exposure and keeps filtering logic centralized.

Example

EF + Dynamic Connection String Resolution

Tenant-Based Database Selection
Dynamically choose a connection string based on the current tenant.

Supports Multi-Tenant Architecture
Enables separate databases per tenant for stronger data isolation.

Resolve Per Request
Determine the connection string from request data (subdomain, header, JWT claim).

Use DbContextOptionsBuilder
Configure the connection string inside OnConfiguring() or during service registration.

Dependency Injection Friendly
Inject a TenantProvider or ConnectionStringResolver service into DbContext.

Improves Security & Scalability
Isolates tenant data and allows independent scaling or migration.

Works with Multiple Providers
Can dynamically switch between SQL Server, PostgreSQL, etc., if required.

Supports Central Configuration Store
Store tenant connection strings in a master database or configuration service.

Requires Careful Lifetime Management
DbContext should be scoped per request to avoid cross-tenant leakage.

Useful for SaaS Applications
Ideal for enterprise SaaS platforms needing strict data separation.

Example

Conclusion

Dynamic connection string resolution in EF Core is a powerful approach for building scalable and secure multi-tenant applications. By resolving the database connection per request, you can ensure proper tenant isolation, improve data security, and enable flexible scaling strategies. When combined with dependency injection and proper DbContext scoping, it becomes a clean and maintainable solution for modern SaaS architectures.

In short, EF Core with dynamic connection string resolution enables true database-level multi-tenancy with flexibility and control.

Why We Use LangChain? — To Smoothly Connect with LLMs

Shreyans Padmani — Sun, 08 Mar 2026 11:05:07 +0000

In today’s AI-driven world, Large Language Models (LLMs) like OpenAI’s GPT models, Google’s Gemini, and Anthropic’s Claude are powerful tools. However, using them effectively in real-world applications requires more than just sending prompts and receiving responses.

What is LangChain ?

LangChain is an open-source Python framework for building application powered by Large Language Models (LLM)

Makes LLM context-aware by integrating external data and tools

Commonly Used for:

Chatbots
Question Answering
Document Analysis
RAG (Retrieval-Augmented Generation)

Why LangChain ?

Out-of-the-box LLM support (OpenAI, Hugging Face, Anthropic, etc.)
APIs
Vector databases (Pinecone, FAISS, Chroma)
Document loaders (PDF, CSV, web scraping)
Supports prompt templates, chains, and agents

How LangChain Works with LLMs

LangChain helps LLMs understand context, remember past interactions, and connect multiple steps to handle complex tasks easily.

Prompt Templates: Define reusable structures for questions or instructions, ensuring consistent and clear communication with the LLM.

Chains: Connect multiple steps or model calls to perform complex reasoning or multi-stage tasks automatically.

Memory: Allows the model to remember previous inputs and responses, giving conversations a continuous and contextual flow.

Agents: Enable the model to decide which action or tool to use next, such as searching data or calling an API.

Conclusion

In a world where Large Language Models (LLMs) are becoming central to modern applications, simply calling an API is no longer enough. We need structure, memory, workflows, and seamless integration with external tools and data sources. LangChain provides that missing layer.

By enabling prompt management, memory handling, Retrieval-Augmented Generation (RAG), and tool integration, LangChain transforms raw LLM capabilities into scalable, production-ready AI systems. Whether you’re building chatbots, AI agents, or data-driven assistants, LangChain helps bridge the gap between powerful models and practical real-world solutions.

In short, we use LangChain to smoothly connect with LLMs — and to turn intelligence into impact.

.NET + AI = The Perfect Combo

Shreyans Padmani — Sun, 08 Mar 2026 10:59:44 +0000

The combination of .NET and Artificial Intelligence creates a powerful foundation for building smart, scalable, and enterprise-ready applications. With the robust ecosystem of ASP.NET Core, developers can seamlessly integrate AI capabilities into web apps, APIs, and cloud solutions.

Using libraries like ML.NET, .NET developers can build, train, and deploy machine learning models directly within their applications — without switching platforms. Integration with cloud platforms such as Microsoft Azure AI further enhances scalability, security, and performance.

Why Choose .NET for AI Development

Cross-Platform & Cloud Friendly

Build once, deploy anywhere: Windows, Linux, Docker, Azure, AWS. Perfect for scalable AI solutions.

Performance & Reliability

.NET is fast and optimized. AI workloads combined with .NET APIs ensure great production performance.

Open Source & Community Support

Huge community, NuGet packages, GitHub Models — rich ecosystem for learning and implementation.

Secure & Enterprise Ready
.NET supports Identity, Dependency Injection, Logging, and Configuration — everything enterprises need for secure AI applications.

What are GitHub Models

GitHub provides pre-hosted AI models that you can use without setting up any GPU or server.

Ready-to-use models (GPT, Phi, LLaMA, etc.)
Runs via API — no infra setup
Great for prototyping AI apps

What is Microsoft.Extensions.AI

A new .NET library that helps developers easily plug AI models (like GitHub Models/OpenAI) directly into their applications with minimal code.

Helps integrate AI like a simple .NET service.
Works with GitHub Models, Azure OpenAI, etc.
Removes complexity of writing APIs manually
You can register AI models in Program.cs using AddAIClient, just like any other .NET service — making it clean and maintainable.

Conclusion

The fusion of .NET and AI empowers developers to build intelligent, scalable, and future-ready applications. By combining the stability of .NET with advanced AI capabilities, businesses can innovate faster, automate smarter, and deliver enhanced user experiences with confidence.

What is Agentic AI ?

Shreyans Padmani — Sun, 08 Mar 2026 10:54:38 +0000

Agentic AI refers to artificial intelligence systems that can act autonomously to achieve goals. Unlike traditional AI that simply responds to prompts, agentic AI can plan, make decisions, take actions, learn from feedback, and adapt to changing environments with minimal human intervention.

What is Agentic AI?

Agentic AI is the next evolution of artificial intelligence — where AI doesn’t just respond but actually acts.

It’s designed to think, decide, and execute tasks on its own, just like a digital assistant that understands goals and takes initiative to achieve them.

Agentic AI can:

Plan actions to reach an objective,
Use tools and APIs to perform real-world tasks,
Adapt using memory and feedback, and
Work continuously without constant human input.

How Agentic AI Works

Agentic AI works like a smart digital brain that can understand goals, plan actions, and execute them — all on its own.

Input Understanding

AI interprets user goals or queries and identifies what needs to be achieved.

Model Reasoning

AI interprets user goals or queries and identifies what needs to be achieved.

Action Execution

The AI performs real-world tasks by interacting with tools, APIs, or systems automatically.

Output Generation

Continuously improves its reasoning and performance through feedback and experience.

Conclusion

Agentic AI represents a powerful shift in artificial intelligence, moving from reactive systems to goal-driven, autonomous agents. By combining reasoning, planning, and adaptability, it enables smarter automation and more efficient problem-solving across industries.

ApiController in .NET

Shreyans Padmani — Sun, 08 Mar 2026 10:48:01 +0000

ApiController in ASP.NET Core is an attribute used for building RESTful web APIs. It enables automatic model validation, parameter binding, and standardized error responses, simplifying controller logic and improving API consistency, reliability, and developer productivity.

ApiController Attribute

The [ApiController] attribute in ASP.NET Core is used to indicate that a controller is intended to serve as an API endpoint.

It simplifies the development of RESTful APIs.

Attribute routing requirement
Automatic HTTP 400 responses
Binding source parameter inference
Problem details for error status codes

Example

Key Features of [ApiController]

1 . Attribute Routing Requirement

Applying the [ApiController] attribute enforces attribute routing. This means that actions within the controller will not be accessible via conventional routing methods (like UseEndpoints or UseMvcWithDefaultRoute). You must use the [Route] attribute on the controller or action methods.

2 .Default Bad Request Response (Problem Details)

The default response type for an HTTP 400 response is ValidationProblemDetails, which conforms to the RFC 7231 standard for problem details.

3 . Automatic HTTP 400 Responses

When model validation fails, the [ApiController] attribute automatically handles the response, returning an HTTP 400 Bad Request status.

4 . Binding Source Parameter Inference

The [ApiController] attribute automatically determines the source of certain action parameters, meaning you often don’t need to explicitly use binding attributes like [FromBody] or [FromQuery].

Conclusion

In conclusion, ApiController in ASP.NET Core streamlines API development by providing automatic validation, binding, and error handling. It reduces boilerplate code, enforces best practices, and enhances consistency, making it essential for building robust and maintainable web APIs.

Middleware Deep Drive in .NET

Shreyans Padmani — Sun, 08 Mar 2026 10:25:55 +0000

Middleware in .NET acts as a request pipeline component that handles logging, authentication, routing, and error handling. Each middleware processes HTTP requests and responses sequentially, enabling modular, reusable, and scalable application architecture within ASP.NET Core applications.

Code Snippet : app.Use(…)

Middleware is the backbone of ASP.NET Core request pipeline.

Executes in pipeline order
Can block, modify, or continue the request
Handles cross-cutting concerns like Logging, Auth, Exception Handling
Inline middleware is the simplest way to inject logic directly in Program.cs.
Use inline middleware for quick checks, lightweight logging, or debugging.

Why Middleware Order Matter

Sequential Request Flow: Middleware executes in the order added; order matters for dependencies.
Reverse Response Flow: Response passes through middleware in reverse order; placement affects response modification.
Short-Circuiting: Middleware like UseAuthentication can stop later middleware from running.
Security & Error Handling: UseExceptionHandler should be first; authentication must run before authorization.
Order impact middleware behavior. Authentication must be before Authorization.

Creating Custom Middleware

RequestDelegate Dependency: Middleware receives a RequestDelegate to invoke the next component.
InvokeAsync Method: Core logic resides in InvokeAsync(HttpContext context).
Short-Circuiting: Middleware can stop the pipeline by not calling await _next(context).
Passing Control: Call await _next(context) to continue to the next middleware.
Registration: Use app.UseMiddleware() to add it to the pipeline.

What Can Middleware Actually Do?

Logging and diagnostics: Middleware can run at the beginning of the pipeline to log request details (timing, path, user) and at the end to log response details (status code, duration).

Blocking suspicious IPs: It can inspect the source IP address of a request and immediately short-circuit the pipeline, preventing malicious or unwanted traffic from reaching the core application.

Injecting headers (e.g., CORS): Middleware is used to modify the HTTP response by adding or changing headers, such as setting CORS (Cross-Origin Resource Sharing) headers to allow external domains to access resources.

Authentication/Authorization:Authentication identifies the user (e.g., reads a token or cookie).Authorization checks if the identified user has permission to access the requested resource.

Request throttling: This involves limiting the number of requests a client can make over a certain period to prevent abuse or overload, often implemented by inspecting rate limits before passing the request further.

Error Handling: Early-registered middleware can catch exceptions thrown by all subsequent components and generate a formatted, user-friendly error response.

Conclusion

Middleware is the backbone of ASP.NET Core’s request pipeline, enabling clean architecture, flexibility, and scalability. By structuring components efficiently, developers can build secure, maintainable, and high-performance .NET applications tailored for modern, AI-integrated systems.

BigQuery vs Traditional Database

Shreyans Padmani — Sun, 08 Mar 2026 10:20:18 +0000

Google BigQuery is a serverless, scalable data warehouse built for analytics on massive datasets, while traditional databases like MySQL handle structured transactions efficiently. BigQuery excels in big data processing; traditional databases suit operational, real-time applications.

Difference Between BigQuery and Traditional Databases

What is BigQuery

BigQuery is a serverless cloud data warehouse by Google, designed for fast analytics and big data processing, capable of analyzing terabytes to petabytes of data in seconds.

1 . Serverless & Fully Managed

No need to manage servers or infrastructure.
Google automatically takes care of scaling, performance, and maintenance.

2 . Massive Scalability

No need to manage servers or infrastructure.
Google automatically takes care of scaling, performance, and maintenance.

3 . Blazing-Fast SQL Queries

Supports simple SQL syntax but runs queries super fast.
Uses a distributed system to process data in parallel.

4 . Cost-Effective (Pay-as-You-Go)

Pay only for the data you store and the queries you run.
No server setup cost or maintenance fees.

5 . Real-Time Analytics

Analyze live data streams in near real-time.
Great for dashboards, monitoring, and instant insights.

What is Traditional Databases

Traditional databases like MySQL, PostgreSQL, and Oracle are RDBMS designed for OLTP, handling day-to-day transactions and CRUD operations efficiently.

1 . Structured Data Storage

Stores data in tables with rows and columns using a fixed schema.
Best for organized and relational data.

2 . Self-Managed Infrastructure

Requires setting up and managing servers, backups, and scaling manually.
Needs regular maintenance and performance tuning.

3 . Optimized for Transactions

Great for CRUD operations (Create, Read, Update, Delete).
Handles real-time transactions like orders, payments, and logins.

4 . Limited Scalability

Works well with small to medium-sized data.
Scaling large data often requires more hardware and complex setups.

5 . Application-Focused Use Cases

Commonly used for web apps, user management, financial systems, and business operations.

Conclusion

Google BigQuery is a powerful, scalable, and serverless data warehouse designed for large-scale analytics. It simplifies big data processing, reduces infrastructure management, and delivers fast insights, making it ideal for modern business intelligence and data-driven decision making.

Stop using try-catch in every controller in C#

Shreyans Padmani — Sun, 08 Mar 2026 10:13:10 +0000

Stop using try-catch in every controller. Instead, use global exception handling and middleware to manage errors centrally. This keeps controllers clean, improves maintainability, ensures consistent responses, and follows best practices in modern web application architecture.

Problem: Try-Catch in Every Controller

Every controller duplicates the same try-catch block.
Controllers mix business logic, error handling, and logging.
Any change to error handling requires editing multiple controllers.
Different developers return different error formats or status codes.
You can’t isolate logic easily due to embedded exception handling.
Adding new exception types means rewriting every controller again.

Solution : Middleware Code(ExceptionMiddleware)

This middleware catches all unhandled exceptions in the request pipeline, so you don’t need to use try-catch in every controller.
It logs the error using ILogger, making debugging and monitoring easier.

Register the Middleware

Registers the custom middleware in the request pipeline so it runs on every request.
Ensures global exception handling by catching unhandled errors before they reach the response.

Benifits

You don’t need to write try-catch in every controller.
All errors are handled in one place, making the code clean and simple.
It gives the same type of error response every time.
Easy to find and fix problems because all exceptions are logged.
Makes the application more secure by not showing detailed error messages to users.
Improves maintenance since error handling logic is centralized.

Conclusion

In conclusion, avoid placing try-catch blocks in every controller. Use centralized exception handling to keep code clean, consistent, and maintainable while ensuring better error management and improved application architecture.

How Azure Works with .NET

Shreyans Padmani — Sun, 08 Mar 2026 10:01:16 +0000

Microsoft Azure works seamlessly with .NET by providing cloud services to build, deploy, and scale applications. Developers can host .NET apps using Microsoft Azure services like App Service, Azure SQL, and Azure Functions for secure, scalable, and high-performance solutions.

Why We Use Azure with .NET

When building .NET software, we need hosting, storage, security, and scalability. Azure, Microsoft’s cloud platform, provides all these seamlessly, making .NET apps easier to run and manage.

Perfect Integration

Azure is made by Microsoft, just like .NET, so they work perfectly together.
You get ready-to-use tools, templates, and SDKs that save time in development.

Easy Deployment & Hosting

You can deploy .NET apps directly to Azure without complicated setup.
Azure automatically handles servers, scaling, and updates, so your app runs smoothly.

Built-in Security and Management

Azure provides security features like authentication, encryption, and role management.
You can monitor, manage, and troubleshoot your .NET apps easily from the Azure portal.

Scalability and Performance

Azure can automatically scale your .NET apps to handle more users anytime.
You only pay for what you use, making it cost-efficient for growing apps.

Azure Services for .NET Developers

Hosting and Computing

Run your .NET apps on Azure’s cloud servers without managing physical hardware.
Use services like Azure App Service to deploy and scale apps automatically.

Database and Storage

Store your app data securely using Azure SQL Database or Blob Storage.
Easily manage backups and large datasets without worrying about server maintenance.

Security and Authentication

Protect your .NET apps with built-in Azure security and identity services.
Manage user access, encryption, and secure connections effortlessly.

Monitoring and Performance

Track your app’s health and performance with Azure Monitor and Application Insights.
Detect issues early and optimize your .NET app for faster, smoother operation.

Conclusion

In conclusion, .NET integrates smoothly with Microsoft Azure, enabling developers to build, deploy, and scale secure and high-performance applications in the cloud. This combination provides flexibility, reliability, and powerful tools for modern application development.

Self-Hosted Runner in Git-Hub Action

Shreyans Padmani — Sun, 08 Mar 2026 09:44:59 +0000

A Self-Hosted Runner in GitHub Actions is a machine that you manage and maintain to run your CI/CD workflows, instead of using GitHub’s hosted runners.

What Are Self-Hosted Runners

A self-hosted runner is your own machine configured to run GitHub Actions workflows.
Runs CI/CD workflows on your own server or VM, giving full control over performance, tools, and build environment.
Fully customizable environment with any OS, software, dependencies, or scripts pre-installed to meet specific workflow requirements.

Types of Runners in GitHub

GitHub-Hosted Runners — Pre-configured, auto-scaled, ready-to-use servers provided by GitHub.

Example: Ubuntu, Windows, macOS virtual environments.
Use case: Quick CI/CD setup, no maintenance needed.

Self-Hosted Runners — Your own machine that executes jobs.

Example: On-prem server, cloud VM (like AWS EC2, Azure VM), or even a Raspberry Pi.
Use case: Full control, custom tools, access to private networks.

How Self-Hosted Work in GitHub Actions

Runner Registration

You register your machine with a GitHub repository or organization.
GitHub provides a token and instructions to install the runner software.

Runner Setup

Install the runner software on your machine (Windows, Linux, or macOS).
The runner connects to GitHub and waits for jobs.

Workflow Trigger

When a GitHub Action workflow runs (like on push or pull_request), GitHub checks the runs-on field.
GitHub checks the workflow’s runs-on field. If it says self-hosted, it sends the job to your machine.

Job Execution

The runner downloads the workflow files, runs the jobs locally, and sends logs/results back to GitHub.

Result Reporting

GitHub shows build results (success/failure) in the Actions tab — just like with a GitHub-hosted runner.

Alternatives to Self-Hosted Runners

GitHub-Hosted Runners (Default Option)

Fully managed by GitHub
No setup, auto-scaled, but limited in customization
Good for small to medium workflows

Third-Party CI/CD Tools

Tools like Jenkins, GitLab CI, or CircleCI can integrate with GitHub and run pipelines on your own servers or cloud.
Gives similar control but outside GitHub Actions.

Self-Managed Cloud Infrastructure

Use Kubernetes, Docker Swarm, or custom CI runners to build a scalable CI/CD system.
More complex but highly flexible for enterprise needs.

Conclusion

A Self-Hosted Runner in GitHub Actions gives organizations complete control over their CI/CD execution environment. Unlike GitHub-hosted runners, self-hosted runners allow you to customize hardware, install specific tools, access private networks, and optimize performance based on project needs.

Stop Using AllowAnyOrigin()

Shreyans Padmani — Sun, 08 Feb 2026 08:11:10 +0000

AllowAnyOrigin() might look like a quick fix for CORS errors, but it silently opens the door to serious security risks.
Many developers use it without understanding how it exposes APIs to unwanted access.
In real-world applications, this single line can compromise data, authentication, and user trust.
Let’s understand why AllowAnyOrigin() is dangerous and what you should use instead.

Common Mistake – Using AllowAnyOrigin()

AllowAnyOrigin() allows any website to access your API, including malicious domains.
It exposes sensitive endpoints that were meant to be used only by your own frontend.
When combined with cookies or authentication headers, it increases the risk of CSRF attacks.
Developers often add it to fix CORS errors quickly and forget to remove it before production.
It breaks the principle of least privilege, allowing more access than necessary.
A single misconfiguration can lead to data leakage, abuse of APIs, and security breaches.

Example:

Safe Environment - Based Setup

Development Configuration (DevConfig)

Allow limited local origins like localhost only for faster development and testing.
Use relaxed CORS rules without exposing real production data.
Keep environment variables separate to avoid accidental production access.
Clearly mark this configuration as development-only.

Production Configuration (ProdConfig)

Allow only trusted domains (e.g., your official frontend URLs).
Never use AllowAnyOrigin() in production under any condition.
Enable stricter rules for headers, methods, and credentials.
Regularly review and update allowed origins as your application grows.

Middleware Placement –Important

CORS middleware must be registered before authentication and authorization to work correctly.
Incorrect placement can cause CORS headers to be missing, even if the configuration is correct.
Browsers may block requests if preflight (OPTIONS) requests are not handled properly.
Placing CORS too late in the pipeline leads to confusing errors that look like auth or API issues.
Proper middleware order ensures consistent behavior across all environments.

Conclusion

CORS configuration alone is not enough—where you place the middleware matters just as much. A secure and well-placed CORS setup prevents unnecessary errors, improves reliability, and ensures your API behaves exactly as expected in both development and production.