Browse Source

Merge branch 'dev' into issue-23871

pull/23910/head
Fahri Gedik 11 months ago
parent
commit
ebe5b27d75
  1. 255
      .github/scripts/add_seo_descriptions.py
  2. 210
      .github/workflows/auto-add-seo.yml
  3. 10
      Directory.Packages.props
  4. 41
      abp_io/AbpIoLocalization/AbpIoLocalization/Admin/Localization/Resources/en.json
  5. 18
      abp_io/AbpIoLocalization/AbpIoLocalization/Base/Localization/Resources/en.json
  6. 1
      abp_io/AbpIoLocalization/AbpIoLocalization/Www/Localization/Resources/en.json
  7. 20
      docs/en/Blog-Posts/2025-10-23-ABP-is-Sponsoring-DotNET-Conf-2025/post.md
  8. 660
      docs/en/Community-Articles/2025-10-07-Building-Scalable-Angular-Apps-with-Reusable-UI-Components/post.md
  9. 289
      docs/en/Community-Articles/2025-10-09-how-to-change-logo-in-angular-abp-apps/article.md
  10. BIN
      docs/en/Community-Articles/2025-10-10-Using-Transfer-State-with-Angular-SSR/cover.png
  11. 267
      docs/en/Community-Articles/2025-10-10-Using-Transfer-State-with-Angular-SSR/post.md
  12. 244
      docs/en/Community-Articles/2025-10-15-angular-library-linking-made-easy-paths-workspaces-and-symlinks/POST.md
  13. 88
      docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/POST.md
  14. BIN
      docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/all.png
  15. BIN
      docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/background.png
  16. BIN
      docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/cover-image.png
  17. BIN
      docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/database.png
  18. 27
      docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/dev-to.md
  19. BIN
      docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/logging.png
  20. BIN
      docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/shared.png
  21. BIN
      docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/stateless.png
  22. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/1.png
  23. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/10.png
  24. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/11.png
  25. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/11_1.png
  26. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/2.png
  27. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/3.png
  28. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/4.png
  29. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/5.png
  30. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/6.png
  31. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/7.png
  32. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/8.png
  33. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/9.png
  34. 251
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/Post.md
  35. 267
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/Post2.md
  36. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/cover-2.png
  37. BIN
      docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/cover.png
  38. 356
      docs/en/Community-Articles/2025-10-17-Top-10-Exception-Handling-Mistakes-in-DotNET/post.md
  39. 1174
      docs/en/Community-Articles/2025-10-20-The-ASP-DotNET-Core-Dependency-Injection System/post.md
  40. 102
      docs/en/Community-Articles/2025-10-20-Uncovering-ABP-Hidden-Magic/Post.md
  41. BIN
      docs/en/Community-Articles/2025-10-20-Uncovering-ABP-Hidden-Magic/cover-image.jpg
  42. 7
      docs/en/apps/volo-docs.md
  43. 7
      docs/en/cli/build-command.md
  44. 7
      docs/en/cli/differences-between-old-and-new-cli.md
  45. 30
      docs/en/cli/index.md
  46. 7
      docs/en/cli/new-command-samples.md
  47. 7
      docs/en/contribution/angular-ui.md
  48. 7
      docs/en/contribution/index.md
  49. 7
      docs/en/deployment/clustered-environment.md
  50. 7
      docs/en/deployment/configuring-openIddict.md
  51. 7
      docs/en/deployment/configuring-production.md
  52. 7
      docs/en/deployment/distributed-microservice.md
  53. 7
      docs/en/deployment/forwarded-headers.md
  54. 7
      docs/en/deployment/index.md
  55. 7
      docs/en/deployment/optimizing-production.md
  56. 7
      docs/en/deployment/ssl.md
  57. 8
      docs/en/docs-nav.json
  58. 7
      docs/en/framework/api-development/auto-controllers.md
  59. 7
      docs/en/framework/api-development/dynamic-csharp-clients.md
  60. 7
      docs/en/framework/api-development/index.md
  61. 7
      docs/en/framework/api-development/integration-services.md
  62. 7
      docs/en/framework/api-development/standard-apis/configuration.md
  63. 7
      docs/en/framework/api-development/standard-apis/index.md
  64. 7
      docs/en/framework/api-development/standard-apis/localization.md
  65. 7
      docs/en/framework/api-development/static-csharp-clients.md
  66. 7
      docs/en/framework/api-development/swagger.md
  67. 7
      docs/en/framework/api-development/versioning.md
  68. 7
      docs/en/framework/architecture/best-practices/application-layer-overview.md
  69. 7
      docs/en/framework/architecture/best-practices/application-services.md
  70. 7
      docs/en/framework/architecture/best-practices/data-access-overview.md
  71. 7
      docs/en/framework/architecture/best-practices/data-transfer-objects.md
  72. 7
      docs/en/framework/architecture/best-practices/domain-layer-overview.md
  73. 7
      docs/en/framework/architecture/best-practices/domain-services.md
  74. 7
      docs/en/framework/architecture/best-practices/entities.md
  75. 7
      docs/en/framework/architecture/best-practices/entity-framework-core-integration.md
  76. 7
      docs/en/framework/architecture/best-practices/index.md
  77. 7
      docs/en/framework/architecture/best-practices/module-architecture.md
  78. 7
      docs/en/framework/architecture/best-practices/mongodb-integration.md
  79. 7
      docs/en/framework/architecture/best-practices/repositories.md
  80. 7
      docs/en/framework/architecture/domain-driven-design/application-layer.md
  81. 7
      docs/en/framework/architecture/domain-driven-design/application-services.md
  82. 7
      docs/en/framework/architecture/domain-driven-design/data-transfer-objects.md
  83. 7
      docs/en/framework/architecture/domain-driven-design/domain-layer.md
  84. 7
      docs/en/framework/architecture/domain-driven-design/domain-services.md
  85. 7
      docs/en/framework/architecture/domain-driven-design/entities.md
  86. 7
      docs/en/framework/architecture/domain-driven-design/index.md
  87. 7
      docs/en/framework/architecture/domain-driven-design/repositories.md
  88. 7
      docs/en/framework/architecture/domain-driven-design/specifications.md
  89. 7
      docs/en/framework/architecture/domain-driven-design/unit-of-work.md
  90. 7
      docs/en/framework/architecture/domain-driven-design/value-objects.md
  91. 7
      docs/en/framework/architecture/index.md
  92. 7
      docs/en/framework/architecture/microservices/index.md
  93. 7
      docs/en/framework/architecture/modularity/basics.md
  94. 7
      docs/en/framework/architecture/modularity/extending/customizing-application-modules-extending-entities.md
  95. 7
      docs/en/framework/architecture/modularity/extending/customizing-application-modules-guide.md
  96. 7
      docs/en/framework/architecture/modularity/extending/customizing-application-modules-overriding-services.md
  97. 7
      docs/en/framework/architecture/modularity/extending/module-entity-extensions.md
  98. 7
      docs/en/framework/architecture/modularity/extending/overriding-user-interface.md
  99. 7
      docs/en/framework/architecture/modularity/plugin-modules.md
  100. 7
      docs/en/framework/architecture/multi-tenancy/index.md

255
.github/scripts/add_seo_descriptions.py

@ -0,0 +1,255 @@
import os
import sys
import re
import json
from openai import OpenAI
client = OpenAI(api_key=os.environ['OPENAI_API_KEY'])
# Regex patterns as constants
SEO_BLOCK_PATTERN = r'```+json\s*//\[doc-seo\]\s*(\{.*?\})\s*```+'
SEO_BLOCK_WITH_BACKTICKS_PATTERN = r'(```+)json\s*//\[doc-seo\]\s*(\{.*?\})\s*\1'
def has_seo_description(content):
"""Check if content already has SEO description with Description field"""
match = re.search(SEO_BLOCK_PATTERN, content, flags=re.DOTALL)
if not match:
return False
try:
json_str = match.group(1)
seo_data = json.loads(json_str)
return 'Description' in seo_data and seo_data['Description']
except json.JSONDecodeError:
return False
def has_seo_block(content):
"""Check if content has any SEO block (with or without Description)"""
return bool(re.search(SEO_BLOCK_PATTERN, content, flags=re.DOTALL))
def remove_seo_blocks(content):
"""Remove all SEO description blocks from content"""
return re.sub(SEO_BLOCK_PATTERN + r'\s*', '', content, flags=re.DOTALL)
def is_content_too_short(content, min_length=200):
"""Check if content is less than minimum length (excluding SEO blocks)"""
clean_content = remove_seo_blocks(content)
return len(clean_content.strip()) < min_length
def get_content_preview(content, max_length=1000):
"""Get preview of content for OpenAI (excluding SEO blocks)"""
clean_content = remove_seo_blocks(content)
return clean_content[:max_length].strip()
def escape_json_string(text):
"""Escape special characters for JSON"""
return text.replace('\\', '\\\\').replace('"', '\\"').replace('\n', '\\n')
def create_seo_block(description):
"""Create a new SEO block with the given description"""
escaped_desc = escape_json_string(description)
return f'''```json
//[doc-seo]
{{
"Description": "{escaped_desc}"
}}
```
'''
def generate_description(content, filename):
"""Generate SEO description using OpenAI"""
try:
preview = get_content_preview(content)
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": """Create a short and engaging summary (1–2 sentences) for sharing this documentation link on Discord, LinkedIn, Reddit, Twitter and Facebook. Clearly describe what the page explains or teaches.
Highlight the value for developers using ABP Framework.
Be written in a friendly and professional tone.
Stay under 150 characters.
--> https://abp.io/docs/latest <--"""},
{"role": "user", "content": f"""Generate a concise, informative meta description for this documentation page.
File: {filename}
Content Preview:
{preview}
Requirements:
- Maximum 150 characters
Generate only the description text, nothing else:"""}
],
max_tokens=150,
temperature=0.7
)
description = response.choices[0].message.content.strip()
return description
except Exception as e:
print(f"❌ Error generating description: {e}")
return f"Learn about {os.path.splitext(filename)[0]} in ABP Framework documentation."
def update_seo_description(content, description):
"""Update existing SEO block with new description"""
match = re.search(SEO_BLOCK_WITH_BACKTICKS_PATTERN, content, flags=re.DOTALL)
if not match:
return None
backticks = match.group(1)
json_str = match.group(2)
try:
seo_data = json.loads(json_str)
seo_data['Description'] = description
updated_json = json.dumps(seo_data, indent=4, ensure_ascii=False)
new_block = f'''{backticks}json
//[doc-seo]
{updated_json}
{backticks}'''
return re.sub(SEO_BLOCK_WITH_BACKTICKS_PATTERN, new_block, content, count=1, flags=re.DOTALL)
except json.JSONDecodeError:
return None
def add_seo_description(content, description):
"""Add or update SEO description in content"""
# Try to update existing block first
updated_content = update_seo_description(content, description)
if updated_content:
return updated_content
# No existing block or update failed, add new block at the beginning
return create_seo_block(description) + content
def is_file_ignored(filepath, ignored_folders):
"""Check if file is in an ignored folder"""
path_parts = filepath.split('/')
return any(ignored in path_parts for ignored in ignored_folders)
def get_changed_files():
"""Get changed files from command line or environment variable"""
if len(sys.argv) > 1:
return sys.argv[1:]
changed_files_str = os.environ.get('CHANGED_FILES', '')
return [f.strip() for f in changed_files_str.strip().split('\n') if f.strip()]
def process_file(filepath, ignored_folders):
"""Process a single markdown file. Returns (processed, skipped, skip_reason)"""
if not filepath.endswith('.md'):
return False, False, None
# Check if file is in ignored folder
if is_file_ignored(filepath, ignored_folders):
print(f"📄 Processing: {filepath}")
print(f" 🚫 Skipped (ignored folder)\n")
return False, True, 'ignored'
print(f"📄 Processing: {filepath}")
try:
# Read file with original line endings
with open(filepath, 'r', encoding='utf-8', newline='') as f:
content = f.read()
# Check if content is too short
if is_content_too_short(content):
print(f" ⏭️ Skipped (content less than 200 characters)\n")
return False, True, 'too_short'
# Check if already has SEO description
if has_seo_description(content):
print(f" ⏭️ Skipped (already has SEO description)\n")
return False, True, 'has_description'
# Generate description
filename = os.path.basename(filepath)
print(f" 🤖 Generating description...")
description = generate_description(content, filename)
print(f" 💡 Generated: {description}")
# Add or update SEO description
if has_seo_block(content):
print(f" 🔄 Updating existing SEO block...")
else:
print(f" ➕ Adding new SEO block...")
updated_content = add_seo_description(content, description)
# Write back (preserving line endings)
with open(filepath, 'w', encoding='utf-8', newline='') as f:
f.write(updated_content)
print(f" ✅ Updated successfully\n")
return True, False, None
except Exception as e:
print(f" ❌ Error: {e}\n")
return False, False, None
def save_statistics(processed_count, skipped_count, skipped_too_short, skipped_ignored):
"""Save processing statistics to file"""
try:
with open('/tmp/seo_stats.txt', 'w') as f:
f.write(f"{processed_count}\n{skipped_count}\n{skipped_too_short}\n{skipped_ignored}")
except Exception as e:
print(f"⚠️ Warning: Could not save statistics: {e}")
def save_updated_files(updated_files):
"""Save list of updated files"""
try:
with open('/tmp/seo_updated_files.txt', 'w') as f:
f.write('\n'.join(updated_files))
except Exception as e:
print(f"⚠️ Warning: Could not save updated files list: {e}")
def main():
# Get ignored folders from environment
IGNORED_FOLDERS_STR = os.environ.get('IGNORED_FOLDERS', 'Blog-Posts,Community-Articles,_deleted,_resources')
IGNORED_FOLDERS = [folder.strip() for folder in IGNORED_FOLDERS_STR.split(',') if folder.strip()]
# Get changed files
changed_files = get_changed_files()
# Statistics
processed_count = 0
skipped_count = 0
skipped_too_short = 0
skipped_ignored = 0
updated_files = []
print("🤖 Processing changed markdown files...\n")
print(f"� Ignored folders: {', '.join(IGNORED_FOLDERS)}\n")
# Process each file
for filepath in changed_files:
processed, skipped, skip_reason = process_file(filepath, IGNORED_FOLDERS)
if processed:
processed_count += 1
updated_files.append(filepath)
elif skipped:
skipped_count += 1
if skip_reason == 'too_short':
skipped_too_short += 1
elif skip_reason == 'ignored':
skipped_ignored += 1
# Print summary
print(f"\n📊 Summary:")
print(f" ✅ Updated: {processed_count}")
print(f" ⏭️ Skipped (total): {skipped_count}")
print(f" ⏭️ Skipped (too short): {skipped_too_short}")
print(f" 🚫 Skipped (ignored folder): {skipped_ignored}")
# Save statistics
save_statistics(processed_count, skipped_count, skipped_too_short, skipped_ignored)
save_updated_files(updated_files)
if __name__ == '__main__':
main()

210
.github/workflows/auto-add-seo.yml

@ -0,0 +1,210 @@
name: Auto Add SEO Descriptions
on:
pull_request:
paths:
- 'docs/en/**/*.md'
branches:
- 'rel-*'
- 'dev'
types: [closed]
jobs:
add-seo-descriptions:
if: |
github.event.pull_request.merged == true &&
!startsWith(github.event.pull_request.head.ref, 'auto-docs-seo/')
runs-on: ubuntu-latest
permissions:
contents: write
pull-requests: write
steps:
- name: Checkout code
uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.base.ref }}
fetch-depth: 0
token: ${{ secrets.GITHUB_TOKEN }}
- name: Setup Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Install dependencies
run: |
pip install openai
- name: Get changed markdown files from merged PR using GitHub API
id: changed-files
uses: actions/github-script@v7
with:
script: |
const prNumber = ${{ github.event.pull_request.number }};
// Get all files changed in the PR with pagination
const allFiles = [];
let page = 1;
let hasMore = true;
while (hasMore) {
const { data: files } = await github.rest.pulls.listFiles({
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: prNumber,
per_page: 100,
page: page
});
allFiles.push(...files);
hasMore = files.length === 100;
page++;
}
console.log(`Total files changed in PR: ${allFiles.length}`);
// Filter for only added/modified markdown files in docs/en/
const changedMdFiles = allFiles
.filter(file =>
(file.status === 'added' || file.status === 'modified') &&
file.filename.startsWith('docs/en/') &&
file.filename.endsWith('.md')
)
.map(file => file.filename);
console.log(`\nFound ${changedMdFiles.length} added/modified markdown files in docs/en/:`);
changedMdFiles.forEach(file => console.log(` - ${file}`));
// Write to environment file for next steps
const fs = require('fs');
fs.writeFileSync(process.env.GITHUB_OUTPUT,
`any_changed=${changedMdFiles.length > 0 ? 'true' : 'false'}\n` +
`all_changed_files=${changedMdFiles.join(' ')}\n`,
{ flag: 'a' }
);
return changedMdFiles;
- name: Create new branch for SEO updates
if: steps.changed-files.outputs.any_changed == 'true'
run: |
git config --local user.email "github-actions[bot]@users.noreply.github.com"
git config --local user.name "github-actions[bot]"
# Create new branch from current base branch (which already has merged files)
BRANCH_NAME="auto-docs-seo/${{ github.event.pull_request.number }}"
git checkout -b $BRANCH_NAME
echo "BRANCH_NAME=$BRANCH_NAME" >> $GITHUB_ENV
echo "✅ Created branch: $BRANCH_NAME"
echo ""
echo "📝 Files to process for SEO descriptions:"
for file in ${{ steps.changed-files.outputs.all_changed_files }}; do
if [ -f "$file" ]; then
echo " ✓ $file"
else
echo " ✗ $file (not found)"
fi
done
- name: Process changed files and add SEO descriptions
if: steps.changed-files.outputs.any_changed == 'true'
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
IGNORED_FOLDERS: ${{ vars.DOCS_SEO_IGNORED_FOLDERS }}
CHANGED_FILES: ${{ steps.changed-files.outputs.all_changed_files }}
run: |
python3 .github/scripts/add_seo_descriptions.py
- name: Commit and push changes
if: steps.changed-files.outputs.any_changed == 'true'
run: |
git add -A docs/en/
if git diff --staged --quiet; then
echo "No changes to commit"
echo "has_commits=false" >> $GITHUB_ENV
else
BRANCH_NAME="auto-docs-seo/${{ github.event.pull_request.number }}"
git commit -m "docs: Add SEO descriptions to modified documentation files" -m "Related to PR #${{ github.event.pull_request.number }}"
git push origin $BRANCH_NAME
echo "has_commits=true" >> $GITHUB_ENV
echo "BRANCH_NAME=$BRANCH_NAME" >> $GITHUB_ENV
fi
- name: Create Pull Request
if: env.has_commits == 'true'
uses: actions/github-script@v7
with:
script: |
const fs = require('fs');
const stats = fs.readFileSync('/tmp/seo_stats.txt', 'utf8').split('\n');
const processedCount = parseInt(stats[0]) || 0;
const skippedCount = parseInt(stats[1]) || 0;
const skippedTooShort = parseInt(stats[2]) || 0;
const skippedIgnored = parseInt(stats[3]) || 0;
const prNumber = ${{ github.event.pull_request.number }};
const baseRef = '${{ github.event.pull_request.base.ref }}';
const branchName = `auto-docs-seo/${prNumber}`;
if (processedCount > 0) {
// Read the actually updated files list (not all changed files)
const updatedFilesStr = fs.readFileSync('/tmp/seo_updated_files.txt', 'utf8');
const updatedFiles = updatedFilesStr.trim().split('\n').filter(f => f.trim());
let prBody = '🤖 **Automated SEO Descriptions**\n\n';
prBody += `This PR automatically adds SEO descriptions to documentation files that were modified in PR #${prNumber}.\n\n`;
prBody += '## 📊 Summary\n';
prBody += `- ✅ **Updated:** ${processedCount} file(s)\n`;
prBody += `- ⏭️ **Skipped (total):** ${skippedCount} file(s)\n`;
if (skippedTooShort > 0) {
prBody += ` - ⏭️ Content < 200 chars: ${skippedTooShort} file(s)\n`;
}
if (skippedIgnored > 0) {
prBody += ` - 🚫 Ignored folders: ${skippedIgnored} file(s)\n`;
}
prBody += '\n## 📝 Modified Files\n';
prBody += updatedFiles.slice(0, 20).map(f => `- \`${f}\``).join('\n');
if (updatedFiles.length > 20) {
prBody += `\n- ... and ${updatedFiles.length - 20} more`;
}
prBody += '\n\n## 🔧 Details\n';
prBody += `- **Related PR:** #${prNumber}\n\n`;
prBody += 'These descriptions were automatically generated to improve SEO and search engine visibility. 🚀';
const { data: pr } = await github.rest.pulls.create({
owner: context.repo.owner,
repo: context.repo.repo,
title: `docs: Add SEO descriptions (from PR ${prNumber})`,
head: branchName,
base: baseRef,
body: prBody
});
console.log(`✅ Created PR: ${pr.html_url}`);
// Add reviewers to the PR (from GitHub variable)
const reviewersStr = '${{ vars.DOCS_SEO_REVIEWERS || '' }}';
const reviewers = reviewersStr.split(',').map(r => r.trim()).filter(r => r);
if (reviewers.length === 0) {
console.log('⚠️ No reviewers specified in DOCS_SEO_REVIEWERS variable.');
return;
}
try {
await github.rest.pulls.requestReviewers({
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: pr.number,
reviewers: reviewers,
team_reviewers: []
});
console.log(`✅ Added reviewers (${reviewers.join(', ')}) to PR ${pr.number}`);
} catch (error) {
console.log(`⚠️ Could not add reviewers: ${error.message}`);
}
}

