1C-Bitrix Component Development: Architecture and Caching

1C-Bitrix Component Development: Architecture and Caching

Standard Bitrix components cover 80% of typical tasks. But when you need specific lists with multi-parameter filtering, complex forms with AJAX validation, or integration with external APIs—a custom component is unavoidable. A common mistake beginners make is writing logic directly in the template or copying code from component.php into each new project. This leads to duplication, maintenance difficulties, and caching problems.

Imagine a catalog of 100,000 products with 20 filter properties—the standard bitrix:catalog won't handle it. Without cache, the database crashes; with cache, data becomes stale. Our approach is to build components with proper architecture using tagged caching and reusable classes. Over 10+ years, we've developed more than 50 components—from e-commerce catalogs to corporate portals, each following the design patterns guidelines.

Problems We Solve

• Lack of caching. Without cache, every component call queries the database. With 1000 visitors, this creates 10,000 queries per minute. Proper caching reduces it to 1–2 queries per cache period.
• Tight coupling of logic and template. When queries are in template.php, a designer cannot change the layout without risking breaking the code. Separating layers solves this 100%.
• Cache invalidation issues. Flushing the entire cache when one element changes wastes resources. Tagged caching, implemented via \Bitrix\Main\Data\TaggedCache, updates only relevant entries and saves up to 40% of page load time.
• Lack of parameter normalization. Parameters passed in $arParams may be invalid. The onPrepareComponentParams() method in the component class guarantees correct values.

How We Do It: Stack and Configurations

We use PHP 8.1+, information blocks v2.0, Bitrix ORM, and the main module. For a typical component (element list), we write a class extending CBitrixComponent. In onPrepareComponentParams, we cast IBLOCK_ID to int and COUNT to a positive number. Then in executeComponent, we enable cache, fetch data via CIBlockElement::GetList with sorting and filter, and assemble $arResult['ITEMS']. The template contains only HTML and calls AddCss/AddJs via Asset.

Case study. For an e-commerce site with 50,000 products, we needed a filter component with 12 parameters. We implemented a class-based component with tagged cache and OnAfterIBlockElementUpdate event for invalidation. After deployment, server load dropped 35%, and response time went from 2 seconds to 0.4 seconds.

Process

1. Analysis — study architecture, load, requirements.
2. Design — define structure, parameters, caching, integrations.
3. Implementation — write class, template, tests.
4. Testing — load, functional, compatibility with updates.
5. Deployment — install on production, hand over documentation.

Timelines

Cost is calculated individually based on requirements—contact us for an accurate estimate.

Why Use a Class Instead of Procedural Code?

The class approach reduces debugging time by 2x and simplifies maintenance by 30% during updates. Our experience confirms: projects using classes have on average 40% fewer bugs. Comparison:

How to Properly Configure Component Caching?

Use $this->StartResultCache() and $this->EndResultCache(). For invalidation when data changes, call BXClearCache(true, '/cache/path/') in the OnAfterIBlockElementUpdate event. More precise is tagged caching: TaggedCache::startTagCache('my_tag'); ... TaggedCache::endTagCache(). This clears only entries tied to specific elements, not the entire component cache. Such setup speeds invalidation 5x compared to full cache flush.

<?php use Bitrix\Main\Data\TaggedCache; $taggedCache = TaggedCache::getInstance(); $taggedCache->startTagCache('/my/component/'); $taggedCache->registerTag('iblock_id_3'); // ... queries and building $arResult $taggedCache->endTagCache(); ?>