10
Directory.Packages.props

@ -19,10 +19,10 @@
<PackageVersion Include="BunnyCDN.Net.Storage" Version="1.0.4" />
<PackageVersion Include="Azure.Messaging.ServiceBus" Version="7.20.1" />
<PackageVersion Include="Azure.Storage.Blobs" Version="12.25.0" />
<PackageVersion Include="Blazorise" Version="1.8.3" />
<PackageVersion Include="Blazorise.Components" Version="1.8.3" />
<PackageVersion Include="Blazorise.DataGrid" Version="1.8.3" />
<PackageVersion Include="Blazorise.Snackbar" Version="1.8.3" />
<PackageVersion Include="Blazorise" Version="1.8.5" />
<PackageVersion Include="Blazorise.Components" Version="1.8.5" />
<PackageVersion Include="Blazorise.DataGrid" Version="1.8.5" />
<PackageVersion Include="Blazorise.Snackbar" Version="1.8.5" />
<PackageVersion Include="Castle.Core" Version="5.2.1" />
<PackageVersion Include="Castle.Core.AsyncInterceptor" Version="2.1.0" />
<PackageVersion Include="CommonMark.NET" Version="0.15.1" />
@ -149,7 +149,7 @@
<PackageVersion Include="RabbitMQ.Client" Version="7.1.2" />
<PackageVersion Include="Rebus" Version="8.8.0" />
<PackageVersion Include="Rebus.ServiceProvider" Version="10.5.0" />
<PackageVersion Include="Riok.Mapperly" Version="4.2.1" />
<PackageVersion Include="Riok.Mapperly" Version="4.3.0" />
<PackageVersion Include="Scriban" Version="6.3.0" />
<PackageVersion Include="Serilog" Version="4.3.0" />
<PackageVersion Include="Serilog.AspNetCore" Version="9.0.0" />

41
abp_io/AbpIoLocalization/AbpIoLocalization/Admin/Localization/Resources/en.json

@ -729,35 +729,36 @@
"Enum:LicenseType:2": "Team",
"Enum:LicenseType:3": "Business",
"Enum:LicenseType:4": "Enterprise",
"Enum:Template:0": "Unknown",
"Enum:Template:1": "App No Layers",
"Enum:Template:2": "App Layered",
"Enum:Template:3": "Microservice",
"Enum:SolutionTemplate:0": "Unknown",
"Enum:SolutionTemplate:1": "App No Layers",
"Enum:SolutionTemplate:2": "App Layered",
"Enum:SolutionTemplate:3": "Microservice",
"Enum:UiFramework:0": "Unknown",
"Enum:UiFramework:1": "None",
"Enum:UiFramework:2": "Mvc Razor Pages",
"Enum:UiFramework:2": "MVC Razor Pages",
"Enum:UiFramework:3": "Angular",
"Enum:UiFramework:4": "Blazor Wasm",
"Enum:UiFramework:4": "Blazor WASM",
"Enum:UiFramework:5": "Blazor Server",
"Enum:UiFramework:6": "Blazor Web App",
"Enum:UiFramework:7": "Blazor MaUI",
"Enum:UiFramework:6": "Blazor WebApp",
"Enum:UiFramework:7": "Blazor MAUI",
"Enum:DatabaseProvider:0": "Unknown",
"Enum:DatabaseProvider:1": "None",
"Enum:DatabaseProvider:2": "EfCore",
"Enum:DatabaseProvider:3": "MongoDb",
"Enum:DatabaseProvider:3": "MongoDB",
"Enum:Dbms:0": "Unknown",
"Enum:Dbms:1": "None",
"Enum:Dbms:2": "SqlServer",
"Enum:Dbms:3": "PostgreSql",
"Enum:Dbms:2": "SQL Server",
"Enum:Dbms:3": "PostgreSQL",
"Enum:Dbms:4": "Oracle",
"Enum:Dbms:5": "OracleDevart",
"Enum:Dbms:6": "MySql",
"Enum:Dbms:7": "Sqlite",
"Enum:Dbms:5": "Oracle Devart",
"Enum:Dbms:6": "MySQL",
"Enum:Dbms:7": "SQLite",
"Enum:UiTheme:0": "Unknown",
"Enum:UiTheme:1": "None",
"Enum:UiTheme:2": "Basic",
"Enum:UiTheme:3": "LeptonX",
"Enum:UiTheme:4": "LeptonX Lite",
"Enum:UiTheme:5": "Lepton",
"Enum:UiThemeStyle:0": "Unknown",
"Enum:UiThemeStyle:1": "System",
"Enum:UiThemeStyle:2": "Dim",
@ -765,12 +766,12 @@
"Enum:UiThemeStyle:4": "Light",
"Enum:MobileApp:0": "Unknown",
"Enum:MobileApp:1": "None",
"Enum:MobileApp:2": "Maui",
"Enum:MobileApp:3": "ReactNative",
"Enum:CreationTool:0": "Unknown",
"Enum:CreationTool:1": "StudioUI",
"Enum:CreationTool:2": "StudioCli",
"Enum:CreationTool:3": "OldCli",
"Enum:MobileApp:2": "MAUI",
"Enum:MobileApp:3": "React Native",
"Enum:AbpTool:0": "Unknown",
"Enum:AbpTool:1": "Studio UI",
"Enum:AbpTool:2": "Studio CLI",
"Enum:AbpTool:3": "Old CLI",
"Menu:TelemetryMenu": "Telemetry Reports",
"Menu:Studio": "Studio",
"Menu:Solutions": "Solutions",

18
abp_io/AbpIoLocalization/AbpIoLocalization/Base/Localization/Resources/en.json

@ -228,7 +228,9 @@
"Articles": "Articles",
"Organizations": "Organizations",
"ManageAccount": "Manage Account",
"MyManageAccount": "My Account",
"CommunityProfile": "Community Profile",
"MyCommunityProfile": "My Community Profile",
"BlogProfile": "Blog Profile",
"Tickets": "Tickets",
"Raffles": "Raffles",
@ -248,11 +250,25 @@
"NewsletterDefinition": "Blog posts, community news, etc.",
"OrganizationOverview": "Organization Overview",
"EmailPreferences": "Email Preferences",
"MyEmailPreferences": "My Email Preferences",
"VideoCourses": "Essential Videos",
"DoYouAgreePrivacyPolicy": "By clicking <b>Subscribe</b> button you agree to the <a href=\"/terms-conditions\">Terms & Conditions</a> and <a href=\"/privacy\">Privacy Policy</a>.",
"AbpConferenceDescription": "ABP Conference is a virtual event for .NET developers to learn and connect with the community.",
"Mobile": "Mobile",
"MetaTwitterCard": "summary_large_image",
"IPAddress": "IP Address"
"IPAddress": "IP Address",
"MyReferrals": "My Referrals",
"LicenseBanner:InfoText": "Your license will <b>expire in {0} days.</b>",
"LicenseBanner:CallToAction": "Please <a href=\"/my-organizations/{0}\" class=\"text-decoration-underline\">extend your license.</a>",
"Referral.CreatorUserIdIsRequired": "Creator user ID is required.",
"Referral.TargetEmailIsRequired": "Target email is required.",
"Referral.TargetEmailAlreadyExists": "A referral link for this email address already exists.",
"Referral.MaxLinkLimitExceeded": "You have reached the maximum limit of {Limit} active referral links.",
"Referral.LinkNotFound": "Referral link not found.",
"Referral.LinkNotFoundOrNotOwned": "Referral link not found or you don't have permission to access it.",
"Referral.CannotDeleteUsedLink": "You cannot delete a referral link that has already been used.",
"LinkCopiedToClipboard": "Link copied to clipboard",
"AreYouSureToDeleteReferralLink": "Are you sure you want to delete this referral link?",
"DefaultErrorMessage": "An error occurred."
}
}

1
abp_io/AbpIoLocalization/AbpIoLocalization/Www/Localization/Resources/en.json

@ -616,6 +616,7 @@
"QuestionItemErrorMessage": "Could not get the latest question details from Stackoverflow.",
"Oops": "Oops!",
"CreatePostSuccessMessage": "The Post has been successfully submitted. It will be published after a review from the site admin.",
"PostCreationFailed": "An error occurred while creating the post. Please try again later.",
"Browse": "Browse",
"CoverImage": "Cover Image",
"ShareYourExperiencesWithTheABPFramework": "ABP Community Articles | Read or Submit Articles",

20
docs/en/Blog-Posts/2025-10-23-ABP-is-Sponsoring-DotNET-Conf-2025/post.md

@ -0,0 +1,20 @@
### ABP is Sponsoring .NET Conf 2025\!
We are very excited to announce that **ABP is a proud sponsor of .NET Conf 2025\!** This year marks the 15th online conference, celebrating the launch of .NET 10 and bringing together the global .NET community for three days\!
Mark your calendar for **November 11th-13th** because you do not want to miss the biggest .NET virtual event of the year\!
### About .NET Conf
.NET Conference has always been **a free, virtual event, creating a world-class, engaging experience for developers** across the globe. This year, the conference is bigger than ever, drawing over 100 thousand live viewers and sponsoring hundreds of local community events worldwide\!
### What to Expect
**The .NET 10 Launch:** The event kicks off with the official release and deep-dive into the newest features of .NET 10\.
**Three Days of Live Content:** Over the course of the event you'll get a wide selection of live sessions featuring speakers from the community and members of the .NET team.
### Chance to Win a License\!
As a proud sponsor, ABP is giving back to the community\! We are giving away one **ABP Personal License for a full year** to a lucky attendee of .NET Conf 2025\! To enter for a chance to win, simply register for the event [**here.**](https://www.dotnetconf.net/)

660
docs/en/Community-Articles/2025-10-07-Building-Scalable-Angular-Apps-with-Reusable-UI-Components/post.md

@ -0,0 +1,660 @@
# Building Scalable Angular Apps with Reusable UI Components
Frontend development keeps evolving at an incredible pace, and with every new update, our implementation standards improve as well. But even as tools and frameworks change, the core principles stay the same, and one of the most important is reusability.
Reusability means building components and utilities that can be used in multiple places instead of using the same logic repeatedly. This approach not only saves time but also keeps your code clean, consistent, and easier to maintain as your project grows.
Angular fully embraces this idea by offering modern features like **standalone components**, **signals**, **hybrid rendering**, and **component-level lazy loading**.
In this article, we will explore how these features make it easier to build reusable UI components. We will also look at how to style them and organize them into shared libraries for scalable, long-term development.
---
## 🧩 Breaking Down Components for True Reusability
The first approach to make an Angular component reusable is to use standalone components. As this feature has been supported for a long time, it is now the default behavior for the latest Angular versions. Keeping that in mind, we can ensure reusability by separating a big component into smaller ones to make the small pieces usable across the application.
Here is a quick example:
Imagine you start with a single `UserProfileComponent` that does everything including displaying user info, recent posts, a list of friends, and even handling profile editing.
```ts
// 📖 Compact user profile component
import { Component } from "@angular/core";
@Component({
selector: "app-user-profile",
template: `
<section class="profile">
<div class="header">
<img [src]="user.avatar" alt="User avatar" />
<h2>{{ user.name }}</h2>
<button (click)="editProfile()">Edit</button>
</div>
<div class="posts">
<h3>Recent Posts</h3>
<ul>
@for (post of user.posts; track post) {
<li>{{ post }}</li>
}
</ul>
</div>
<div class="friends">
<h3>Friends</h3>
<ul>
@for (friend of user.friends; track friend) {
<li>{{ friend }}</li>
}
</ul>
</div>
</section>
`,
})
export class UserProfileComponent {
user = {
name: "Jane Doe",
avatar: "/assets/avatar.png",
posts: ["Angular Tips", "Reusable Components FTW!"],
friends: ["John", "Mary", "Steve"],
};
editProfile() {
console.log("Editing profile...");
}
}
```
Instead of this, you can create small components like these:
- `user-avatar.component.ts`
- `user-posts.component.ts`
- `user-friends.component.ts`
```ts
// 🧩 user-avatar.component.ts
import { Component, input } from "@angular/core";
@Component({
selector: "app-user-avatar",
template: `
<div class="user-avatar">
<img [src]="avatar()" alt="User avatar" />
<h2>{{ name() }}</h2>
</div>
`,
})
export class UserAvatarComponent {
name = input.required<string>();
avatar = input.required<string>();
}
```
```ts
// 🧩 user-posts.component.ts
import { Component, input } from "@angular/core";
@Component({
selector: "app-user-posts",
template: `
<div class="user-posts">
<h3>Recent Posts</h3>
<ul>
@for (post of posts(); track post) {
<li>{{ post }}</li>
}
</ul>
</div>
`,
})
export class UserPostsComponent {
posts = input<string[]>([]);
}
```
```ts
// 🧩 user-friends.component.ts
import { Component, input, output } from "@angular/core";
@Component({
selector: "app-user-friends",
template: `
<div class="user-friends">
<h3>Friends</h3>
<ul>
@for (friend of friends(); track friend) {
<li (click)="selectFriend(friend)">{{ friend }}</li>
}
</ul>
</div>
`,
})
export class UserFriendsComponent {
friends = input<string[]>([]);
friendSelected = output<string>();
selectFriend(friend: string) {
this.friendSelected.emit(friend);
}
}
```
Then, you can use them in a container component like this
```ts
// 🧩 new user profile components that uses other user components
import { Component } from "@angular/core";
import { signal } from "@angular/core";
import { UserAvatarComponent } from "./user-avatar.component";
import { UserPostsComponent } from "./user-posts.component";
import { UserFriendsComponent } from "./user-friends.component";
@Component({
selector: "app-user-profile",
imports: [UserAvatarComponent, UserPostsComponent, UserFriendsComponent],
template: `
<section class="profile">
<app-user-avatar [name]="user().name" [avatar]="user().avatar" />
<app-user-posts [posts]="user().posts" />
<app-user-friends
[friends]="user().friends"
(friendSelected)="onFriendSelected($event)"
/>
</section>
`,
})
export class UserProfileComponent {
user = signal({
name: "Jane Doe",
avatar: "/assets/avatar.png",
posts: ["Angular Tips", "Reusable Components FTW!"],
friends: ["John", "Mary", "Steve"],
});
onFriendSelected(friend: string) {
console.log(`Selected friend: ${friend}`);
}
}
```
The most common problem of creating such components is over-creating new elements when you actually do not need them. So, it is a design decision that needs to be carefully taken while building the application. If misused, it can lead to:
- a management nightmare
- unnecessary lifecycle hook complexity
- extra indirect data flow (makes debugging harder)
Nevertheless, this makes the app more scalable and maintainable if correctly used. Such structure will provide:
- a clear separation of concerns as each component will maintain decided tasks
- faster feature development
- shared libraries or elements across the application
---
## 🚀 Why Standalone Components Matter
As Angular has announced standalone components starting from version 17, they have been gradually developing features that support reusability. This important feature brings a great migration for components, directives, and pipes.
Since it allows these elements to be used directly inside an `imports` array rather than through a module structure, it reinforces reusability patterns and simplifies management.
Back in the module-based structure, we used to create these components and declare them in modules. This still offers some reusability, as we can import the modules where needed. However, standalone components can be consumed both by other standalone components and modules. For this reason, migrating from the module-based structure to a fully standalone architecture brings many benefits for this concern.
---
## 🧠 Designing Components That Scale and Reuse Well
The first point you need to consider here is to encapsulate and isolate logic.
For example:
1. This counter component isolates the concept of incrementing/decrementing so the parent component will not take care of this logic except showing the result.
```ts
import { Component, signal } from "@angular/core";
@Component({
selector: "app-counter",
template: `
<button (click)="decrement()">-</button>
<span>{{ count() }}</span>
<button (click)="increment()">+</button>
`,
})
export class CounterComponent {
private count = signal(0); // internal state
increment() {
this.count.update((v) => v + 1);
}
decrement() {
this.count.update((v) => v - 1);
}
}
```
2. This component isolates the styles and makes the badge reusable. Styles in this component will not leak out to others, and global styles will not affect it.
```ts
import { Component, ViewEncapsulation } from "@angular/core";
@Component({
selector: "app-badge",
template: `<span class="badge">{{ label }}</span>`,
styles: [
`
.badge {
background: #007bff;
color: white;
padding: 4px 8px;
border-radius: 4px;
}
`,
],
encapsulation: ViewEncapsulation.Emulated, // default; isolates CSS
})
export class BadgeComponent {
label = "New";
}
```
3. The search component below is a very common example since it handles a business logic exposing simple inputs/outputs
```ts
import { Component, input, output } from "@angular/core";
@Component({
selector: "app-search-box",
template: `
<input
type="text"
[value]="query()"
(input)="onChange($event)"
placeholder="Search..."
/>
`,
})
export class SearchBoxComponent {
query = input<string>("");
changed = output<string>();
onChange(event: Event) {
const value = (event.target as HTMLInputElement).value;
this.changed.emit(value);
}
}
```
Encapsulation ensures that each component manages its own logic without leaking details to the outside. By keeping behavior self-contained, components become easier to understand, test, and reuse. This isolation prevents unexpected side effects, keeps your UI predictable, and allows each component to evolve independently as your application grows.
At this point, we can also briefly mention smart and dumb components. Smart components handle business logic, while dumb components take care of displaying data and emitting user actions.
This separation keeps your UI structure scalable. Smart components can change how data is loaded or handled without affecting presentation components, and dumb components can be reused anywhere since they just rely on inputs and outputs.
```ts
// smart component (container)
@Component({
selector: "app-user-profile",
imports: [UserCardComponent],
template: `<app-user-card [user]="user()" (select)="onSelect($event)" />`,
})
export class UserProfileComponent {
user = signal({ name: "Jane", role: "Admin" });
onSelect(user: any) {
console.log("Selected user:", user);
}
}
// dumb component (presentation)
@Component({
selector: "app-user-card",
standalone: true,
template: `
<div (click)="select.emit(user())" class="card">
<h3>{{ user().name }}</h3>
<p>{{ user().role }}</p>
</div>
`,
})
export class UserCardComponent {
user = input.required<{ name: string; role: string }>();
select = output<{ name: string; role: string }>();
}
```
---
## 🔁 Reusing Components Across the Application
As there are many ways of reusing a component in the project, we will go over a real-life example.
Here are two very common ABP components that can be reused anywhere in the app:
```ts
//...
import { ABP } from "@abp/ng.core";
@Component({
selector: "abp-button",
template: `
<button
#button
[id]="buttonId"
[attr.type]="buttonType"
[attr.form]="formName"
[ngClass]="buttonClass"
[disabled]="loading || disabled"
(click.stop)="click.next($event); abpClick.next($event)"
(focus)="focus.next($event); abpFocus.next($event)"
(blur)="blur.next($event); abpBlur.next($event)"
>
<i [ngClass]="icon" class="me-1" aria-hidden="true"></i
><ng-content></ng-content>
</button>
`,
imports: [NgClass],
})
export class ButtonComponent implements OnInit {
private renderer = inject(Renderer2);
@Input()
buttonId = "";
@Input()
buttonClass = "btn btn-primary";
@Input()
buttonType = "button";
@Input()
formName?: string = undefined;
@Input()
iconClass?: string;
@Input()
loading = false;
@Input()
disabled: boolean | undefined = false;
@Input()
attributes?: ABP.Dictionary<string>;
@Output() readonly click = new EventEmitter<MouseEvent>();
@Output() readonly focus = new EventEmitter<FocusEvent>();
@Output() readonly blur = new EventEmitter<FocusEvent>();
@Output() readonly abpClick = new EventEmitter<MouseEvent>();
@Output() readonly abpFocus = new EventEmitter<FocusEvent>();
@Output() readonly abpBlur = new EventEmitter<FocusEvent>();
@ViewChild("button", { static: true })
buttonRef!: ElementRef<HTMLButtonElement>;
get icon(): string {
return `${
this.loading ? "fa fa-spinner fa-spin" : this.iconClass || "d-none"
}`;
}
ngOnInit() {
if (this.attributes) {
Object.keys(this.attributes).forEach((key) => {
if (this.attributes?.[key]) {
this.renderer.setAttribute(
this.buttonRef.nativeElement,
key,
this.attributes[key]
);
}
});
}
}
}
```
This button component can be used by simply importing the `ButtonComponent` and using the `<abp-button />` tag.
You can reach the source code [here](https://github.com/abpframework/abp/blob/dev/npm/ng-packs/packages/theme-shared/src/lib/components/button/button.component.ts).
This modal component is also commonly used. The source code is [here](https://github.com/abpframework/abp/blob/dev/npm/ng-packs/packages/theme-shared/src/lib/components/modal/modal.component.ts).
```ts
//...
export type ModalSize = "sm" | "md" | "lg" | "xl";
@Component({
selector: "abp-modal",
templateUrl: "./modal.component.html",
styleUrls: ["./modal.component.scss"],
providers: [SubscriptionService],
imports: [NgTemplateOutlet],
})
export class ModalComponent implements OnInit, OnDestroy, DismissableModal {
protected readonly confirmationService = inject(ConfirmationService);
protected readonly modal = inject(NgbModal);
protected readonly modalRefService = inject(ModalRefService);
protected readonly suppressUnsavedChangesWarningToken = inject(
SUPPRESS_UNSAVED_CHANGES_WARNING,
{
optional: true,
}
);
protected readonly destroyRef = inject(DestroyRef);
private document = inject(DOCUMENT);
visible = model<boolean>(false);
busy = input(false, {
transform: (value: boolean) => {
if (this.abpSubmit() && this.abpSubmit() instanceof ButtonComponent) {
this.abpSubmit().loading = value;
}
return value;
},
});
options = input<NgbModalOptions>({ keyboard: true });
suppressUnsavedChangesWarning = input(
this.suppressUnsavedChangesWarningToken
);
modalContent = viewChild<TemplateRef<any>>("modalContent");
abpHeader = contentChild<TemplateRef<any>>("abpHeader");
abpBody = contentChild<TemplateRef<any>>("abpBody");
abpFooter = contentChild<TemplateRef<any>>("abpFooter");
abpSubmit = contentChild(ButtonComponent, { read: ButtonComponent });
readonly init = output();
readonly appear = output();
readonly disappear = output();
modalRef!: NgbModalRef;
isConfirmationOpen = false;
modalIdentifier = `modal-${uuid()}`;
get modalWindowRef() {
return this.document.querySelector(
`ngb-modal-window.${this.modalIdentifier}`
);
}
get isFormDirty(): boolean {
return Boolean(this.modalWindowRef?.querySelector(".ng-dirty"));
}
constructor() {
effect(() => {
this.toggle(this.visible());
});
}
ngOnInit(): void {
this.modalRefService.register(this);
}
dismiss(mode: ModalDismissMode) {
switch (mode) {
case "hard":
this.visible.set(false);
break;
case "soft":
this.close();
break;
default:
break;
}
}
protected toggle(value: boolean) {
this.visible.set(value);
if (!value) {
this.modalRef?.dismiss();
this.disappear.emit();
return;
}
setTimeout(() => this.listen(), 0);
this.modalRef = this.modal.open(this.modalContent(), {
size: "md",
centered: false,
keyboard: false,
scrollable: true,
beforeDismiss: () => {
if (!this.visible()) return true;
this.close();
return !this.visible();
},
...this.options(),
windowClass: `${this.options().windowClass || ""} ${
this.modalIdentifier
}`,
});
this.appear.emit();
}
ngOnDestroy(): void {
this.modalRefService.unregister(this);
this.toggle(false);
}
close() {
if (this.busy()) return;
if (this.isFormDirty && !this.suppressUnsavedChangesWarning()) {
if (this.isConfirmationOpen) return;
this.isConfirmationOpen = true;
this.confirmationService
.warn(
"AbpUi::AreYouSureYouWantToCancelEditingWarningMessage",
"AbpUi::AreYouSure",
{
dismissible: false,
}
)
.subscribe((status: Confirmation.Status) => {
this.isConfirmationOpen = false;
if (status === Confirmation.Status.confirm) {
this.visible.set(false);
}
});
} else {
this.visible.set(false);
}
}
listen() {
if (this.modalWindowRef) {
fromEvent<KeyboardEvent>(this.modalWindowRef, "keyup")
.pipe(
takeUntilDestroyed(this.destroyRef),
debounceTime(150),
filter(
(key: KeyboardEvent) =>
key && key.key === "Escape" && this.options().keyboard
)
)
.subscribe(() => this.close());
}
fromEvent(window, "beforeunload")
.pipe(takeUntilDestroyed(this.destroyRef))
.subscribe((event) => {
if (this.isFormDirty && !this.suppressUnsavedChangesWarning()) {
event.preventDefault();
}
});
this.init.emit();
}
}
```
This concept differs slightly from the others mentioned above since these components are introduced within a library called `theme-shared`, which you can explore [here](https://github.com/abpframework/abp/tree/dev/npm/ng-packs/packages/theme-shared).
Using **shared libraries** for such common components is one of the most effective ways to make your app modular and maintainable. By grouping frequently used elements into a dedicated library, you create a single source of truth for your UI and logic.
However, over-creating or prematurely abstracting small pieces of logic into separate libraries can lead to unnecessary complexity and dependency management overhead. When every feature has its own “mini-library,” updates and debugging become scattered and difficult to coordinate.
The key is to extract shared functionality only when it is proven to be reused across multiple contexts. Start small, let patterns emerge naturally, and then move them into a shared library when the benefits of reusability outweigh the maintenance cost.
---
## ⚙️ Best Practices and Common Pitfalls
### ✅ Best Practices
1. **Start with real reuse:** Extract components only after the pattern appears in multiple places.
2. **Keep them focused:** One clear responsibility per component—avoid “do-it-all” designs.
3. **Use standalone components:** Simplify imports and improve independence.
4. **Promote through libraries:** Move proven, stable components into shared libraries for wider use.
### ⚠️ Common Mistakes
1. **Premature abstraction:** Don't create components before actual reuse.
2. **Too many input/output bindings:** Overly generic components are hard to configure and maintain.
3. **Neglecting performance:** Too many micro-components can hurt performance.
4. **Ignoring accessibility and semantics:** Reusable does not mean usable—always consider ARIA roles and HTML structure.
---
## 📚 Further Reading and References
As this article has mentioned some concepts and best practices, you can explore these resources for more details:
- [Angular Components Guide](https://angular.dev/guide/components)
- [Standalone Migration Guides](https://angular.dev/reference/migrations/standalone), [ABP Angular Standalone Applications](https://abp.io/community/articles/abp-now-supports-angular-standalone-applications-zzi2rr2z#gsc.tab=0)
- [Smart vs. Dumb Components](https://blog.angular-university.io/angular-2-smart-components-vs-presentation-components-whats-the-difference-when-to-use-each-and-why/)
- [Angular Libraries Overview](https://angular.dev/tools/libraries)
You can also check these open-source libraries for a better understanding of reusability and modularity:
- [Angular Components on GitHub](https://github.com/angular/components)
- [ABP NPM Libraries](https://github.com/abpframework/abp/tree/dev/npm/ng-packs/packages)
---
## 🏁 Conclusion
Reusability is one of the strongest architectural foundations for scalable Angular applications. By combining **standalone components**, **signals**, **encapsulated logic**, and **shared libraries**, you can create a modular system that grows gracefully over time.
The goal is not just to make components reusable. It is to make them meaningful, maintainable, and consistent across your app. Build only what truly adds value, reuse intentionally, and let Angular's evolving ecosystem handle the rest.

289
docs/en/Community-Articles/2025-10-09-how-to-change-logo-in-angular-abp-apps/article.md

@ -0,0 +1,289 @@
# How to Change Logo in Angular ABP Applications
## Introduction
Logo application customization is one of the most common branding requirements in web applications. In ABP Framework's Angular applications, we found that developers were facing problems while they were trying to implement their application logos, especially on theme dependencies and flexibility. To overcome this, we moved the logo provider from `@volo/ngx-lepton-x.core` to `@abp/ng.theme.shared`, where it is more theme-independent and accessible. Here, we will describe our experience using this improvement and guide you on the new approach for logo configuration in ABP Angular applications.
## Problem
Previously, the logo configuration process in ABP Angular applications had several disadvantages:
1. **Theme Dependency**: The `provideLogo` function was a part of the `@volo/ngx-lepton-x.core` package, so the developers had to depend on LeptonX theme packages even when they were using a different theme or wanted to extend the logo behavior.
2. **Inflexibility**: The fact that the logo provider had to adhere to a specific theme package brought about an undesirable tight coupling of logo configuration and theme implementation.
3. **Discoverability Issues**: Developers looking for logo configuration features would likely look in core ABP packages, but the provider was hidden in a theme-specific package, which made it harder to discover.
4. **Migration Issues**: During theme changes or theme package updates, logo setting could get corrupted or require additional tuning.
These made a basic operation like altering the application logo more challenging than it should be, especially for teams using custom themes or wanting to maintain theme independence.
## Solution
We moved the `provideLogo` function from `@volo/ngx-lepton-x.core` to `@abp/ng.theme.shared` package. This solution offers:
- **Theme Independence**: Works with any ABP-compatible theme
- **Single Source of Truth**: Logo configuration is centralized in the environment file
- **Standard Approach**: Follows ABP's provider-based configuration pattern
- **Easy Migration**: Simple import path change for existing applications
- **Better Discoverability**: Located in a core ABP package where developers expect it
This approach maintains ABP's philosophy of providing flexible, reusable solutions while reducing unnecessary dependencies.
## Implementation
Let's walk through how logo configuration works with the new approach.
### Step 1: Configure Logo URL in Environment
First, define your logo URL in the `environment.ts` file:
```typescript
export const environment = {
production: false,
application: {
baseUrl: 'http://localhost:4200',
name: 'MyApplication',
logoUrl: 'https://your-domain.com/assets/logo.png',
},
// ... other configurations
};
```
The `logoUrl` property accepts any valid URL, allowing you to use:
- Absolute URLs (external images)
- Relative paths to assets folder (`/assets/logo.png`)
- Data URLs for embedded images
- CDN-hosted images
### Step 2: Provide Logo Configuration
In your `app.config.ts` (or `app.module.ts` for module-based apps), import and use the logo provider:
```typescript
import { provideLogo, withEnvironmentOptions } from '@abp/ng.theme.shared';
import { environment } from './environments/environment';
export const appConfig: ApplicationConfig = {
providers: [
// ... other providers
provideLogo(withEnvironmentOptions(environment)),
],
};
```
**Important Note**: If you're migrating from an older version where the logo provider was in `@volo/ngx-lepton-x.core`, simply update the import statement:
```typescript
// Old (before migration)
import { provideLogo, withEnvironmentOptions } from '@volo/ngx-lepton-x.core';
// New (current approach)
import { provideLogo, withEnvironmentOptions } from '@abp/ng.theme.shared';
```
### How It Works Under the Hood
The `provideLogo` function registers a logo configuration service that:
1. Reads the `logoUrl` from environment configuration
2. Provides it to theme components through Angular's dependency injection
3. Allows themes to access and render the logo consistently
The `withEnvironmentOptions` helper extracts the relevant configuration from your environment object, ensuring type safety and proper configuration structure.
### Example: Complete Configuration
Here's a complete example showing both environment and provider configuration:
**environment.ts:**
```typescript
export const environment = {
production: false,
application: {
baseUrl: 'http://localhost:4200',
name: 'E-Commerce Platform',
logoUrl: 'https://cdn.example.com/brand/logo-primary.svg',
},
oAuthConfig: {
issuer: 'https://localhost:44305',
clientId: 'MyApp_App',
// ... other OAuth settings
},
// ... other settings
};
```
**app.config.ts:**
```typescript
import { ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';
import { provideLogo, withEnvironmentOptions } from '@abp/ng.theme.shared';
import { environment } from './environments/environment';
import { routes } from './app.routes';
export const appConfig: ApplicationConfig = {
providers: [
provideRouter(routes),
provideLogo(withEnvironmentOptions(environment)),
// ... other providers
],
};
```
## Advanced: Logo Component Replacement
For more advanced customization scenarios where you need complete control over the logo component's structure, styling, or behavior, ABP provides a component replacement mechanism. This approach allows you to replace the entire logo component with your custom implementation.
### When to Use Component Replacement
Consider using component replacement when:
- You need custom HTML structure around the logo
- You want to add interactive elements (e.g., dropdown menu, animations)
- You need to implement complex responsive behavior
- The simple `logoUrl` configuration doesn't meet your requirements
### How to Replace the Logo Component
#### Step 1: Generate a New Logo Component
Run the following command in your Angular folder to create a new component:
```bash
ng generate component custom-logo --inline-template --inline-style
```
#### Step 2: Implement Your Custom Logo
Open the generated `custom-logo.component.ts` and implement your custom logo:
```typescript
import { Component } from '@angular/core';
import { RouterModule } from '@angular/router';
@Component({
selector: 'app-custom-logo',
standalone: true,
imports: [RouterModule],
template: `
<a class="navbar-brand" routerLink="/">
<img
src="https://via.placeholder.com/120x40/343a40/00D1B2?text=MyBrand"
alt="My Application Logo"
width="120"
height="40"
/>
</a>
`,
styles: [`
.navbar-brand {
padding: 0.5rem 1rem;
}
.navbar-brand img {
transition: opacity 0.3s ease;
}
.navbar-brand:hover img {
opacity: 0.8;
}
`]
})
export class CustomLogoComponent {}
```
#### Step 3: Register the Component Replacement
Open your `app.config.ts` and register the component replacement:
```typescript
import { ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';
import { ReplaceableComponentsService } from '@abp/ng.core';
import { eThemeBasicComponents } from '@abp/ng.theme.basic';
import { CustomLogoComponent } from './custom-logo/custom-logo.component';
import { environment } from './environments/environment';
import { routes } from './app.routes';
export const appConfig: ApplicationConfig = {
providers: [
provideRouter(routes),
// ... other providers
{
provide: 'APP_INITIALIZER',
useFactory: (replaceableComponents: ReplaceableComponentsService) => {
return () => {
replaceableComponents.add({
component: CustomLogoComponent,
key: eThemeBasicComponents.Logo,
});
};
},
deps: [ReplaceableComponentsService],
multi: true,
},
],
};
```
Alternatively, if you're using a module-based application, you can register it in `app.component.ts`:
```typescript
import { Component, OnInit } from '@angular/core';
import { ReplaceableComponentsService } from '@abp/ng.core';
import { eThemeBasicComponents } from '@abp/ng.theme.basic';
import { CustomLogoComponent } from './custom-logo/custom-logo.component';
@Component({
selector: 'app-root',
template: '<router-outlet></router-outlet>',
})
export class AppComponent implements OnInit {
constructor(private replaceableComponents: ReplaceableComponentsService) {}
ngOnInit() {
this.replaceableComponents.add({
component: CustomLogoComponent,
key: eThemeBasicComponents.Logo,
});
}
}
```
### Component Replacement vs Logo URL Configuration
Here's a comparison to help you choose the right approach:
| Feature | Logo URL Configuration | Component Replacement |
|---------|------------------------|----------------------|
| **Simplicity** | Very simple, one-line configuration | Requires creating a new component |
| **Flexibility** | Limited to image URL | Full control over HTML/CSS/behavior |
| **Use Case** | Standard logo display | Complex customizations |
| **Maintenance** | Minimal | Requires component maintenance |
| **Migration** | Easy to change | Requires code changes |
| **Recommended For** | Most applications | Advanced customization needs |
For most applications, the simple `logoUrl` configuration in the environment file is sufficient and recommended. Use component replacement only when you need advanced customization that goes beyond a simple image.
### Benefits of This Approach
1. **Separation of Concerns**: Logo configuration is separate from theme implementation
2. **Environment-Based**: Different logos for development, staging, and production
3. **Type Safety**: TypeScript ensures correct configuration structure
4. **Testing**: Easy to mock and test logo configuration
5. **Consistency**: Same logo appears across all theme components automatically
6. **Flexibility**: Choose between simple configuration or full component replacement based on your needs
## Conclusion
In this article, we explored how ABP Framework simplified logo configuration in Angular applications by moving the logo provider from `@volo/ngx-lepton-x.core` to `@abp/ng.theme.shared`. This change eliminates unnecessary theme dependencies and makes logo customization more straightforward and theme-agnostic.
The solution we implemented allows developers to configure their application logo simply by setting a URL in the environment file and providing the logo configuration in their application setup. For advanced scenarios requiring complete control over the logo component, ABP's component replacement mechanism provides a powerful alternative. This approach maintains flexibility while reducing complexity and improving discoverability.
We developed this improvement while working on ABP Framework to enhance developer experience and reduce common friction points. By sharing this solution, we hope to help teams implement consistent branding across their ABP Angular applications more easily, regardless of which theme they choose to use.
If you're using an older version of ABP with logo configuration in LeptonX packages, migrating to this new approach requires only a simple import path change, making it a smooth upgrade path for existing applications.
## See Also
- [Component Replacement Documentation](https://abp.io/docs/latest/framework/ui/angular/component-replacement)
- [ABP Angular UI Customization Guide](https://abp.io/docs/latest/framework/ui/angular/customization)

BIN
docs/en/Community-Articles/2025-10-10-Using-Transfer-State-with-Angular-SSR/cover.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 294 KiB

267
docs/en/Community-Articles/2025-10-10-Using-Transfer-State-with-Angular-SSR/post.md

@ -0,0 +1,267 @@
# From Server to Browser — the Elegant Way: Angular TransferState Explained
## Introduction
When building Angular applications with Server‑Side Rendering (SSR), a common performance pitfall is duplicated data fetching: the server loads data to render HTML, then the browser bootstraps Angular and fetches the same data again. That’s wasteful, increases Time‑to‑Interactive, and can hammer your APIs.
Angular’s built‑in **TransferState** lets you transfer the data fetched on the server to the browser during hydration so the client can reuse it instead of calling the API again. It’s simple, safe for serializable data, and makes SSR feel instant for users.
This article explains what TransferState is, and how to implement it in your Angular SSR app.
---
## What Is TransferState?
TransferState is a key–value store that exists for a single SSR render. On the server, you put serializable data into the store. Angular serializes it into the HTML as a small script tag. When the browser hydrates, Angular reads that payload back and makes it available to your app. You can then consume it and skip duplicate HTTP calls.
Key points:
- Works only across the SSR → browser hydration boundary (not a general cache).
- Data is cleaned up after bootstrapping (no stale data).
- Stores JSON‑serializable data only (if you need to use Date/Functions/Map; serialize it).
- Data is set on the server and read on the client.
---
## When Should You Use It?
- Data fetched during SSR that is also be needed on the client.
- Data that doesn’t change between server render and immediate client hydration.
- Expensive or slow API endpoints where a second request is visibly costly.
Avoid using it for:
- Highly dynamic data that changes frequently.
- Sensitive data (never put secrets/tokens in TransferState).
- Large payloads (keep the serialized state small to avoid bloating HTML).
---
## Prerequisites
- An Angular app with SSR enabled (Angular ≥16: `ng add @angular/ssr`).
- `HttpClient` configured. The examples below show both manual TransferState use and the build in solutions.
---
## Option A — Using TransferState Manually
This approach gives you full control over what to cache and when. It's straightforward and works in both module‑based and standalone‑based apps.
Service example that fetches books and uses TransferState:
```ts
// books.service.ts
import {
Injectable,
PLATFORM_ID,
makeStateKey,
TransferState,
inject,
} from '@angular/core';
import { isPlatformServer } from '@angular/common';
import { HttpClient } from '@angular/common/http';
import { Observable, of } from 'rxjs';
import { tap } from 'rxjs/operators';
export interface Book {
id: number;
name: string;
price: number;
}
@Injectable({ providedIn: 'root' })
export class BooksService {
BOOKS_KEY = makeStateKey<Book[]>('books:list');
readonly httpClient = inject(HttpClient);
readonly transferState = inject(TransferState);
readonly platformId = inject(PLATFORM_ID);
getBooks(): Observable<Book[]> {
// If browser and we have the data that already fetched on the server, use it and remove from TransferState
if (this.transferState.hasKey(this.BOOKS_KEY)) {
const cached = this.transferState.get<Book[]>(this.BOOKS_KEY, []);
this.transferState.remove(this.BOOKS_KEY); // remove to avoid stale reads
return of(cached);
}
// Otherwise fetch data. If running on the server, write into TransferState
return this.httpClient.get<Book[]>('/api/books').pipe(
tap(list => {
if (isPlatformServer(this.platformId)) {
this.transferState.set(this.BOOKS_KEY, list);
}
})
);
}
}
```
Use it in a component:
```ts
// books.component.ts
import { Component, inject, OnInit } from '@angular/core';
import { CommonModule } from '@angular/common';
import { BooksService, Book } from './books.service';
@Component({
selector: 'app-books',
imports: [CommonModule],
template: `
<h1>Books</h1>
<ul>
@for (book of books; track book.id) {
<li>{{ book.name }} — {{ book.price | currency }}</li>
}
</ul>
`,
})
export class BooksComponent implements OnInit {
private booksService = inject(BooksService);
books: Book[] = [];
ngOnInit() {
this.booksService.getBooks().subscribe(data => (this.books = data));
}
}
```
Route resolver variant (keeps templates simple and aligns with SSR prefetching):
```ts
// src/app/routes.ts
export const routes: Routes = [
{
path: 'books',
component: BooksComponent,
resolve: {
books: () => inject(BooksService).getBooks(),
},
},
];
```
Then read `books` from the `ActivatedRoute` data in your component.
---
## Option B — Using HttpInterceptor to Automate TransferState
Like Option A, but less boilerplate. This approach uses an **HttpInterceptor** to automatically cache HTTP GET (also POST/PUT request but not recommended) responses in TransferState. You can determine which requests to cache based on URL patterns.
Example interceptor that caches GET requests:
```ts
import { inject, makeStateKey, PLATFORM_ID, TransferState } from '@angular/core';
import {
HttpEvent,
HttpHandlerFn,
HttpInterceptorFn,
HttpRequest,
HttpResponse,
} from '@angular/common/http';
import { Observable, of } from 'rxjs';
import { isPlatformBrowser, isPlatformServer } from '@angular/common';
import { tap } from 'rxjs/operators';
export const transferStateInterceptor: HttpInterceptorFn = (
req: HttpRequest<any>,
next: HttpHandlerFn,
): Observable<HttpEvent<any>> => {
const transferState = inject(TransferState);
const platformId = inject(PLATFORM_ID);
// Only cache GET requests. You can customize this to match specific URLs if needed.
if (req.method !== 'GET') {
return next(req);
}
// Create a unique key for this request
const stateKey = makeStateKey<HttpResponse<any>>(req.urlWithParams);
// If browser, check if we have the response in TransferState
if (isPlatformBrowser(platformId)) {
const storedResponse = transferState.get<HttpResponse<any>>(stateKey, null);
if (storedResponse) {
transferState.remove(stateKey); // remove to avoid stale reads
return of(new HttpResponse<any>({ body: storedResponse, status: 200 }));
}
}
return next(req).pipe(
tap(event => {
// If server, store the response in TransferState
if (isPlatformServer(platformId) && event instanceof HttpResponse) {
transferState.set(stateKey, event.body);
}
}),
);
};
```
Add the interceptor to your app module or bootstrap function:
````ts
provideHttpClient(withFetch(), withInterceptors([transferStateInterceptor]))
````
---
## Option C — Using Angular's Built-in HTTP Transfer Cache
This is the simplest option if you want to HTTP requests that without custom logic.
Angular docs: https://angular.dev/api/platform-browser/withHttpTransferCacheOptions
Usage examples:
```ts
// Only cache GET requests that have no headers
provideClientHydration(withHttpTransferCacheOptions({}))
// Also cache POST requests (not recommended for most cases)
provideClientHydration(withHttpTransferCacheOptions({
includePostRequests: true
}))
// Cache requests that have auth headers (e.g., JWT tokens)
provideClientHydration(withHttpTransferCacheOptions({
includeRequestsWithAuthHeaders: true
}))
```
To see all options, check the Angular docs: https://angular.dev/api/common/http/HttpTransferCacheOptions
## Best Practices and Pitfalls
- Keep payloads small: only put what’s needed for initial paint.
- Serialize explicitly if needed: for Dates or complex types, convert to strings and reconstruct on the client.
- Don’t transfer secrets: never place tokens or sensitive user data in TransferState.
- Per‑request isolation: state is scoped to a single SSR request; it is not a global cache.
---
## Debugging Tips
- Log on server vs browser: use `isPlatformServer` and `isPlatformBrowser` checks to confirm where code runs.
- DevTools inspection: view the page source after SSR; you’ll see a small script tag that embeds the transfer state.
- Count requests: put a console log in your service to verify the second HTTP call is gone on the client.
---
## Measurable Impact
On content‑heavy pages, TransferState typically removes 1–3 duplicate API calls during hydration, shaving 100–500 ms from the critical path on average networks. It’s a low‑effort, high‑impact win for SSR apps.
---
## Conclusion
If you already have SSR, enabling TransferState is one of the easiest ways to make hydration feel instant. You can use it built‑in HTTP caching or manually control what to cache. Either way, it eliminates redundant data fetching, speeds up Time‑to‑Interactive, and improves user experience with minimal effort.

244
docs/en/Community-Articles/2025-10-15-angular-library-linking-made-easy-paths-workspaces-and-symlinks/POST.md

@ -0,0 +1,244 @@
# Angular Library Linking Made Easy: Paths, Workspaces, and Symlinks
Managing local libraries and path references in Angular projects has evolved significantly with the introduction of the new Angular application builder. What once required manual path mappings, fragile symlinks, and `node_modules` references is now more structured, predictable, and aligned with modern TypeScript and workspace practices. This guide walks through how path mapping works, how it has changed, and the best ways to link and manage your local libraries in brand new Angular ecosystem.
### Understanding TypeScript Path Mapping
Path aliases is a powerful feature in TypeScript that helps developers simplify and organize their import statements. Instead of dealing with long and error-prone relative paths like `../../../components/button`, you can define a clear and descriptive alias that points directly to a specific directory or module.
This configuration is managed through the `paths` property in the TypeScript configuration file (`tsconfig.json`), allowing you to map custom names to local folders or compiled outputs. For example:
```json
// tsconfig.json
{
"compilerOptions": {
"paths": {
"@my-package": ["./dist/my-package"],
"@my-second-package": ["./projects/my-second-package/src/public-api.ts"]
}
}
}
```
In this setup, `@my-package` serves as a shorthand reference to your locally built library. Once configured, you can import modules using `@my-package` instead of long relative paths, which greatly improves readability and maintainability across large projects.
When working with multiple subdirectories or a more complex folder structure, you can also use wildcards to create flexible and dynamic mappings. This pattern is especially useful for modular libraries or mono-repos that contain multiple sub-packages:
```json
// tsconfig.json
{
"compilerOptions": {
"paths": {
"@my-package/*": ["./dist/my-package/*"]
}
}
}
```
With this approach, imports like `@my-package/utils` or `@my-package/components/button` will automatically resolve to the corresponding directories in your build output. This makes your codebase more maintainable, portable, and consistent. This is useful especially when collaborating across teams or working with multiple libraries in the same workspace.
---
### Step-by-Step Examples of Path Configuration
As this example provides a glimpse for the path mapping, this is not the only way for the aliases. Here are the other ways to utilize this feature.
1. **Using `package.json` Exports for Library Mapping**
When developing internal libraries within a mono-repo, another option is to use the `exports` field in each library’s `package.json`
This allows Node and modern bundlers to resolve imports cleanly when consuming the library, without depending solely on TypeScript configuration.
```json
// dist/my-lib/package.json
{
"name": "@my-org/my-lib",
"version": "1.0.0",
"exports": {
".": "./index.js",
"./utils": "./utils/index.ts"
}
}
```
```tsx
import { formatDate } from "@my-org/my-lib/utils";
```
This approach becomes especially powerful when publishing your libraries or integrating them into larger Angular mono-repos. Because, it aligns both runtime (Node) and compile-time (TypeScript) resolution.
2. **Linking Local Libraries via Symlinks**
If you want to use a local library that is not yet published to npm, you can create a symbolic link between your library’s `dist` output and your consuming app.
This is useful when testing or developing multiple packages in parallel.
You can create a symlink using npm or yarn:
```bash
# Inside your library folder
npm link
# Inside your consuming app
npm link @my-org/my-lib
```
This effectively tells Node to resolve `@my-org/my-lib` from your local file system instead of the npm registry.
However, note that symlinks can sometimes lead to path resolution issues with certain Angular build configurations, especially before the new application builder. With the latest builder improvements, this approach is becoming more stable and predictable.
3. **Combining Path Mapping with Workspace Configuration**
In a structured Angular workspace, especially one created with **Nx** or **Angular CLI** using multiple projects, you can combine the approaches above.
For instance, your `tsconfig.base.json` can define local references for in-repo libraries, while each library’s `package.json` provides external mappings for reuse outside the workspace.
This hybrid setup ensures that:
- The workspace remains easy to navigate and refactor locally.
- External consumers (or CI builds) can still resolve imports correctly once libraries are built.
For larger Angular projects or mono-repos, **Workspaces** (supported by both **Yarn** and **npm**) offer a clean way to manage multiple local packages within the same repository. Workspaces automatically link internal libraries together, so you can reference them by name instead of using manual `file:` paths or complex TypeScript aliases. This approach keeps dependencies consistent, simplifies cross-project development, and scales well for enterprise or multi-package setups.
Each of these methods has its strengths:
- **TypeScript paths:** This is great for local development and quick imports.
- **`package.json` exports:** This is ideal for libraries meant to be distributed.
- **Symlinks:** These are convenient for local testing between projects.
Choosing the right one, or even combining them depends on the scale of your project and whether you are building internal libraries, or a full mono-repo setup.
---
### How Path References Worked Before the New Angular Application Builder
Angular used to support path aliases to the locally installed packages by referencing to the `node_modules` folder like this:
```json
// tsconfig.json
{
"compilerOptions": {
"paths": {
"@angular/*": ["./node_modules/@angular/*"]
}
}
}
```
However, this approach is not recommended, hence not supported, by the TypeScript. You can find detailed guidance on this topic in the TypeScript documentation, which notes that paths should not reference mono-repo packages or those inside **node_modules**: [Paths should not point to monorepo packages or node_modules packages](https://www.typescriptlang.org/docs/handbook/modules/reference.html#paths-should-not-point-to-monorepo-packages-or-node_modules-packages).
Giving a real life example would explain the situation better. Suppose that you have such structure:
- Amain angular app that consumes several npm dependencies and holds registered local paths that reference to another library locally like this:
```json
// angular/tsconfig.json
{
"compileOnSave": false,
"compilerOptions": {
"paths": {
"@abp/ng.identity": [
"../modules/Volo.Abp.Identity/angular/projects/identity/src/public-api.ts"
],
"@abp/ng.identity/config": [
"../modules/Volo.Abp.Identity/angular/projects/identity/config/src/public-api.ts"
],
"@abp/ng.identity/proxy": [
"../modules/Volo.Abp.Identity/angular/projects/identity/proxy/src/public-api.ts"
]
}
}
}
```
This simply references to this package physically https://github.com/abpframework/abp/tree/dev/npm/ng-packs/packages/identity
- This library is also using these dependencies
```json
// npm/ng-packs/packages/identity/package.json
{
"name": "@abp/ng.identity",
"version": "10.0.0-rc.1",
"homepage": "https://abp.io",
"repository": {
"type": "git",
"url": "https://github.com/abpframework/abp.git"
},
"dependencies": {
"@abp/ng.components": "~10.0.0-rc.1",
"@abp/ng.permission-management": "~10.0.0-rc.1",
"@abp/ng.theme.shared": "~10.0.0-rc.1",
"tslib": "^2.0.0"
},
"publishConfig": {
"access": "public"
}
}
```
As these libraries also have their own dependencies, the identity package needs to consume them in itself. Before the [application builder migration](https://angular.dev/tools/cli/build-system-migration), you could register the path configuration like this
```json
// angular/tsconfig.json
{
"compileOnSave": false,
"compilerOptions": {
"paths": {
"@angular/*": ["node_modules/@angular/*"],
"@abp/*": ["node_modules/@abp/*"],
"@swimlane/*": ["node_modules/@swimlane/*"],
"@ngx-validate/core": ["node_modules/@ngx-validate/core"],
"@ng-bootstrap/ng-bootstrap": [
"node_modules/@ng-bootstrap/ng-bootstrap"
],
"@abp/ng.identity": [
"../modules/Volo.Abp.Identity/angular/projects/identity/src/public-api.ts"
],
"@abp/ng.identity/config": [
"../modules/Volo.Abp.Identity/angular/projects/identity/config/src/public-api.ts"
],
"@abp/ng.identity/proxy": [
"../modules/Volo.Abp.Identity/angular/projects/identity/proxy/src/public-api.ts"
]
}
}
}
```
However, the latest builder forces more strict rules. So, it does not resolve the paths that reference to the `node_modules` causing a common DI error as mentioned here:
- https://github.com/angular/angular-cli/issues/31395
- https://github.com/angular/angular-cli/issues/26901
- https://github.com/angular/angular-cli/issues/27176
In this case, we recommend using a symlink script. You can reach them through this example application: [🔗 Angular Sample Path Reference](https://github.com/sumeyyeKurtulus/AbpPathReferenceExamples)
These scripts help you share dependencies from the main Angular app to local library projects via symlinks:
- `symlink-config.ps1` centralizes which library directories to touch (e.g., ../../modules/Volo.Abp.Identity/angular/projects/identity) and which packages to link (e.g., @angular, @abp, rxjs)
- `setup-symlinks.ps1` reads that config and, for each library, creates a `node_modules` folder if needed and symlinks only the listed packages from the `node_modules` of the app to avoid duplicate installs
- `remove-symlinks.ps1` cleans up by deleting those library `node_modules` directories so they can use their own local deps again
- In `angular/package.json`, the `symlinks:setup` and `symlinks:remove` npm scripts simply run those two PowerShell scripts so you can execute them conveniently with your package manager.
---
### Best Practices and Recommendations
As we have explained each way of path mapping, this part of the article aims to summarize the best practices. Here are the points you need to consider:
- Prefer **workspace references** for large projects and mono-repos.
- Use **TypeScript path aliases** only for local development convenience.
- Strictly avoid referencing `node_modules` directly; let the Angular builder manage package resolution.
- Maintain **consistent library structures** with clear `package.json` exports for reusable libraries.
- Automate **symlink creation/removal** if needed to reduce manual errors.
Here is the list of common pitfalls and how you could troubleshoot them:
- **DI errors after path configurations for typescript config**: Ensure that only one copy of each library is resolved. Avoid duplicate modules by checking `node_modules` and symlinks.
- **IDE not recognizing aliases**: Confirm that `tsconfig.json` or `tsconfig.base.json` includes the correct `paths` configuration and that your IDE is using the correct tsconfig.
- **Build errors with old paths**: Migrate paths pointing to `node_modules` to either workspace references or local library paths.
- **Symlink issues in CI/CD**: Use automated scripts to create/remove symlinks consistently; do not rely on manual linking.
- **Module resolution conflicts**: Check library dependencies for mismatched versions and align them using a package manager workspace strategy.
As Angular’s build system continues to mature, developers are encouraged to move away from outdated path configurations and manual symlink setups. By embracing workspace references, consistent library exports, and TypeScript path mapping, teams can build scalable, maintainable applications without wrestling with complex import paths or dependency conflicts. With the right configuration, local development becomes faster, cleaner, and far more reliable.

88
docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/POST.md

@ -0,0 +1,88 @@
# 5 Things You Should Keep in Mind When Deploying to a Clustered Environment
Let’s be honest — moving from a single server to a cluster sounds simple on paper.
You just add a few more machines, right?
In practice, it’s the moment when small architectural mistakes start to grow legs.
Below are a few things that experienced engineers usually double-check before pressing that “Deploy” button.
---
## 1️⃣ Managing State the Right Way
Each request in a cluster might hit a different machine.
If your application keeps user sessions or cache in memory, that data probably won’t exist on the next node.
That’s why many teams decide to push state out of the app itself.
![Stateless vs Stateful](stateless.png)
**A few real-world tips:**
- Keep sessions in **Redis** or something similar instead of local memory.
- Design endpoints so they don’t rely on earlier requests.
- Don’t assume the same server will handle two requests in a row — it rarely does.
---
## 2️⃣ Shared Files and Where to Put Them
Uploading files to local disk? That’s going to hurt in a cluster.
Other nodes can’t reach those files, and you’ll spend hours wondering why images disappear.
![Shared Storage](shared.png)
**Better habits:**
- Push uploads to **S3**, **Azure Blob**, or **Google Cloud Storage**.
- Send logs to a shared location instead of writing to local files.
- Keep environment configs in a central place so each node starts with the same settings.
---
## 3️⃣ Database Connections Aren’t Free
Every node opens its own database connections.
Ten nodes with twenty connections each — that’s already two hundred open sessions.
The database might not love that.
![Database Connections](database.png)
**What helps:**
- Put a cap on your connection pools.
- Avoid keeping transactions open for too long.
- Tune indexes and queries before scaling horizontally.
---
## 4️⃣ Logging and Observability Matter More Than You Think
When something breaks in a distributed system, it’s never obvious which server was responsible.
That’s why observability isn’t optional anymore.
![Observability](logging.png)
**Consider this:**
- Stream logs to **ELK**, **Datadog**, or **Grafana Loki**.
- Add a **trace ID** to every incoming request and propagate it across services.
- Watch key metrics with **Prometheus** and visualize them in Grafana dashboards.
---
## 5️⃣ Background Jobs and Message Queues
If more than one node runs the same job, you might process the same data twice — or delete something by mistake.
You don’t want that kind of excitement in production.
![Background Jobs](background.png)
**A few precautions:**
- Use a **distributed lock** or **leader election** system.
- Make jobs **idempotent**, so running them twice doesn’t break data.
- Centralize queue consumers or use a proper task scheduler.
---
## Wrapping Up
Deploying to a cluster isn’t only about scaling up — it’s about staying stable when you do.
Systems that handle state, logging, and background work correctly tend to age gracefully.
Everything else eventually learns the hard way.
> A cluster doesn’t fix design flaws — it magnifies them.

BIN
docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/all.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 118 KiB

BIN
docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/background.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 68 KiB

BIN
docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/cover-image.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 718 KiB

BIN
docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/database.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 75 KiB

27
docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/dev-to.md

@ -0,0 +1,27 @@
# 5 Things You Should Keep in Mind When Deploying to a Clustered Environment
Let’s be honest — moving from a single server to a cluster sounds simple on paper.
You just add a few more machines, right?
In practice, it’s the moment when small architectural mistakes start to grow legs.
Below are a few things that experienced engineers usually double-check before pressing that “Deploy” button.
---
## 1️⃣ Managing State the Right Way
---
## 2️⃣ Shared Files and Where to Put Them
---
## 3️⃣ Database Connections Aren’t Free
---
## 4️⃣ Logging and Observability Matter More Than You Think
---
## 5️⃣ Background Jobs and Message Queues
---
![all](all.png)
👉 Read the full guide here: [5 Things You Should Keep in Mind When Deploying to a Clustered Environment](https://abp.io/community/articles/)

BIN
docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/logging.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 67 KiB

BIN
docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/shared.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 87 KiB

BIN
docs/en/Community-Articles/2025-10-17-5-Things-Deploy-Clustered-Environment/stateless.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 40 KiB

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/1.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 352 KiB

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/10.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 206 KiB

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/11.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 237 KiB

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/11_1.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 52 KiB

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/2.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 354 KiB

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/3.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 487 KiB

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/4.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.2 MiB

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/5.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 366 KiB

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/6.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 256 KiB

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/7.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 191 KiB

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/8.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 242 KiB

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/9.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 190 KiB

251
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/Post.md

@ -0,0 +1,251 @@
# Optimize Your .NET App for Production (Complete Checklist)
I see way too many .NET apps go to prod like it’s still “F5 on my laptop.” Here’s the checklist I wish someone shoved me years ago. It’s opinionated, pragmatic, copy-pasteable.
------
## 1) Publish Command and CSPROJ Settings
![Publish Command and CSPROJ Setting](1.png)
Never go to production with debug build! See the below command which publishes properly a .NET app for production.
```bash
dotnet publish -c Release -o out -p:PublishTrimmed=true -p:PublishSingleFile=true -p:ReadyToRun=true
```
`csproj` for the optimum production publish:
```xml
<PropertyGroup>
<PublishReadyToRun>true</PublishReadyToRun>
<PublishTrimmed>true</PublishTrimmed>
<InvariantGlobalization>true</InvariantGlobalization>
<TieredCompilation>true</TieredCompilation>
</PropertyGroup>
```
- **PublishTrimmed** It's trimmimg assemblies. What's that!? It removes unused code from your application and its dependencies, hence it reduces the output files.
- **PublishReadyToRun** When you normally build a .NET app, your C# code is compiled into **IL** (Intrmediate Language). When your app runs, the JIT Compiler turns that IL code into native CPU commands. But this takes much time on startup. When you enable `PublishReadyToRun`, the build process precompiles your IL into native code and it's called AOT (Ahead Of Time). Hence your app starts faster... But the downside is; the output files are now a bit bigger. Another thing; it'll compile only for a specific OS like Windows and will not run on Linux anymore.
- **Self-contained** When you publish your .NET app this way, it ncludes the .NET runtime inside your app files. It will run even on a machine that doesn’t have .NET installed. The output size gets larger, but the runtime version is exactly what you built with.
------
## 2) Kestrel Hosting
![Kestrel Hosting](2.png)
By default, ASP.NET Core app listen only `localhost`, it means it accepts requests only from inside the machine. When you deploy to Docker or Kubernetes, the container’s internal network needs to expose the app to the outside world. To do this you can set it via environment variable as below:
```bash
ASPNETCORE_URLS=http://0.0.0.0:8080
```
Also if you’re building an internall API or a containerized microservice which is not multilngual, then add also the below setting. it disables operating system's globalization to reduce image size and dependencies..
```bash
DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1
```
Clean `Program.cs` startup!
Here's a minimal `Program.cs` which includes just the essential middleware and settings:
```csharp
var builder = WebApplication.CreateBuilder(args);
builder.Logging.ClearProviders();
builder.Logging.AddConsole();
builder.Services.AddResponseCompression();
builder.Services.AddResponseCaching();
builder.Services.AddHealthChecks();
var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/error");
app.UseHsts();
}
app.UseResponseCompression();
app.UseResponseCaching();
app.MapHealthChecks("/health");
app.MapGet("/error", () => Results.Problem(statusCode: 500));
app.Run();
```
------
## 3) Garbage Collection and ThreadPool
![Garbage Collection and ThreadPool](3.png)
### GC Memory Cleanup Mode
GC (Garbage Collection) is how .NET automatically frees memory. There are two main modes:
- **Workstation GC:** good for desktop apps (focuses on responsiveness)
- **Server GC:** good for servers (focuses on throughput)
The below environment variable is telling the .NET runtime to use the *Server Garbage Collector (Server GC)* instead of the *Workstation GC*. Because our ASP.NET Core app must be optmized for servers not personal computers.
```bash
COMPlus_gcServer=1
```
### GC Limit Memory Usage
Use at max 60% of the total available memory for the managed heap (the memory that .NET’s GC controls). So if your container or VM has, let's say 4 GB of RAM, .NET will try to keep the GC heap below 2.4 GB (60% of 4 GB). Especially when you run your app in containers, don’t let the GC assume host memory:
```bash
COMPlus_GCHeapHardLimitPercent=60
```
### Thread Pool Warm-up
When your .NET app runs, it uses a thread pool. This is for handling background work like HTTP requests, async tasks, I/O things... By default, the thread pool starts small and grows dynamically as load increases. That’s good for desktop apps but for server apps it's too slow! Because during sudden peek of traffic, the app might waste time creating threads instead of handling requests. So below code keeps at least 200 worker threads and 200 I/O completion threads ready to go even if they’re idle.
```csharp
ThreadPool.SetMinThreads(200, 200);
```
------
## 4) HTTP Performance
![HTTP Performance](4.png)
### HTTP Response Compression
`AddResponseCompression()` enables HTTP response compression. It shrinks your outgoing responses before sending them to the client. Making smaller payloads for faster responses and uses less bandwidth. Default compression method is `Gzip`. You can also add `Brotli` compression. `Brotli` is great for APIs returning JSON or text. If your CPU is already busy, keep the default `Gzip` method.
```csharp
builder.Services.AddResponseCompression(options =>
{
options.Providers.Add<BrotliCompressionProvider>();
options.EnableForHttps = true;
});
```
### HTTP Response Caching
Use caching for GET endpoints where data doesn’t change often (e.g., configs, reference data). `ETags` and `Last-Modified` headers tell browsers or proxies skip downloading data that hasn’t changed.
- **ETag** = a version token for your resource.
- **Last-Modified** = timestamp of last change.
If a client sends `If-None-Match: "abc123"` and your resource’s `ETag` hasn’t changed, .NET automatically returns `304 Not Modified`.
### HTTP/2 or HTTP/3
These newer protocols make web requests faster and smoother. It's good for microservices or frontends making many API calls.
- **HTTP/2** : multiplexing (many requests over one TCP connection).
- **HTTP/3** : uses QUIC (UDP) for even lower latency.
You can enable them on your reverse proxy (Nginx, Caddy, Kestrel)...
.NET supports both out of the box if your environment allows it.
### Minimal Payloads with DTOs
The best practise here is; Never send/recieve your entire database entity, use DTOs. In the DTOs include only the fields the client actually needs by doing so you will keep the responses smaller and even safer. Also, prefer `System.Text.Json` (now it’s faster than `Newtonsoft.Json`) and for very high-traffic APIs, use source generation to remove reflection overhead.
```csharp
//define your entity DTO
[JsonSerializable(typeof(MyDto))]
internal partial class MyJsonContext : JsonSerializerContext { }
//and simply serialize like this
var json = JsonSerializer.Serialize(dto, MyJsonContext.Default.MyDto)
```
------
## 5) Data Layer (Mostly Where Most Apps Slow Down!)
![Data Layer](5.png)
### Reuse `DbContext` via Factory (Pooling)
Creating a new `DbContext` for every query is expensive! Use `IDbContextFactory<TContext>`, it gives you pooled `DbContext` instances from a pool that reuses objects instead of creating them from scratch.
```csharp
services.AddDbContextFactory<AppDbContext>(options =>
options.UseSqlServer(connectionString));
```
Then inject the factory:
```csharp
using var db = _contextFactory.CreateDbContext();
```
Also, ensure your database server (SQL Server, PostgreSQL....) has **connection pooling enabled**.
------
### N+1 Query Problem
The N+1 problem occurs when your app runs **one query for the main data**, then **N more queries for related entities**. That kills performance!!!
**Bad-Practise:**
```csharp
var users = await context.Users.Include(u => u.Orders).ToListAsync();
```
**Good-Practise:**
Project to DTOs using `.Select()` so EF-Core generates a single optimized SQL query:
```csharp
var users = await context.Users.Select(u => new UserDto
{
Id = u.Id,
Name = u.Name,
OrderCount = u.Orders.Count
}).ToListAsync();
```
------
### **Indexes**
Use EF Core logging, SQL Server Profiler, or `EXPLAIN` (Postgres/MySQL) to find slow queries. Add missing indexes **only** where needed. For example [at this page](https://blog.sqlauthority.com/2011/01/03/sql-server-2008-missing-index-script-download/), he wrote an SQL query which lists missing index list (also there's another version at [Microsoft Docs](https://learn.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-db-missing-index-details-transact-sql?view=sql-server-ver17)). This perf improvement is mostly applied after running the app for a period of time.
------
### Migrations
In production run migrations manually, never do it on app startup. That way you can review schema changes, back up data and avoid breaking the live DB.
------
### Resilience with Polly
Use [Polly](https://www.pollydocs.org/) for retries, timeouts and circuit breakers for your DB or HTTP calls. Handles short outages gracefully
*To keep the article short and for the better readability I spitted it into 2 parts 👉 [Continue with the second part here](https://abp.io/community/articles/optimize-your-dotnet-app-for-production-for-any-.net-app-2-78xgncpi)...*

267
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/Post2.md

@ -0,0 +1,267 @@
*If you’ve landed directly on this article, note that it’s part-2 of the series. You can read part-1 here: [Optimize Your .NET App for Production (Part 1)](https://abp.io/community/articles/optimize-your-dotnet-app-for-production-for-any-.net-app-wa24j28e)*
## 6) Telemetry (Logs, Metrics, Traces)
![Telemetry](6.png)
The below code adds `OpenTelemetry` to collect app logs, metrics, and traces in .NET.
```csharp
builder.Services.AddOpenTelemetry()
.UseOtlpExporter()
.WithMetrics(m => m.AddAspNetCoreInstrumentation().AddHttpClientInstrumentation())
.WithTracing(t => t.AddAspNetCoreInstrumentation().AddHttpClientInstrumentation());
```
- `UseOtlpExporter()` Tells it where to send telemetry. Usually that’s an OTLP collector (like Grafana , Jaeger, Tempo, Azure Monitor). So you can visualize metrics and traces in dashboards.
- `WithMetrics()` means it'll collects metrics. These metrics are Request rate (RPS), Request duration (latency), GC pauses, Exceptions, HTTP client timings.
- `.WithTracing(...)` means it'll collect distributed traces. That's useful when your app calls other APIs or microservices. You can see the full request path from one service to another with timings and bottlenecks.
### .NET Diagnostic Tools
When your app is on-air, you should know about the below tools. You know in airplanes there's _black box recorder_ which is used to understand why the airplane crashed. For .NET below are our *black box recorders*. They capture what happened without attaching a debugger.
| Tool | What It Does | When to Use |
| --------------------- | --------------------------------------- | ---------------------------- |
| **`dotnet-counters`** | Live metrics like CPU, GC, request rate | Monitor running apps |
| **`dotnet-trace`** | CPU sampling & performance traces | Find slow code |
| **`dotnet-gcdump`** | GC heap dumps (allocations) | Diagnose memory issues |
| **`dotnet-dump`** | Full process dumps | Investigate crashes or hangs |
| **`dotnet-monitor`** | HTTP service exposing all the above | Collect telemetry via API |
------
## 7) Build & Run .NET App in Docker the Right Way
![Docker](7.png)
A multi-stage build is a Docker technique where you use one image for building your app and another smaller image for running it. Why we do multi-stage build, because the .NET SDK image is big but has all the build tools. The .NET Runtime image is small and optimized for production. You copy only the published output from the build stage into the runtime stage.
```dockerfile
# build
FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build
WORKDIR /src
COPY . .
RUN dotnet restore
RUN dotnet publish -c Release -o /app/out -p:PublishTrimmed=true -p:PublishSingleFile=true -p:ReadyToRun=true
# run
FROM mcr.microsoft.com/dotnet/aspnet:9.0
WORKDIR /app
ENV ASPNETCORE_URLS=http://+:8080
EXPOSE 8080
COPY --from=build /app/out .
ENTRYPOINT ["./YourApp"] # or ["dotnet","YourApp.dll"]
```
I'll explain what these Docker file commands;
**Stage1: Build**
* `FROM mcr.microsoft.com/dotnet/sdk:9.0 AS build`
Uses the .NET SDK image including compilers and tools. The `AS build` name lets you reference this stage later.
* `WORKDIR /src`
Sets the working directory inside the container.
* `COPY . .`
Copies your source code into the container.
* `RUN dotnet restore`
Restores NuGet packages.
* `RUN dotnet publish ...`
Builds the project in **Release** mode, optimizes it for production, and outputs it to `/app/out`.
The flags;
* `PublishTrimmed=true` -> removes unused code
* `PublishSingleFile=true` -> bundles everything into one file
* `ReadyToRun=true` -> precompiles code for faster startup
**Stage 2: Run**
- `FROM mcr.microsoft.com/dotnet/aspnet:9.0`
Uses a lighter runtime image which no compiler, just the runtime.
- `WORKDIR /app`
Where your app will live inside the container.
- `ENV ASPNETCORE_URLS=http://+:8080`
Makes the app listen on port 8080 (and all network interfaces).
- `EXPOSE 8080`
Documents the port your container uses (for Docker/K8s networking).
- `COPY --from=build /app/out .`
Copies the published output from the **build stage** to this final image.
- `ENTRYPOINT ["./YourApp"]`
Defines the command that runs when the container starts. If you published as a single file, it’s `./YourApp`. f not, use `dotnet YourApp.dll`.
------
## 8) Security
![Security](8.png)
### HTTPS Everywhere Even Behind Proxy
Even if your app runs behind a reverse proxy like Nginx, Cloudflare or a load balancer, always enforce HTTPS. Why? Because internal traffic can still be captured if you don't use SSL and also cookies, HSTS, browser APIs require HTTPS. In .NET, you can easily enforce HTTPS like this:
```csharp
app.UseHttpsRedirection();
```
### Use HSTS in Production
HSTS (HTTP Strict Transport Security) tells browsers:
> Always use HTTPS for this domain — don’t even try HTTP again!
Once you set, browsers cache this rule, so users can’t accidentally hit the insecure version. You can easily enforce this as below:
```csharp
if (!app.Environment.IsDevelopment())
{
app.UseHsts();
}
```
When you use HSTS, it sends browser this HTTP header: ` Strict-Transport-Security: max-age=31536000; includeSubDomains`. Browser will remember this setting for 1 year (31,536,000 seconds) that this site must only use HTTPS. And `includeSubDomains` option applies the rule to all subdomains as well (eg: `api.abp.io`, `cdn.abp.io`, `account.abp.io` etc..)
### Store Secrets on Environment Variables or Secret Stores
Never store passwords, connection strings, or API keys in your code or Git. Then where should we keep them?
- Best/practical way is **Environment variables**. You can easily sett an environment variable in a Unix-like system as below:
- ```bash
export ConnectionStrings__Default="Server=...;User Id=...;Password=..."
```
- And you can easily access these environment variables from your .NET app like this:
- ```csharp
var conn = builder.Configuration.GetConnectionString("Default");
```
Or **Secret stores** like: Azure Key Vault, AWS Secrets Manager, HashiCorp Vault
### Add Rate-Limiting to Public Endpoints
Don't forget there'll be not naive guys who will use your app! We've many times faced this issue in the past on our public front-facing websites. So protect your public APIs from abuse, bots, and DDoS. Use rate-limiting!!! Stop brute-force attacks, prevent your resources from exhaustion...
In .NET, there's a built-in rate-limit feature for .NET (System.Threading.RateLimiting):
```csharp
builder.Services.AddRateLimiter(_ => _
.AddFixedWindowLimiter("default", options =>
{
options.PermitLimit = 100;
options.Window = TimeSpan.FromMinutes(1);
}));
app.UseRateLimiter();
```
- Also there's an open-source rate-limiting library -> [github.com/stefanprodan/AspNetCoreRateLimit](https://github.com/stefanprodan/AspNetCoreRateLimit)
- Another one -> [nuget.org/packages/Polly.RateLimiting](https://www.nuget.org/packages/Polly.RateLimiting)
### Secure Cookies
Cookies are often good targets for attacks. You must secure them properly otherwise you can face cookie stealing or CSRF attack.
```csharp
options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
options.Cookie.SameSite = SameSiteMode.Strict; // or Lax
```
- **`SecurePolicy = Always`** -> only send cookies over HTTPS
- **`SameSite=Lax/Strict`** -> prevent CSRF (Cross-Site Request Forgery)
- `Strict` = safest
- `Lax` = good balance for login sessions
------
## 9) Startup/Cold Start
![Cold Start / Startup](9.png)
### Keep Tiered JIT On
The **JIT (Just-In-Time) compiler** converts your app’s Intermediate Language (IL) into native CPU instructions when the code runs. _Tiered JIT_ means the runtime uses 2 stages of compilation. Actually this setting is enabled by default in modern .NET. So just keep it on.
1. **Tier 0 (Quick JIT):**
Fast, low-optimization compile → gets your app running ASAP.
(Used at startup.)
2. **Tier 1 (Optimized JIT):**
Later, the runtime re-compiles *hot* methods (frequently used ones) with deeper optimizations for speed.
### Use PGO (Profile-Guided Optimization)
PGO lets .NET learn from real usage of your app. It profiles which functions are used most often, then re-optimizes the build for that pattern. You can think of it as the runtime saying:
> I’ve seen what your app actually does... I’ll rearrange and optimize code paths accordingly.
In .NET 8+, you don’t have to manually enable PGO (Profile-Guided Optimization). The JIT collects runtime profiling data (e.g. which types are common, branch predictions) and uses it to generate more optimized code later. In .NET 9, PGO has been improved: the JIT uses PGO data for more patterns (like type checks / casts) and makes better decisions.
------
## 10) Graceful Shutdown
![Shutdown](10.png)
When we break up with our lover, we often argue and regret it later. When an application breaks up with an operating system, it should be done well 😘 ...
When your app stops, maybe you deploy a new version or Kubernetes restarts a pod... the OS sends a signal called `SIGTERM` (terminate).
A **graceful shutdown** means handling that signal properly, finishing what’s running, cleaning up, and exiting cleanly (like an adult)!
```csharp
var app = builder.Build();
var lifetime = app.Services.GetRequiredService<IHostApplicationLifetime>();
lifetime.ApplicationStopping.Register(() =>
{
// stop accepting, finish in-flight, flush telemetry
});
app.Run();
```
On K8s, set `terminationGracePeriodSeconds` and wire **readiness**/startup probes.
------
## 11) Load Test
![Load Test](11.png)
Sometimes arguing with our lover is good. We can see her/his face before marrying 😀 Use **k6** or **bombardier** and test with realistic payloads and prod-like limits. Don't be surprise later when your app is running on prod! These topics should be tested: `CPU %` , `Time in GC` , `LOH Allocations` , `ThreadPool Queue Length` and `Socket Exhaustion`.
### About K6
- A modern load testing tool, using Go and JavaScript.
- 29K stars on GitHub
- GitHub address: https://github.com/grafana/k6
### About Bombardier
- Fast cross-platform HTTP benchmarking tool written in Go.
- 7K stars on GitHub
- GitHub address: https://github.com/codesenberg/bombardier
[![Bombardier vs K6](11_1.png)](https://trends.google.com/trends/explore?cat=31&q=bombardier%20%2B%20benchmarking,k6%20%2B%20benchmarking)
## Summary
In summary, I listed 11 items for optimizing a .NET application for production; Covering build configuration, hosting setup, runtime behavior, data access, telemetry, containerization, security, startup performance and reliability under load. By applying the checklist from Part 1 and Part 2 of this series, leveraging techniques like trimmed releases, server GC, minimal payloads, pooled `DbContexts`, OpenTelemetry, multi-stage Docker builds, HTTPS enforcement, and proper shutdown handling—you’ll improve your app’s durability, scalability and maintainability under real-world traffic and production constraints. Each item is a checkpoint and you’ll be able to deliver a robust, high-performing .NET application ready for live users.
🎉 Want top-tier .NET performance without the headaches? Try [ABP Framework](https://abp.io?utm_source=alper-ebicoglu-performance-article) for best-performance and skip all the hustles of .NET app development.

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/cover-2.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 394 KiB

BIN
docs/en/Community-Articles/2025-10-17-Optimize-Your-App-For-Production/cover.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 394 KiB

356
docs/en/Community-Articles/2025-10-17-Top-10-Exception-Handling-Mistakes-in-DotNET/post.md

@ -0,0 +1,356 @@
# 💥 Top 10 Exception Handling Mistakes in .NET (and How to Actually Fix Them)
Every .NET developer has been there it's 3 AM, production just went down, and the logs are flooding in.
You open the error trace, only to find… nothing useful. The stack trace starts halfway through a catch block, or worse it's empty. Somewhere, an innocent-looking `throw ex;` or a swallowed background exception has just cost hours of sleep.
Exception handling is one of those things that seems simple on the surface but can quietly undermine an entire system if done wrong. Tiny mistakes like catching `Exception`, forgetting an `await`, or rethrowing incorrectly don't just break code; they break observability. They hide root causes, produce misleading logs, and make even well-architected applications feel unpredictable.
In this article, we'll go through the most common exception handling mistakes developers make in .NET and more importantly, how to fix them. Along the way, you'll see how small choices in your code can mean the difference between a five-minute fix and a full-blown production nightmare.
----------
## 🧨 1. Catching `Exception` (and Everything Else)
**The mistake:**
```csharp
try
{
// Some operation
}
catch (Exception ex)
{
// Just to be safe
}
```
**Why it's a problem:**
Catching the base `Exception` type hides all context including `OutOfMemoryException`, `StackOverflowException`, and other runtime-level issues that you should never handle manually. It also makes debugging painful since you lose the ability to treat specific failures differently.
**The right way:**
Catch only what you can handle:
```csharp
catch (SqlException ex)
{
// Handle DB issues
}
catch (IOException ex)
{
// Handle file issues
}
```
If you really must catch all exceptions (e.g., at a system boundary), **log and rethrow**:
```csharp
catch (Exception ex)
{
_logger.LogError(ex, "Unexpected error occurred");
throw;
}
```
> 💡 **ABP Tip:** In ABP-based applications, you rarely need to catch every exception at the controller or service level.
> The framework's built-in `AbpExceptionFilter` already handles unexpected exceptions, logs them, and returns standardized JSON responses automatically keeping your controllers clean and consistent.
----------
## 🕳️ 2. Swallowing Exceptions Silently
**The mistake:**
```csharp
try
{
DoSomething();
}
catch
{
// ignore
}
```
**Why it's a problem:**
Silent failures make debugging nearly impossible. You lose stack traces, error context, and sometimes even awareness that something failed at all.
**The right way:**
Always log or rethrow, unless you have a very specific reason not to:
```csharp
try
{
_cache.Remove(key);
}
catch (Exception ex)
{
_logger.LogWarning(ex, "Failed to clear cache key {Key}", key);
}
```
> 💡 **ABP Tip:** Since ABP automatically logs all unhandled exceptions, it's often better to let the framework handle them. Only catch exceptions when you want to enrich logs or add custom business logic before rethrowing.
----------
## 🌀 3. Using `throw ex;` Instead of `throw;`
**The mistake:**
```csharp
catch (Exception ex)
{
Log(ex);
throw ex;
}
```
**Why it's a problem:**
Using `throw ex;` resets the stack trace you lose where the exception actually occurred. This is one of the biggest causes of misleading production logs.
**The right way:**
```csharp
catch (Exception ex)
{
Log(ex);
throw; // preserves stack trace
}
```
----------
## ⚙️ 4. Wrapping Everything in Try/Catch
**The mistake:**
Developers sometimes wrap _every function_ in try/catch “just to be safe.”
**Why it's a problem:**
This clutters your code and hides the real source of problems. Exception handling should happen at **system boundaries**, not in every method.
**The right way:**
Handle exceptions at higher levels (e.g., middleware, controllers, background jobs). Let lower layers throw naturally.
> 💡 **ABP Tip:** The ABP Framework provides a top-level exception pipeline via filters and middleware. You can focus purely on your business logic ABP automatically translates unhandled exceptions into standardized API responses.
----------
## 📉 5. Using Exceptions for Control Flow
**The mistake:**
```csharp
try
{
var user = GetUserById(id);
}
catch (UserNotFoundException)
{
user = CreateNewUser();
}
```
**Why it's a problem:**
Exceptions are expensive and should represent _unexpected_ states, not normal control flow.
**The right way:**
```csharp
var user = GetUserByIdOrDefault(id) ?? CreateNewUser();
```
----------
## 🪓 6. Forgetting to Await Async Calls
**The mistake:**
```csharp
try
{
DoSomethingAsync(); // missing await!
}
catch (Exception ex)
{
...
}
```
**Why it's a problem:**
Without `await`, the exception happens on another thread, outside your `try/catch`. It never gets caught.
**The right way:**
```csharp
try
{
await DoSomethingAsync();
}
catch (Exception ex)
{
_logger.LogError(ex, "Error during async operation");
}
```
----------
## 🧵 7. Ignoring Background Task Exceptions
**The mistake:**
```csharp
Task.Run(() => SomeWork());
```
**Why it's a problem:**
Unobserved task exceptions can crash your process or vanish silently, depending on configuration.
**The right way:**
```csharp
_ = Task.Run(async () =>
{
try
{
await SomeWork();
}
catch (Exception ex)
{
_logger.LogError(ex, "Background task failed");
}
});
```
----------
## 📦 8. Throwing Generic Exceptions
**The mistake:**
```csharp
throw new Exception("Something went wrong");
```
**Why it's a problem:**
Generic exceptions carry no semantic meaning. You can't catch or interpret them specifically later.
**The right way:**
Use more descriptive types:
```csharp
throw new InvalidOperationException("Order is already processed");
```
> 💡 **ABP Tip:** In ABP applications, you can throw a `BusinessException` or `UserFriendlyException` instead.
> These support structured data, error codes, localization, and automatic HTTP status mapping:
>
> ```csharp
> throw new BusinessException("App:010046")
> .WithData("UserName", "john");
>
> ```
>
> This integrates with ABP's localization system, letting your error messages be translated automatically based on the error code.
----------
## 🪞 9. Losing Inner Exceptions
**The mistake:**
```csharp
catch (Exception ex)
{
throw new CustomException("Failed to process order");
}
```
**Why it's a problem:**
You lose the inner exception and its stack trace the real reason behind the failure.
**The right way:**
```csharp
catch (Exception ex)
{
throw new CustomException("Failed to process order", ex);
}
```
> 💡 **ABP Tip:** ABP automatically preserves and logs inner exceptions (for example, inside `BusinessException` chains). You don't need to add boilerplate to capture nested errors just throw them properly.
----------
## 🧭 10. Missing Global Exception Handling
**The mistake:**
Catching exceptions manually in every controller.
**Why it's a problem:**
It creates duplicated logic, inconsistent responses, and gaps in logging.
**The right way:**
Use middleware or a global exception filter:
```csharp
app.UseExceptionHandler("/error");
```
> 💡 **ABP Tip:** ABP already includes a complete global exception system that:
>
> - Logs exceptions automatically
>
> - Returns a standard `RemoteServiceErrorResponse` JSON object
>
> - Maps exceptions to correct HTTP status codes (e.g., 403 for business rules, 404 for entity not found, 400 for validation)
>
> - Allows customization through `AbpExceptionHttpStatusCodeOptions`
> You can even implement an `ExceptionSubscriber` to react to certain exceptions (e.g., send notifications or trigger audits).
>
----------
## 🧩 Bonus: Validation Is Not an Exception
**The mistake:**
Throwing exceptions for predictable user input errors.
**The right way:**
Use proper validation instead:
```csharp
[Required]
public string UserName { get; set; }
```
> 💡 **ABP Tip:** ABP automatically throws an `AbpValidationException` when DTO validation fails.
> You don't need to handle this manually ABP formats it into a structured JSON response with `validationErrors`.
----------
## 🧠 Final Thoughts
Exception handling isn't just about preventing crashes it's about making your failures **observable, meaningful, and recoverable**.
When done right, your logs tell a story: _what happened, where, and why_.
When done wrong, you're left staring at a 3 AM mystery.
By avoiding these common pitfalls and taking advantage of frameworks like ABP that handle the heavy lifting you'll spend less time chasing ghosts and more time building stable, predictable systems.

1174
docs/en/Community-Articles/2025-10-20-The-ASP-DotNET-Core-Dependency-Injection System/post.md

File diff suppressed because it is too large

102
docs/en/Community-Articles/2025-10-20-Uncovering-ABP-Hidden-Magic/Post.md

@ -0,0 +1,102 @@
# Uncovering ABP’s Hidden Magic: Supercharging ASP.NET Core Development
Experienced back-end developers often approach new frameworks with healthy skepticism. But many who try the ABP Framework quickly notice something different: things “just work” with minimal boilerplate. There’s a good reason ABP can feel magical – it silently handles a host of tedious tasks behind the scenes. In this article, we’ll explore how ABP’s out-of-the-box features and modular architecture dramatically boost productivity. We’ll compare with plain ASP.NET Core where relevant, so you can appreciate what ABP is doing for you under the hood.
## Beyond the Basics: Why ABP Feels Magical
ABP isn’t a typical library; it’s a full application framework that goes beyond the basics. From the moment you start an ABP project, a lot is happening automatically. Have you ever built an ASP.NET Core app and spent time wiring up cross-cutting concerns like error handling, logging, security tokens, or multi-tenancy? With ABP, much of that comes pre-configured. You might find that you write just your business logic, and ABP has already enabled security, transactions, and even APIs for you by convention. This can be disorienting at first (“Where’s the code that does X?”) until you realize ABP’s design is doing it for you, in line with best practices.
For example, ABP completely automates CSRF (anti-forgery) protection and it works out-of-the-box without any configuration. In a plain ASP.NET Core project, you’d have to add anti-forgery tokens to your views or enable a global filter and manually include the token in AJAX calls. ABP’s startup template already includes a global antiforgery filter and even sets up the client-side code to send the token on each request, without you writing a line. This kind of “invisible” setup is repeated across many areas. ABP’s philosophy is to take care of the plumbing – like unit of work, data filters, audit logging, etc. – so you can focus on the real code. It feels magical because things that would normally require explicit code or packages in ASP.NET Core are just handled. As we peel back the layers in the next sections, you’ll see how ABP pulls off these tricks.
## Zero to Hero: Rapid Application Development with ABP
One of the most striking benefits of ABP is how quickly you can go from zero to a fully functional application – it’s a true rapid application development platform. With ASP.NET Core alone, setting up a new project with identity management, localization, an API layer, and a clean architecture can be a day’s work or more. In contrast, ABP’s startup templates give you a solution with all those pieces pre-wired. You can create a new ABP project (using the ABP CLI or ABP Studio) and run it, and you already have: user login and registration, role-based permission management, an admin UI, a REST API layer with Swagger, and a clean domain-driven code structure. It’s essentially a jump-start that takes you from zero to hero in record time.
Rapid development is further enabled by ABP’s coding model. Define an entity and an application service, and ABP can generate the REST API endpoints for you automatically (via Conventional Controllers). You don’t need to write repetitive controllers that just call the service; ABP’s conventions map your service methods to HTTP verbs and routes by naming convention. For instance, a method name `GetListAsync()` in an `AppService` becomes an HTTP `GET` to `/api/app/your-entity` without extra attributes. The result: you implement application logic once in the application layer, and ABP instantly exposes it as an API (and even provides client proxies for UI).
The tooling in the ABP ecosystem multiplies this productivity. The ABP Suite tool, for example, allows you to visually design entities and then generate a full-stack CRUD page for your entities in seconds, complete with UI forms, validation, DTOs, application services, and even unit tests. The generated code follows ABP’s best practices (layered architecture, proper authorization checks, etc.), so you’re not creating a maintenance headache. You get a working feature out-of-the-box and can then tweak it to your needs. All these accelerators mean you can deliver features at a higher velocity than ever, turning a blank project into a real application with minimal grunt work.
## Modular Architecture: Building Like Digital Lego
Perhaps the greatest strength of ABP is its modular architecture. Think of modules as building blocks – “digital Lego” pieces – that you can snap together to compose your application. ABP itself is built on modules (for example, Identity, Audit Logging, Language Management, etc.), and you can develop your own modules as well. This design encourages separation of concerns and reusability. Need a certain functionality? Chances are, ABP has a module for it – just plug it in, and it works seamlessly with the others.
With plain ASP.NET Core, setting up a modular system requires a lot of upfront design. ABP, however, “is born to be a modular application development structure”, where every feature is compatible with modular development by default. The framework ensures that each module can encapsulate its own domain, application services, database migrations, UI pages, etc., without tight coupling. For example, the ABP Identity module provides all the user and role management functionality (built atop ASP.NET Core Identity), the SaaS module provides multi-tenant management, the Audit Logging module records user activities, and so on. You can include these modules in your project, gaining enterprise-grade functionality in literally one line of configuration. As the official documentation puts it, ABP provides “a lot of re-usable application modules like payment, chat, file management, audit log reporting… All of these modules are easily installed into your solution and directly work.” This is a huge time saver – you’re not reinventing the wheel for common requirements.
The Lego-like nature also means you can remove or swap pieces without breaking the whole. If a built-in module doesn’t meet your needs, you can extend it or replace it (we’ll talk about customization later). Modules can even be maintained as separate packages, enabling teams to develop features in isolation and share modules across projects. Ultimately, ABP’s modularity gives your architecture a level of flexibility and organization that plain ASP.NET Core doesn’t provide out-of-the-box. It’s a solid foundation for either monolithic applications or microservice systems, as you can start with a modular monolith and later split modules into services if needed. In short, ABP provides the architectural “bricks” – you design the house.
## Out-of-the-Box Features that Save Weeks of Work
Beyond the big building blocks, ABP comes with a plethora of built-in features that operate behind the scenes to save you time. These are things that, in a non-ABP project, you would likely spend days or weeks implementing and fine-tuning – but ABP gives them to you on Day 1. Here are some of the key hidden gems ABP provides out-of-the-box:
- CSRF Protection: As mentioned earlier, ABP automatically enables anti-forgery tokens for you. You get robust CSRF/XSRF protection by default – the server issues a token cookie and expects a header on modify requests, all handled by ABP’s infrastructure without manual setup. This means your app is defended against cross-site request forgery with essentially zero effort on your part.
- Automated Data Filtering: ABP uses data filters to transparently apply common query conditions. For example, if an entity implements `ISoftDelete`, it will not be retrieved in queries unless you explicitly ask for deleted data. ABP automatically sets `IsDeleted=true` instead of truly deleting and filters it out on queries, so you don’t accidentally show or modify soft-deleted records. Similarly, if an entity implements `IMultiTenant`, ABP will “silently in the background” filter all queries to the current tenant and fill the `TenantId` on new records – no need to manually add tenant clauses to every repository query. These filters (and others) are on by default and can be toggled when needed, giving you multi-tenancy and soft delete behavior out-of-the-box.
- Concurrency Control: In enterprise apps, it’s important to handle concurrent edits to avoid clobbering data. ABP makes this easy with an optimistic concurrency system. If you implement `IHasConcurrencyStamp` on an entity, ABP will automatically set a GUID stamp on insert and check that stamp on updates to detect conflicts, throwing an exception if the record was changed by someone else. In ASP.NET Core EF you’d set up a RowVersion or concurrency token manually – ABP’s built-in approach is a ready-to-use solution to ensure data consistency.
- Data Seeding: Most applications need initial seed data (like an admin user, initial roles, etc.). ABP provides a modular data seeding system that runs on application startup or during migration. You can implement an `IDataSeedContributor` and ABP will automatically discover and execute it as part of the seeding process. Different modules add their own seed contributors (for example, the Identity module seeds the admin user/role). This system is database-independent and even works in production deployments (the templates include a DbMigrator tool to apply migrations and seed data). It’s more flexible than EF Core’s native seeding and saves you writing custom seeding scripts.
- Audit Logging: ABP has an integrated auditing mechanism that logs details of each web request. By default, an audit log is created for each API call or MVC page hit, recording who did what and when. It captures the URL and HTTP method, execution duration, the user making the call, the parameters passed to application services, any exceptions thrown, and even entity changes saved to the database during the request. All of this is saved automatically (for example, into the AbpAuditLogs table if using EF Core). The startup templates enable auditing by default, so you have an audit trail with no extra coding. In a vanilla ASP.NET Core app, you’d have to implement your own logging to achieve this level of detail.
- Unit of Work & Transaction Management: ABP implements the Unit of Work pattern globally. When you call a repository or an application service method, ABP will automatically start a UOW (database transaction) for you if one isn’t already running. It will commit on success or roll back on error. By convention, all app service methods, controller actions, and repository methods are wrapped in a UOW – so you don’t explicitly call SaveChanges() or begin transactions in most cases. For example, if you create or update multiple entities in an app service method, they either all succeed or all fail as a unit. This behavior is there “for free”, whereas in raw ASP.NET Core you’d be writing try/catch and transaction code around such operations. (ABP even avoids opening transactions on read-only GET requests by default for performance.)
- Global Exception Handling: No need to write a global exception filter – ABP provides one. If an unhandled exception occurs in an API endpoint, ABP’s exception handling system catches it and returns a standardized error response in JSON. It also maps known exception types to appropriate HTTP status codes and can localize error messages. This means your client applications always get a clean, consistent error format (with an error code, message, validation details, etc.) instead of ugly stack traces or HTML error pages. Internally, ABP logs the error details and hides the sensitive info from the client by default. Essentially, you get production-ready error handling without writing it yourself.
- Localization & Multi-Language Support: ABP’s localization system is built on the .NET localization extension but adds convenient enhancements. It automatically determines the user’s language/culture for each request (by checking the browser or tenant settings) and you can define localization resources in JSON files easily. ABP supports database-backed translations via the Language Management module as well. From day one, your app is ready to be translated – even exception messages and validation errors are localization-friendly. The default project template sets up a default resource and uses it for all framework-provided texts, meaning things like error messages or menu items are already localized (and you can add new languages through the UI if you include the module). In short, ABP bakes in multi-lingual capabilities so you don’t have to internationalize your app from scratch.
- Background Jobs: Need to run tasks in the background (e.g. send emails, generate reports) without blocking the user? ABP has a built-in background job infrastructure. You can simply implement a job class and enqueue it via `IBackgroundJobManager`. By default, jobs are persisted and executed, and ABP has providers to integrate with popular systems like Hangfire, RabbitMQ and Quartz if you need scalability. For example, sending an email after a user registers can be offloaded to a background job with one method call. ABP will handle retries on failure and storing the job info. This saves you the effort of configuring a separate job runner or scheduler – it’s part of the framework.
- Security & Defaults: ABP comes with sensible security defaults. It’s integrated with ASP.NET Core Identity, so password policies, lockout on multiple failed logins, and other best practices are in place by default. The framework also adds standard security headers to HTTP responses (against XSS, clickjacking, etc.) through its startup configuration. Additionally, ABP’s permission system is pre-configured: every module brings its own permission definitions, and you can easily check permissions with an attribute or method call. There’s even a built-in Permission Management UI (if you include the module) where you can grant or revoke permissions per role or user at runtime. All these defaults mean a lot of the “boring” but critical security work is done for you.
- Paging & Query Limiting: ABP encourages efficient data access patterns. For list endpoints, the framework DTOs usually include paging parameters (MaxResultCount, SkipCount), and if you don't specify them, ABP will assume default values (often 10). ABP also enforces an upper limit on how many records can be requested in a single call, preventing potential performance issues from overly large queries. This protects your application from accidentally pulling thousands of records in one go. Of course, you can configure or override these limits, but the safe defaults are there to protect your application.
That’s a long list – and it’s not even exhaustive – but the pattern is clear. ABP spares you from writing a lot of infrastructure and “glue” code. And if you do need multi-tenancy (or any of these advanced features), the time savings grow even more. These out-of-the-box capabilities let you focus on your business logic, since the baseline features are already in place. Next, let’s zoom in on a couple of these areas (like multi-tenancy and security) that typically cause headaches in pure ASP.NET Core but are a breeze with ABP.
## Seamless Multi-Tenancy: Scaling Without the Headaches
Multi-tenant architecture – supporting multiple isolated customers (tenants) in one application – is notoriously tricky to implement from scratch. You have to partition data per tenant, ensure no cross-tenant data leaks, manage connection strings if using separate databases, and adapt authentication/authorization to be tenant-aware. ABP Framework makes multi-tenancy almost trivial in comparison.
Out of the box, ABP supports both approaches to multi-tenancy: single database with tenant segregation and separate databases per tenant, or even a hybrid of the two. If you go the single database route, as many SaaS apps do for simplicity, ABP will ensure every entity that implements the tenant interface (`IMultiTenant`) gets a `TenantId` value and is automatically filtered. As we touched on earlier, you don’t have to manually add `.Where(t => t.TenantId == currentTenant.Id)` on every query – ABP’s data filter does that behind the scenes based on the logged-in user’s tenant. If a user from Tenant A tries to access Tenant B’s data by ID, they simply won’t find it, because the filter is in effect on all repositories. Similarly, when saving data, ABP sets the `TenantId` for you. This isolation is enforced at the ORM level by ABP’s infrastructure.
For multiple databases, ABP’s SaaS (Software-as-a-Service) module handles tenant management. At runtime, the framework can switch the database connection string based on the tenant context. In the ABP startup template, there’s a “tenant management” UI that lets an admin add new tenants and specify their connection strings. If a connection string is provided, ABP will use that database for that tenant’s data. If not, it falls back to the default shared database. Remarkably, from a developer’s perspective, the code you write is the same in both cases – ABP abstracts the difference. In practice, you just write repository queries as usual; ABP will route those to the appropriate place and filter as needed.
Another pain point that ABP solves is making other subsystems tenant-aware. For example, ASP.NET Core Identity (for user accounts) isn’t multi-tenant by default, and neither is Keycloak, IdentityServer or OpenIddict (for authentication). ABP takes care of configuring these to work in a tenant context. When a user logs in, they do so with a tenant domain or tenant selection, and the identity system knows about the tenant. Permissions in ABP are also tenant-scoped by default – a tenant admin can only manage roles/permissions within their tenant, for instance. ABP’s modules are built to respect tenant boundaries out-of-the-box.
What does all this mean for you? It means you can offer a multi-tenant SaaS solution without writing the bulk of the isolation logic. Instead of spending weeks on multi-tenancy infrastructure, you essentially flip a switch in ABP (enable multi-tenancy, use the SaaS module) and focus on higher-level concerns.
## Security That Works Without the Pain
Security is one area you do not want to get wrong. With plain ASP.NET Core, you have great tools (Identity, etc.) at your disposal, but a lot of configuration and integration work to tie them together in a full application. ABP takes the sting out of implementing security by providing a comprehensive, pre-integrated security model.
To start, ABP’s application templates include the Identity Module, which is a ready-made integration of ASP.NET Core Identity (the membership system) with ABP’s framework. You get user and role entities extended to fit in ABP’s domain model, and a UI for user and role management. All the heavy lifting of setting up identity tables, password hashing, email confirmation, two-factor auth, etc. is done. The moment you run an ABP application, you can log in with the seeded admin account and manage users and roles through a built-in administration page. This would take significant effort to wire up yourself in a new ASP.NET Core app; ABP gives it to you out-of-the-box.
Permission management is another boon. In an ABP solution, you don’t have to hard-code what each role can do – instead, ABP provides a declarative way to define permissions and a UI to assign those permissions to roles or users. The Permission Management module’s UI allows dynamic granting/revoking of permissions. Under the hood, ABP’s authorization system will automatically check those permissions when you annotate your application services or controllers with [Authorize] and a policy name (the policy maps to a permission). For example, you might declare a permission Inventory.DeleteProducts. In your ProductAppService’s DeleteAsync method, you add [Authorize("Inventory.DeleteProducts")]. ABP will ensure the current user has that permission (through their roles or direct assignment) before allowing the method to execute. If not, it throws a standardized authorization exception. This is standard ASP.NET Core policy-based auth, but ABP streamlines defining and managing the policies by its permission system. The result: secure by default – it’s straightforward to enforce role-based access control throughout your application, and even non-developers (with access to the admin UI) can adjust permissions as requirements evolve.
We already discussed CSRF protection, but it’s worth reiterating in the security context: ABP saves you from common web vulnerabilities by enabling defenses by default. Anti-forgery tokens are automatic, and output encoding (to prevent XSS) is naturally handled by using Razor Pages or Angular with proper binding (framework features that ABP leverages). ABP also sets up ASP.NET Core’s Data Protection API for things like cookie encryption and CSRF token generation behind the scenes in its startup, so you get a proper cryptographic key management for free.
Another underappreciated aspect is exception shielding. In development, you want to see detailed errors, but in production you should not reveal internal details (stack traces, etc.) to the client. ABP’s exception filter will output a generic error message to the client while logging the detailed exception on the server. This prevents information leakage that attackers could exploit, without you having to configure custom middleware or filters.
On the topic of authentication: ABP supports modern authentication scenarios too. If you want to build a microservice or single-page app (SPA) architecture, ABP provides modules for OpenID Connect and OAuth2 protocol implementations. The ABP Commercial version even provides an OpenIddict setup out-of-the-box for issuing JWTs to SPAs or mobile apps. This means you can stand up a secure token service and resource servers with minimal configuration. With ABP, much of the configuration (clients, scopes, grants) is abstracted by the framework.
In short, ABP’s approach to security is holistic and follows the mantra of secure by default. New ABP developers are often pleasantly surprised that they didn’t have to spend days on user auth or protecting API endpoints – it’s largely handled. Of course, you still design your authorization logic (defining who can do what), but ABP provides the scaffolding to enforce it consistently. The painful parts of security – getting the plumbing right – are taken care of, so you can focus on the policies and rules that matter for your domain. This dramatically lowers the risk of security holes compared to rolling it all yourself.
## Customization Without Chaos
With all this magic happening automatically, you might wonder: “What if I need to do it differently? Can I customize or override ABP’s behavior?” The answer is a resounding yes. ABP is designed with extension points and configurability in mind, so you can change the defaults without hacking the framework. This is important for keeping your project maintainable – you get ABP’s benefits, but you’re not boxed in when requirements demand a change.
One way ABP enables customization is through its powerful dependency injection system and the modular structure. Because each feature is delivered via services (interfaces and classes) in DI, you can replace almost any ABP service with your own implementation if needed. For example, if you want to change how the IdentityUserAppService (the service behind user management) works, you can create your own class inheriting or implementing the same interface, and register it with `Dependency(ReplaceServices = true)`. ABP will start using your class in place of the original. This is an elegant way to override behavior without modifying ABP’s source – keeping you on the upgrade path for new versions. ABP’s team intentionally makes most methods virtual to support overriding in derived classes. This means you can subclass an ABP application service or domain service and override just the specific method you need to change, rather than writing a whole service from scratch.
Beyond swapping out services, ABP offers configuration options for its features. Virtually every subsystem has an options class you can configure in your module startup. Not liking the 10-item default page size? You can change the default MaxResultCount. Want to disable a filter globally? You can toggle, say, soft-delete filtering off by default using `AbpDataFilterOptions`. Need to turn off auditing for certain operations? Configure `AbpAuditingOptions` to ignore them. These options give you a lot of control to tweak ABP’s behavior. And because they’re central configurations, you aren’t scattering magic numbers or settings throughout your code – it’s a structured approach to customization.
Another area is UI and theming. ABP’s UI (if you use the integrated UI) is also modular and replaceable. You can override Razor components or pages from a module by simply re-declaring them in your web project. For instance, if you want to modify the login page from the Account module, you can add a Razor page with the same path in your web layer – ABP will use yours instead of the default. The documentation has guidance on how to override views, JavaScript, CSS, etc., in a safe manner for Angular, Blazor, and MVC. The LeptonX theme that ABP uses can be customized via SCSS variables or entirely new theme derivations. The key point is, you’re never stuck with the “out-of-the-box” look or logic if it doesn’t fit your needs. ABP gives you the foundation, and you’re free to build on top of it or change it.
The best part? These customizations stay clean and organized. ABP's extension patterns prevent your project from becoming a mess of patches. When ABP releases updates, your overrides remain intact – no more copy-pasting framework code or dealing with merge conflicts. You get ABP's smart defaults plus the freedom to customize when needed.
## Ecosystem Power: ABP’s Tools, Templates, and Integrations
ABP is more than just a runtime framework; it’s surrounded by an ecosystem of tools and libraries that amplify productivity. We’ve touched on a few (like the ABP Suite code generator), but let’s look at the broader ecosystem that comes with ABP.
- Project Templates: ABP provides multiple startup templates (via the ABP CLI or Studio) for different architectures – from a simple monolithic web app to a layered modular monolith, or even a microservice-oriented solution with multiple projects pre-configured. These templates are not empty skeletons; they include working examples of authentication, a UI theme, navigation, and so on for your own modules. The microservice template, for instance, sets up separate identity, administration, and SaaS services with communication patterns already wired. Using these templates can save you a huge amount of setup time and ensure you follow best practices from the get-go.
- ABP CLI: The command-line tool abp is a developer’s handy companion. With it, you can generate new solutions or modules, add package references, update your ABP version, and even client proxy generations with simple commands.
- ABP Studio: It is a cross-platform desktop environment designed to make working with ABP solutions smoother and more insightful. It provides a unified UI to create, run, monitor, and manage your ABP projects – whether you're building a monolith or a microservice system. With features like a real-time Application Monitor, Solution Runner, and Kubernetes integration, it brings operational visibility and ease-of-use to development workflows. Studio also includes tools for managing modules, packages, and even launching integrated tools like ABP Suite – all from a single place. Think of it as a control center for your ABP solutions.
- ABP Suite: It is a powerful visual tool (included in PRO licenses) that helps you generate full-stack CRUD pages in minutes. Define your entities, their relationships, and hit generate – ABP Suite scaffolds everything from the database model to the HTTP APIs, application services, and UI components. It supports one-to-many and many-to-many relationships, master-detail patterns, and even lets you generate from existing database tables. Developers can customize the generated code using predefined hook points that persist across regenerations.
- 3rd-Party Integrations: Modern applications often need to integrate with messaging systems, distributed caching, search engines, etc. ABP recognizes this and provides integration packages for many common technologies. Want to use RabbitMQ for event bus or background jobs? ABP has you covered. The same goes for others: ABP has modules or packages for Redis caching, Kafka distributed event bus, SignalR real-time hubs, Twilio SMS, Stripe payments, and more. Each integration is done in a way that it feels like a natural extension of the ABP environment (for example, using the same configuration system and dependency injection). This saves you from writing repetitive integration code or dealing with each library’s nuances in every project.
- UI Themes and Multi-UI Support: ABP comes with a modern default theme (LeptonX) for web applications, and it supports Angular, MVC/Razor Pages and Blazor out-of-the-box. If you prefer Angular for frontend, ABP offers an Angular UI package that works with the same backend. There’s also support for mobile via React Native or MAUI templates. The ability to switch UI front-ends (or even support multiple simultaneously, e.g. an Angular SPA and a Blazor server app using the same API) is facilitated by ABP’s API and authentication infrastructure. This dramatically reduces the friction when setting up a new client application – you don’t have to hand-roll API clients or auth flows.
- Community and Samples: While not a tool per se, the ABP community is part of the ecosystem and adds a lot of value. There are official sample projects (like eShopOnAbp, a full microservice reference application) and many community-contributed modules on GitHub. The consistency of ABP’s structure means community modules or examples are easier to understand and plug in. Being in a community where “everyone follows similar coding styles and principles” means code and knowledge are highly transferable. Developers share open source ABP modules (for example, there are community modules for things like blob storage management, setting UI, React frontend support, etc., beyond the official ones). This network effect is an often overlooked part of the ecosystem: as ABP’s adoption grows, so do the resources you can draw on, from Q&A to reusable code.
In summary, ABP’s ecosystem provides a full-platform experience. It’s not just the core framework, but also the tooling to work with that framework efficiently and the integrations to connect it with the wider tech world. By using ABP, you’re not piecing together disparate tools – you have a coherent set of solutions designed to work in concert. This is the kind of ecosystem that traditionally only large enterprises or opinionated tech stacks provided, but ABP makes it accessible in the .NET open-source space. It supercharges development in a way that goes beyond just writing code faster; it’s about having a robust infrastructure around your code, so you can deliver more value with less guesswork.
## Developer Happiness: The Hidden Productivity Boost
All these features and time-savers aren’t just about checking off technical boxes – they have a profound effect on developer happiness and productivity. When a framework handles the heavy lifting and enforces good practices, developers can spend more time on interesting problems (and less on boilerplate or bug-hunting). ABP’s “hidden” features – the things that work without you even noticing – contribute to a less stressful development experience.
Think about the common sources of frustration in back-end development: security holes that come back to bite you, race conditions or transaction bugs, deployment issues because some configuration was missed, writing the same logging or exception handling code in every project… ABP’s approach preempts many of these. There’s confidence in knowing that the framework has built-in solutions for common pitfalls. For instance, you’re less likely to have a data inconsistency bug because ABP’s unit of work ensured all your DB operations were atomic. This confidence means developers can focus on delivering features rather than constantly firefighting or re-architecting core pieces.
Another aspect of developer happiness is consistency. ABP provides a uniform structure – every module has the same layering (Domain, Application, etc.), every web endpoint returns a standard response, and so on. Once you learn the patterns, you can navigate and contribute to any part of an ABP application with ease. New team members or even outside contributors ramp up faster because the project structure is familiar (it’s the ABP structure). This reduces the bus factor and onboarding time on teams – a source of relief for developers and managers alike.
Moreover, by taking away a lot of the “yak shaving” (the endless setup tasks), ABP lets you as a developer spend your energy on creative problem-solving and delivering value. It’s simply more fun to develop when you can swiftly implement a feature without being bogged down in plumbing code. The positive feedback loop of having working features quickly (thanks to things like ABP Suite, or just the rapid scaffolding of ABP) can be very motivating. It feels like you have an expert co-pilot who has already wired the security system, laid out the architecture, and packed the toolkit with everything you need – so you can drive the project forward confidently.
Finally, the community support adds to this happiness. There’s a thriving Discord server and forum where ABP developers help each other. Since ABP standardizes a lot, advice from one person’s experience often applies directly to your scenario. That sense of not being alone when you hit a snag – because others likely encountered and solved it – reduces anxiety and speeds up problem resolution. It’s the kind of developer experience where things “just work,” and when they occasionally don’t, you have a clear path to figure it out (good docs, support, community). In the daily life of a software developer, this can make a huge difference.
In conclusion, ABP’s multitude of behind-the-scenes features are not about making the framework look impressive on paper – they’re about making you, the developer, more productive and happier in your job. By handling the boring, complex, or repetitive stuff, ABP lets you focus on building great software. It’s like having a teammate who has already done half the work before you even start coding. When you combine that with ABP’s extensibility and strong foundation, you get a framework that not only accelerates development but also encourages you to do things the right way. For experienced engineers and newcomers alike, that can indeed feel a bit like magic. But now that we’ve uncovered the “magic tricks” ABP is doing under the hood, you can fully appreciate how it all comes together – and decide if this framework’s approach aligns with your goals of building applications faster, smarter, and with fewer headaches. Chances are, once you experience the productivity boost of ABP, you won’t want to go back. Happy coding!

BIN
docs/en/Community-Articles/2025-10-20-Uncovering-ABP-Hidden-Magic/cover-image.jpg

Binary file not shown.

After

Width:  |  Height:  |  Size: 77 KiB

7
docs/en/apps/volo-docs.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "VoloDocs simplifies documentation creation with GitHub integration, supporting Markdown, versioning, and collaborative editing across platforms."
}
```
# VoloDocs
## What is VoloDocs?

7
docs/en/cli/build-command.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to efficiently build .NET projects with the ABP Framework's build command, handling complex dependencies and configurations seamlessly."
}
```
# Build Command
Building a .NET project is hard when the project references a project reference outside of the solution or even from a different GIT repository. This command builds a GIT repository and it's depending repositories or a single .NET solution File. In order ```build``` command to work, its **executing directory** or passed ```--working-directory``` parameter's directory must contain one of;

7
docs/en/cli/differences-between-old-and-new-cli.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Discover the differences between the old and new ABP CLI, including features and commands, to enhance your ABP development experience."
}
```
# Old ABP CLI vs New ABP CLI
ABP CLI (Command Line Interface) is a command line tool to perform some common operations for ABP based solutions or ABP Studio features. With **v8.2+**, the old/legacy ABP CLI has been replaced with a new [CLI](index.md) system to align with the new templating system and [ABP Studio](../studio/index.md). Also, some superior features/commands have been introduced with the new CLI, such as `kube-connect` and `kube-intercept` commands.

30
docs/en/cli/index.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Discover how to install and use the new ABP CLI for streamlined operations in ABP-based solutions, enhancing your development experience!"
}
```
# ABP CLI
ABP CLI (Command Line Interface) is a command line tool to perform some common operations for ABP based solutions or ABP Studio features.
@ -288,30 +295,39 @@ abp new-package --name Acme.BookStore.Domain --template lib.domain
* `--template` or `-t`: Specifies the template name. This parameter doesn't have a default value and must be set. Available templates and their sub-options:
* `lib.class-library`
* `lib.domain-shared`
* `--add-localization`: Includes default localization configuration & language files.
* `lib.domain`
* `--add-settings`: Includes default settings configuration.
* `--add-db-properties`: Includes the default Database Properties class.
* `--add-domain-shared`: Includes an additional Domain Shared package.
* `lib.application-contracts`
* `lib.application`
* `--with-automapper`: Adds automapper configuration.
* `--add-mapperly`: Adds Mapperly configuration.
* `--add-application-contracts`: Includes an additional contracts package.
* `lib.ef`
* `--include-migrations`: Allows migration operations on this package.
* `--connection-string-name`: Default value is the last part of the package's namespace (or package name simply).
* `--connection-string`: Connection string value. Defaut value is null. You can set it alter. **Note:** When specifying the connection string, make sure to enclose it in double quotes, for example: `--connection-string "Server=localhost;Database=MyProjectName;Trusted_Connection=True"`.
* `--connection-string`: Connection string value. The default value is null. You can set it later. **Note:** When specifying the connection string, make sure to enclose it in double quotes, for example: `--connection-string "Server=localhost;Database=MyProjectName;Trusted_Connection=True"`.
* `lib.mongodb`
* `lib.http-api`
* `lib.http-api-client`
* `lib.mvc`
* `--add-mapperly`: Adds Mapperly configuration.
* `lib.blazor`
* `--add-mapperly`: Adds Mapperly configuration.
* `--add-menu-contributors`: Includes default menu contributors.
* `lib.blazor-wasm`
* `lib.blazor-server`
* `host.http-api`
* `--with-serilog`: Includes Serilog configuration.
* `--with-swagger`: Includes Swagger configuration.
* `--add-serilog`: Includes Serilog configuration.
* `--add-swagger`: Includes Swagger configuration.
* `host.mvc`
* `--with-serilog`: Includes Serilog configuration.
* `--with-swagger`: Includes Swagger configuration.
* `--add-serilog`: Includes Serilog configuration.
* `--add-swagger`: Includes Swagger configuration.
* `host.blazor-wasm`
* `--backend`: Name of the backend project in the module (not path).
* `host.blazor-server`
* `abp.console`
* `csharp.console`
* `csharp.library`
* `--module-file` or `-m`: If set, the new package will be added to the given module. Otherwise the new package will added to the closest module in the file system. If no module found, it will throw an error.
@ -342,7 +358,7 @@ Note that this command can upgrade your solution from a previous version, and al
* `--solution-name` or `-sn`: Specify the solution name. Search `*.sln` files in the directory by default.
* `--check-all`: Check the new version of each package separately. Default is `false`.
* `--version` or `-v`: Specifies the version to use for update. If not specified, latest version is used.
* * `--leptonx-version` or `-lv`: Specifies the LeptonX version to use for update. If not specified, latest version or the version that is compatible with `--version` argument is used.
* `--leptonx-version` or `-lv`: Specifies the LeptonX version to use for update. If not specified, latest version or the version that is compatible with `--version` argument is used.
### clean

7
docs/en/cli/new-command-samples.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Explore sample commands to create ABP solutions using the ABP CLI, including Angular projects and database options for developers."
}
```
# ABP CLI - New Solution Sample Commands
The `abp new` command creates an ABP solution or other artifacts based on an ABP template. [ABP CLI](../cli/index.md) has several parameters to create a new ABP solution. In this document we will show you some sample commands to create a new solution. All the project names are `Acme.BookStore`. Currently, the available mobile projects are `React Native` and `MAUI` mobile app (they are *available for* ***Team*** *or higher licenses*). Available database providers are `Entity Framework Core` and `MongoDB`. All the commands starts with `abp new`.

7
docs/en/contribution/angular-ui.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to set up and contribute to Angular UI in the ABP Framework with essential tools, commands, and guidelines for developers."
}
```
# Contribution Guide for the Angular UI
## Pre-requirements

7
docs/en/contribution/index.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Join the ABP community! This guide outlines how to contribute code and articles to enhance the ABP Framework."
}
```
# Contribution Guide
ABP is an [open source](https://github.com/abpframework) and community driven project. This guide is aims to help anyone wants to contribute to the project.

7
docs/en/deployment/clustered-environment.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to effectively deploy your ABP application in a clustered environment, ensuring smooth operation across multiple instances."
}
```
# Deploying to a Clustered Environment
This document explains the topics that you should consider when deploying your application to a clustered environment where multiple instances of your application run concurrently.

7
docs/en/deployment/configuring-openIddict.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to configure OpenIddict in your AuthServer project for both Development and Production environments with this comprehensive guide."
}
```
# Configuring OpenIddict
This document introduces how to configure `OpenIddict` in the `AuthServer` project.

7
docs/en/deployment/configuring-production.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to optimize your ABP application for production with essential configurations and caching strategies for better performance."
}
```
# Configuring Your Application for Production Environments
ABP predefines the configurations for the best performance for common deployment scenarios.

7
docs/en/deployment/distributed-microservice.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to deploy distributed and microservice solutions with ABP, ensuring seamless communication and effective application management."
}
```
# Deploying Distributed / Microservice Solutions
ABP is designed for distributed and microservice systems, where multiple applications and/or services communicate internally. All of its features are compatible with distributed scenarios. This document highlights some points you should consider when deploying your distributed or microservice solution.

7
docs/en/deployment/forwarded-headers.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to handle common issues with reverse proxies in ASP.NET Core using forwarded headers middleware for your ABP applications."
}
```
# Forwarded Headers
Reverse proxies and load balancers play a crucial role in modern web application architectures. When an application is deployed behind these proxies and load balancers, several specific issues can arise. This document will discuss these issues in detail, explain how ASP.NET Core's forwarded headers middleware can address them, and provide a code example for configuring forwarded headers in an ABP application.

7
docs/en/deployment/index.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to effectively deploy your ABP applications with essential guides on SSL, OpenIddict, and best practices for .NET environments."
}
```
# Deployment
Deploying an ABP application is not different than deploying any .NET or ASP.NET Core application. You can deploy it to a cloud provider (e.g., Azure, AWS, Google Could) or an on-premise server, IIS or any other web server. ABP's documentation doesn't contain much information on deployment. You can refer to your provider's documentation.

7
docs/en/deployment/optimizing-production.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to optimize your ABP applications for production with caching strategies and best practices for maximum performance."
}
```
# Optimizing Your Application for Production Environments
ABP and the startup solution templates are configured well to get the maximum performance on production environments.

7
docs/en/deployment/ssl.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to obtain and configure an SSL certificate for your application to enhance security, trust, and ownership verification."
}
```
# Configuring SSL certificate(HTTPS)
A website needs an SSL certificate to keep user data secure, verify ownership, prevent attackers from creating a fake version of the site, and gain user trust.

8
docs/en/docs-nav.json

@ -2343,6 +2343,10 @@
}
]
},
{
"text": "AI Management (Pro)",
"path": "modules/ai-management/index.md"
},
{
"text": "Audit Logging",
"path": "modules/audit-logging.md"
@ -2641,6 +2645,10 @@
{
"text": "Optimizing for Production",
"path": "deployment/optimizing-production.md"
},
{
"text": "Configuring Forwarded Headers for Reverse Proxies",
"path": "deployment/forwarded-headers.md"
}
]
},

7
docs/en/framework/api-development/auto-controllers.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to automatically create API controllers in ABP Framework, simplifying your application's REST API setup with minimal configuration."
}
```
# Auto API Controllers
Once you create an [application service](../architecture/domain-driven-design/application-services.md), you generally want to create an API controller to expose this service as an HTTP (REST) API endpoint. A typical API controller does nothing but redirects method calls to the application service and configures the REST API using attributes like [HttpGet], [HttpPost], [Route]... etc.

7
docs/en/framework/api-development/dynamic-csharp-clients.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to use ABP's dynamic C# API client proxies for seamless HTTP service calls, simplifying authentication, serialization, and error handling."
}
```
# Dynamic C# API Client Proxies
ABP can dynamically create C# API client proxies to call your remote HTTP services (REST APIs). In this way, you don't need to deal with `HttpClient` and other low level details to call remote services and get results.

7
docs/en/framework/api-development/index.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Explore comprehensive guidance on building HTTP APIs with ABP, covering endpoints, versioning, auto controllers, and more."
}
```
# API Development
The following documents explain the concepts, infrastructure and integrations to build HTTP APIs with ABP:

7
docs/en/framework/api-development/integration-services.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how Integration Services facilitate communication between microservices, enhancing your ABP Framework applications with seamless integration."
}
```
# Integration Services
The *Integration Service* concept was created to distinguish the [application services](../architecture/domain-driven-design/application-services.md) that are built for inter-module (or inter-microservice) communication from the application services that are intended to be consumed from a UI or a client application.

7
docs/en/framework/api-development/standard-apis/configuration.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to use ABP's Application Configuration Endpoint to access user permissions, settings, and tenant info for your application."
}
```
# Application Configuration Endpoint
ABP provides a pre-built and standard endpoint that contains some useful information about the application/service. Here, is the list of some fundamental information at this endpoint:

7
docs/en/framework/api-development/standard-apis/index.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Explore ABP's standard HTTP API endpoints for easy access to application configuration and localization information."
}
```
# Standard HTTP API Endpoints
ABP provides some pre-built and standard endpoints that contains useful information about the application or service, such as localization entries and settings. Here, is the list of the pre-built endpoints:

7
docs/en/framework/api-development/standard-apis/localization.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to utilize ABP's application localization endpoint to fetch localization resources and enhance your UI application effectively."
}
```
# Application Localization Endpoint
ABP provides a pre-built and standard endpoint that returns all the [localization](../../fundamentals/localization.md) resources and texts defined in the server.

7
docs/en/framework/api-development/static-csharp-clients.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to create Static C# API client proxies with ABP for seamless HTTP service calls, simplifying authentication, serialization, and error handling."
}
```
# Static C# API Client Proxies
ABP can create C# API client proxy code to call your remote HTTP services (REST APIs). In this way, you don't need to deal with `HttpClient` and other low level details to call remote services and get results.

7
docs/en/framework/api-development/swagger.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to integrate Swagger with ABP Framework for seamless REST API documentation and service connectivity with minimal setup."
}
```
# Swagger Integration
[Swagger (OpenAPI)](https://swagger.io/) is a language-agnostic specification for describing REST APIs. It allows both computers and humans to understand the capabilities of a REST API without direct access to the source code. Its main goals are to:

7
docs/en/framework/api-development/versioning.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to implement API versioning in ABP Framework, enabling seamless integration with ASP.NET while supporting static client proxies."
}
```
# API Versioning System
ABP integrates the [ASPNET-API-Versioning](https://github.com/dotnet/aspnet-api-versioning/wiki) feature and adapts to C# and JavaScript Static Client Proxies and [Auto API Controller](./auto-controllers.md).

7
docs/en/framework/architecture/best-practices/application-layer-overview.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Explore best practices for implementing the application layer in your solution with Domain Driven Design principles."
}
```
# Best Practices: Application Layer
The following documents suggest some best-practices that you can use while implementing the application layer of your solution by following the Domain Driven Design principles:

7
docs/en/framework/architecture/best-practices/application-services.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Explore best practices for implementing Application Services in ABP Framework, ensuring effective use of Domain-Driven Design principles."
}
```
# Application Services Best Practices & Conventions
> This document offers best practices for implementing Application Services classes in your modules and applications based on Domain-Driven-Design principles.

7
docs/en/framework/architecture/best-practices/data-access-overview.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Explore best practices for data access in your solutions using Entity Framework Core and MongoDB, aligned with Domain Driven Design principles."
}
```
# Best Practices: Data Access
The following documents suggest some best-practices that you can use while implementing the database integration layer of your solution by following Domain Driven Design principles:

7
docs/en/framework/architecture/best-practices/data-transfer-objects.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Explore best practices for implementing Data Transfer Objects in your applications, guided by Domain-Driven Design principles."
}
```
# Data Transfer Objects Best Practices & Conventions
> This document offers best practices for implementing Data Transfer Object classes in your modules and applications based on Domain-Driven-Design principles.

7
docs/en/framework/architecture/best-practices/domain-layer-overview.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Discover best practices for implementing the domain layer using Domain Driven Design principles, including entities, repositories, and domain services."
}
```
# Best Practices: Domain Layer
The following documents suggest some best-practices that you can use while implementing the domain layer of your solution by following the Domain Driven Design principles:

7
docs/en/framework/architecture/best-practices/domain-services.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn best practices for implementing Domain Services in your applications, guided by Domain-Driven Design principles."
}
```
# Domain Services Best Practices & Conventions
> This document offers best practices for implementing Domain Service classes in your modules and applications based on Domain-Driven-Design principles.

7
docs/en/framework/architecture/best-practices/entities.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Explore best practices for implementing Aggregate Root and Entity classes in your applications using Domain-Driven Design principles."
}
```
# Entity Best Practices & Conventions
> This document offers best practices for implementing Aggregate Root and Entity classes in your modules and applications based on Domain-Driven-Design principles.

7
docs/en/framework/architecture/best-practices/entity-framework-core-integration.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Discover best practices for integrating Entity Framework Core in your applications, ensuring optimal performance and maintainability."
}
```
# Entity Framework Core Integration Best Practices
> This document offers best practices for implementing Entity Framework Core integration in your modules and applications.

7
docs/en/framework/architecture/best-practices/index.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Explore best practices for developing ABP Framework modules, focusing on Domain Driven Design, DBMS independence, and microservice compatibility."
}
```
# Module Development Best Practices & Conventions
This document describes the **best practices** and **conventions** for those who want to develop **modules** that satisfy the following specifications:

7
docs/en/framework/architecture/best-practices/module-architecture.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Discover best practices for structuring ABP modules with clear conventions on solution architecture, layered design, and package dependencies."
}
```
# Module Architecture Best Practices & Conventions
## Solution Structure

7
docs/en/framework/architecture/best-practices/mongodb-integration.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn best practices for integrating MongoDB in your ABP Framework applications with clear guidelines on defining MongoDbContext."
}
```
# MongoDB Integration
> This document offers best practices for implementing MongoDB integration in your modules and applications.

7
docs/en/framework/architecture/best-practices/repositories.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Discover best practices for implementing repository classes in your applications, grounded in Domain-Driven Design principles."
}
```
# Repository Best Practices & Conventions
> This document offers best practices for implementing Repository classes in your modules and applications based on Domain-Driven-Design principles.

7
docs/en/framework/architecture/domain-driven-design/application-layer.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Explore the Application Layer in Domain Driven Design, learn about its components, and how it facilitates application logic in ABP Framework."
}
```
# Domain Driven Design: Application Layer
Application Layer mediates between the Presentation and Domain Layers. Orchestrates business objects to perform specific application tasks and implements use cases as the application logic. Here, is the list of the building blocks of the Application Layer:

7
docs/en/framework/architecture/domain-driven-design/application-services.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to implement application services in the ABP Framework to expose domain logic and streamline presentation layer interactions."
}
```
# Application Services
Application services are used to implement the **use cases** of an application. They are used to **expose domain logic to the presentation layer**.

7
docs/en/framework/architecture/domain-driven-design/data-transfer-objects.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how Data Transfer Objects (DTOs) enhance data handling between application and presentation layers, ensuring clean architecture and abstraction."
}
```
# Data Transfer Objects
**Data Transfer Objects** (DTO) are used to transfer data between the **Application Layer** and the **Presentation Layer** or other type of clients.

7
docs/en/framework/architecture/domain-driven-design/domain-layer.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Explore the Domain Layer in Domain Driven Design, featuring essential building blocks like Entities, Value Objects, and Domain Services."
}
```
# Domain Driven Design: Domain Layer
Domain Layer contains business objects and the core (domain) business rules of the application and it's the heart of the application. Here, is the list of building blocks of the Domain Layer:

7
docs/en/framework/architecture/domain-driven-design/domain-services.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to implement Domain Services in ABP Framework for core business logic, enhancing your Domain Driven Design solutions effectively."
}
```
# Domain Services
In a [Domain Driven Design](../domain-driven-design) (DDD) solution, the core business logic is generally implemented in aggregates ([entities](./entities.md)) and the Domain Services. Creating a Domain Service is especially needed when;

7
docs/en/framework/architecture/domain-driven-design/entities.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn about entities in DDD, their structure, and best practices for using GUID keys in the ABP Framework for effective data modeling."
}
```
# Entities
Entities are one of the core concepts of DDD (Domain Driven Design). Eric Evans describes it as "*An object that is not fundamentally defined by its attributes, but rather by a thread of continuity and identity*".

7
docs/en/framework/architecture/domain-driven-design/index.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Discover how ABP Framework simplifies Domain Driven Design (DDD) for developers with structured layers and collaboration for complex software needs."
}
```
# Domain Driven Design
## What is DDD?

7
docs/en/framework/architecture/domain-driven-design/repositories.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to use repositories in ABP Framework for effective data access and CRUD operations on domain objects."
}
```
# Repositories
"*Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects*" (Martin Fowler).

7
docs/en/framework/architecture/domain-driven-design/specifications.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to implement the Specification Pattern in your ABP projects for creating reusable and testable filters for your entities."
}
```
# Specifications
Specification Pattern is used to define **named, reusable, combinable and testable filters** for entities and other business objects.

7
docs/en/framework/architecture/domain-driven-design/unit-of-work.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how ABP's Unit of Work simplifies database transactions, ensuring consistency across operations in any application type."
}
```
# Unit of Work
ABP's Unit Of Work (UOW) implementation provides an abstraction and control on a **database connection and transaction** scope in an application.

7
docs/en/framework/architecture/domain-driven-design/value-objects.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn about Value Objects in domain-driven design, how to implement them in your projects, and why they matter for clean architecture."
}
```
# Value Objects
> An object that represents a descriptive aspect of the domain with no conceptual identity is called a VALUE OBJECT.

7
docs/en/framework/architecture/index.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Discover ABP's opinionated yet flexible architecture for building enterprise software, featuring modularity and comprehensive tools for developers."
}
```
# ABP Architecture
ABP offers an **opinionated architecture** to build enterprise software solutions. In this way, the solution structure and development model is pretty well defined. All the solution templates, tooling, pre-built modules, guides and documentation are compatible to that development model.

7
docs/en/framework/architecture/microservices/index.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Explore microservice architecture and learn how it enhances modularity, scalability, and continuous delivery for efficient application development."
}
```
# Microservice Architecture
*"Microservices are a software development technique—a variant of the **service-oriented architecture** (SOA) architectural style that structures an application as a collection of **loosely coupled services**. In a microservices architecture, services are **fine-grained** and the protocols are **lightweight**. The benefit of decomposing an application into different smaller services is that it improves **modularity**. This makes the application easier to understand, develop, test, and become more resilient to architecture erosion. It **parallelizes development** by enabling small autonomous teams to **develop, deploy and scale** their respective services independently. It also allows the architecture of an individual service to emerge through **continuous refactoring**. Microservices-based architectures enable **continuous delivery and deployment**."*

7
docs/en/framework/architecture/modularity/basics.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to build modular applications with ABP Framework, including best practices, templates, and CLI support for seamless development."
}
```
# Modularity
ABP was designed to support to build fully modular applications and systems where every module may have entities, services, database integration, APIs, UI components and so on;

7
docs/en/framework/architecture/modularity/extending/customizing-application-modules-extending-entities.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to extend entities in ABP Framework by adding extra properties to seamlessly customize your application modules."
}
```
# Customizing the Application Modules: Extending Entities
In some cases, you may want to add some additional properties (and database fields) for an entity defined in a depended module. This section will cover some different approaches to make this possible.

7
docs/en/framework/architecture/modularity/extending/customizing-application-modules-guide.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to customize and reuse ABP's pre-built application modules for efficient and modular application development."
}
```
# Customizing the Existing Modules
ABP has been designed to support to build fully [modular applications](../../modularity/basics.md) and systems. It also provides some [pre-built application modules](../../../../modules) those are **ready to use** in any kind of application.

7
docs/en/framework/architecture/modularity/extending/customizing-application-modules-overriding-services.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to customize ABP application modules by overriding services using dependency injection for tailored business logic."
}
```
# Customizing the Application Modules: Overriding Services
You may need to **change behavior (business logic)** of a depended module for your application. In this case, you can use the power of the [dependency injection system](../../../fundamentals/dependency-injection.md) to replace a service, controller or even a page model of the depended module by your own implementation.

7
docs/en/framework/architecture/modularity/extending/module-entity-extensions.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to extend existing entities in ABP Framework modules by adding new properties seamlessly across the entire system."
}
```
# Module Entity Extensions
Module entity extension system is a **high level** extension system that allows you to **define new properties** for existing entities of the depended modules. It automatically **adds properties to the entity, database, HTTP API and the user interface** in a single point.

7
docs/en/framework/architecture/modularity/extending/overriding-user-interface.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to customize and override the user interface for ABP Framework modules using various UI frameworks like ASP.NET Core, Angular, and Blazor."
}
```
# Overriding the User Interface
You may want to override a page, a component, a JavaScript, CSS or an image file of your depended module. Overriding the UI completely depends on the UI framework you're using. Select the UI framework to continue:

7
docs/en/framework/architecture/modularity/plugin-modules.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how to load modules as plug-ins in your ABP Framework application, enabling flexible module management without direct assembly references."
}
```
# Plug-In Modules
[Modules](../modularity/basics.md) can also be loaded as plug-ins. This means that you don’t need to reference a module’s assembly directly in your solution; instead, you can load it during application startup in the same way as any other module.

7
docs/en/framework/architecture/multi-tenancy/index.md

@ -1,3 +1,10 @@
```json
//[doc-seo]
{
"Description": "Learn how ABP Framework enables developers to build powerful multi-tenant applications, optimizing resource sharing for SaaS solutions."
}
```
# Multi-Tenancy
Multi-Tenancy is a widely used architecture to create **SaaS applications** where the hardware and software **resources are shared by the customers** (tenants). ABP provides all the base functionalities to create **multi tenant applications**.

Some files were not shown because too many files changed in this diff

Loading…
Cancel
Save