1. Introduction

The major issues we encountered in our legacy system led us to initiate a transition to a new product structure. These issues included limitations in the product-seller relationship, data redundancy, management difficulties, constraints stemming from domain-specific design, and the risks associated with a shared database architecture. To address these problems, we launched a comprehensive migration project titled “New Product Structure.”

2. Comparison of the Legacy and New Product Structures

In our old system, a product could only be sold by a single seller. This meant that if multiple sellers wanted to offer the same product, it had to be duplicated in the system. In the new structure, this restriction was removed — allowing a single product to be sold by multiple sellers. This change introduced a more flexible sales model and enabled better stock and price management.

We also made significant improvements in product attributes and variant management. In the legacy system, tagging and customizable attributes were defined at the variant level, which led to unnecessary data duplication and management challenges. In the new structure, we elevated these attributes to the product level, thereby reducing redundancy and simplifying administration.

Another major change involved image management. Previously, images had to be defined per variant, which complicated the user experience, bloated the database, and caused storage inefficiencies. We centralized image management at the product level to resolve these issues.

Category-based product management was one of the most critical changes. With category-specific attributes, products were split based on these features. For example, in a category with a “color” attribute, each color was defined as a separate product. This approach allowed for easier management of product visuals and attributes while providing sellers with greater flexibility in listing products.

We also restructured our database. Previously, a shared legacy MSSQL database was used, exposing our system to issues caused by other domains. We moved to an isolated architecture using a MySQL database, eliminating this risk.

Significant changes were also made in integration management. While the old system relied on direct integration, the new system introduced an adapter layer. This allowed integrators to transition seamlessly without requiring any changes on their end.

Domain flexibility was another area of improvement. The legacy system was tightly coupled with the flower domain, making it difficult to adapt to the marketplace domain. The new structure was designed to accommodate the needs of both domains efficiently.

3. Migration Project Details

The migration project was developed using .NET 8 and employed Hangfire for job management, with Redis used for Hangfire storage. The primary goal was to transform millions of product records from the legacy MSSQL database into the new structure.

The migration process consisted of two main phases. In the first phase, products were segmented based on category-specific attributes and transferred to the new schema. During this process, image migration and storage optimization were also conducted.

The second phase involved continuous synchronization. Changes in the legacy system were tracked using timestamps and replicated into the new system. A table-specific job system enabled low-latency synchronization.

Each table had a custom-designed job. Using a recurring job structure, continuous syncing was ensured. A retry mechanism was implemented for failure scenarios, and data was processed in chunks for performance optimization. Errors were logged in a structured table, allowing us to analyze and resolve issues observed during testing. Ensuring clean data in the new system was one of the most critical aspects of the migration.

Cross-domain interactions were another important topic. To update related domains such as promotions and advertising, a dedicated job system was developed. This ensured that changes in product structures were reflected across all dependent systems.

To minimize load on the production database, various optimization strategies were applied. A chunk-based processing model using IDs and timestamps was implemented, allowing for controlled, incremental data transfers. This significantly reduced the impact on the live environment.

4. Transition and Go-Live Process

A go-live date was set and communicated to all relevant teams. Dependency analysis was conducted to determine which services could be transitioned independently. Services without dependencies were launched ahead of the migration; dependent services were migrated in sync.

As part of the versioning strategy, endpoint versioning was introduced in shared services. Separate endpoints were maintained for both legacy and new structures to ensure a seamless transition and reduce interdependencies.

Prior to the go-live, sellers and integrators were informed. Product creation and updates were temporarily halted, while critical operations like stock and price updates continued. Incoming price and stock update requests were queued and processed with minimal delay during the transition.

Throughout the migration, database synchronization and service transitions were carefully coordinated. User experience remained uninterrupted, with only minor downtime observed for product creation and updates.

Extensive quality assurance processes were followed, including high test coverage and rigorous testing procedures. Load and performance tests were conducted, ensuring the system was fully prepared for high-traffic scenarios, such as during special campaigns.

5. Results and Gains

This project provided invaluable experience in managing and executing large-scale transformations. Over several months, multiple teams collaborated across dozens of services in a coordinated effort.

The isolated database structure helped prevent external service outages from impacting our domain — addressing a major risk posed by the shared legacy database.

Adopting a Domain-Driven Design approach allowed us to clearly define domain rules and bounded contexts. Hundreds of business rules were documented, and the common language developed between analysts and engineers enabled smoother communication with business stakeholders.

We also made significant strides in documentation and knowledge management. Dozens of technical and analysis documents were prepared. Updated documentation for users and integrators made adoption easier. These documents are expected to significantly reduce the onboarding time for new team members.

The project also delivered technical and cost-related gains through data deduplication and storage optimization:

• Legacy shared database size reduced by 65%
• Disk usage on storage systems dropped by 20%, reducing costs
• Monthly database costs decreased noticeably

Performance improvements were another key outcome:

• API response times improved by an average of 35%
• Database query performance increased by 30%

From a development and maintenance perspective, we now have a cleaner, more modern codebase:

• Code duplication significantly reduced
• Full test coverage achieved across all systems
• Average bug fix time shortened
• Noticeable improvements in the development of new features

Overall, the project was a success in both execution and outcome. There was no data loss, no system downtime, and no need for rollback.

This migration fostered confidence and experience for future large-scale projects. 95% of team members reported high satisfaction with the project and expressed greater readiness for similar challenges ahead.

With this article, we aimed to provide a detailed account of how to plan and execute a major system migration, the challenges encountered, and the successes achieved. We hope our insights will guide other teams undertaking similar transitions — both from a technical and organizational perspective.

Product Structure Transition: Seamless Migration from Legacy to New System was originally published in ÇSTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

1. Giriş

Eski sistemimizde karşılaştığımız temel sorunlar, bizi yeni bir ürün yapısına geçiş yapmaya yönlendirdi. Bu sorunlar arasında ürün-bayi ilişkisindeki kısıtlamalar, veri tekrarı ve yönetim zorlukları, domain özgü tasarımın getirdiği sınırlamalar ve ortak veritabanı kullanımının riskleri bulunuyordu. Bu sorunların çözümü için “Yeni Ürün Yapısı” adın verdiğimiz kapsamlı bir geçiş projesi başlattık.

2. Eski ve Yeni Ürün Yapısının Karşılaştırması

Eski sistemimizde, bir ürün sadece bir bayi tarafından satılabiliyordu. Bu durum, aynı ürünü farklı bayilerin satmak istemesi durumunda sisteme aynı ürünün tekrar eklenmesini gerektiriyordu. Yeni yapımızda bu kısıtlama kaldırıldı ve bir ürün birden fazla bayi tarafından satılabilir hale geldi. Bu değişiklik, daha esnek bir satış modeli ve daha iyi stok-fiyat yönetimi imkanı sağladı.

Ürün özellikleri ve varyant yönetimi konusunda da önemli değişiklikler yaptık. Eski sistemde tagleme ve kişiselleştirilebilir özellikler varyant seviyesinde tanımlanıyordu. Bu durum, veritabanında gereksiz veri tekrarına ve yönetim zorluklarına yol açıyordu. Yeni yapımızda bu özellikleri ürün seviyesine taşıdık, böylece veri tekrarını önleyerek yönetimi kolaylaştırdık.

Ürün görsellerinin yönetimi de önemli bir değişiklik alanıydı. Eski sistemde her varyant için ayrı görsel tanımlanması gerekiyordu. Bu durum, kullanıcılar için zorluk yaratıyor, veritabanında gereksiz veri oluşturuyor ve storage tarafında sorunlara yol açıyordu. Yeni yapımızda görselleri ürün seviyesine taşıdık, böylece bu sorunları çözdük.

Kategori bazlı ürün yönetimi, yeni yapımızın en önemli değişikliklerinden biriydi. Kategori bazlı tanımlanan ürün özellikleri ile birlikte, ürünler bu özelliklere göre parçalandı. Örneğin, renk özelliği olan bir kategoride, her renk ayrı bir ürün olarak tanımlandı. Bu yaklaşım, görsel ve ürün özelliklerinin kolay yönetilmesini sağladı ve bayilerin ürün satışında daha esnek olmasına olanak tanıdı.

Veritabanı yapımızda da önemli değişiklikler yaptık. Eski sistemde legacy MSSQL veritabanını ortak olarak kullanıyorduk. Bu durum, diğer domainlerde yaşanan sorunların bizim sistemimizi de etkileme riskini taşıyordu. Yeni yapımızda MySQL veritabanına geçiş yaparak izole bir yapı oluşturduk ve bu riski ortadan kaldırdık.

Entegrasyon yönetiminde de önemli değişiklikler yaptık. Eski sistemde doğrudan entegrasyon kullanıyorduk, yeni yapımızda ise adaptör katmanı ekledik. Bu değişiklik, geçiş sürecinde entegratörlerin hiçbir değişiklik yapmasına gerek kalmadan sorunsuz bir geçiş sağladı.

Domain esnekliği konusunda da önemli iyileştirmeler yaptık. Eski sistem çiçek domainine özel tasarlanmıştı ve marketplace domainine uyarlamada zorluklar yaşıyorduk. Yeni yapımız hem çiçek hem de marketplace domaininin ihtiyaçlarına cevap verebilecek şekilde tasarlandı.

3. Migration Projesinin Detayları

Migration projemiz, .NET 8 tabanlı olarak geliştirildi ve job yönetimi için Hangfire kullanıldı. Hangfire storage olarak Redis tercih edildi. Projenin temel amacı, legacy MSSQL veritabanında bulunan milyonlarca ürün verisini yeni yapıya uygun şekilde dönüştürmekti.

Migration süreci iki ana aşamadan oluşuyor. İlk aşamada, ürünlerin kategori bazlı özelliklere göre parçalanması ve yeni tablo yapısına aktarılması gerçekleştirildi. Bu süreçte görsel transferi ve storage optimizasyonu da yapıldı.

İkinci aşamada ise sürekli senkronizasyon süreci başladı. Bu süreçte, legacy sistemdeki değişiklikler timestamp bazlı olarak takip edildi ve yeni sisteme aktarıldı. Tablo bazlı job sistemi sayesinde düşük latency ile senkronizasyon sağlandı.

Job sistemi, her tablo için özel olarak tasarlandı. Recurring job yapısı kullanılarak sürekli senkronizasyon sağlandı. Hata durumları için retry mekanizması eklendi ve performans optimizasyonu için veriler parçalı olarak işlendi. Hata alan jobların incelenmesi için hata senaryoları maddelere ayrılarak bir tabloya loglandı. Böylece migration sürecinde yaptığımız denemelerde yaşanan sorunları madde bazlı görerek gerekli veri düzenlemelerini sağladık. Yeni yapıya temiz bir veri ile geçişin en önemli kısımlarından biri buydu.

Çapraz domain etkileşimleri de önemli bir konuydu. Reklam ve indirim gibi diğer domainlerin güncellenmesi için ayrı bir job sistemi oluşturuldu. Bu sayede parçalanan ürünlerin diğer sistemlerdeki yansımaları da güncellendi.

Teknik çözümler ve optimizasyonlar kapsamında, canlıda bulunan veritabanı yükünü minimize etmek için çeşitli stratejiler geliştirildi. ID ve timest bazlı parçalı veri işleme yaklaşımı benimsendi. Bu sayede parçalamalar ve gelen güncellemeler parçalı bir şekilde eski veritabanından alınarak yeni veritabanına yansıtıldı. Eski ve canlıda aktif görev alan veritabanına getirilen yükün en alt seviyede tutulması amaçlandı.

4. Geçiş Süreci ve Canlıya Alma

Geçiş süreci için bir tarih belirlendi ve tüm ilgili ekiplere bilgi verildi. Ekipler arasında bağımlılık analizi yapıldı ve bağımlılık olmayan servisler geçişten önce canlıya alındı. Bağımlılık olan servisler ise senkronize olarak canlıya alındı.

Versiyonlama stratejisi kapsamında, ortak servislerde endpoint versiyonlaması yapıldı. Eski ve yeni yapı için ayrı endpoint versiyonları oluşturuldu. Bu sayede kesintisiz geçiş sağlandı ve bağımlılık minimizasyonu sağlandı.

Geçiş öncesi son hazırlıklar kapsamında, bayi ve entegratörlere bilgilendirme yapıldı. Ürün açma ve güncelleme işlemleri geçici olarak durduruldu, ancak kritik işlemler olan fiyat ve stok güncellemeleri devam etti. Gelen fiyat ve stok istekleri geçiş esnasında kuyruk sisteminde toplanarak dakikalar seviyesinde gecikmeli olarak işlendi.

Geçiş süreci boyunca veritabanı senkronizasyonu ve servis geçişleri koordineli bir şekilde yönetildi. Kullanıcı deneyiminde kesintisizlik sağlandı, sadece ürün açma ve güncelleme işlemlerinde kısa süreli bir kesinti yaşandı.

Kalite ve test güvencesi kapsamında, yüksek test coverage oranları ve kapsamlı test süreçleri uygulandı. Yük testleri ve performans analizleri yapıldı. Yapılan yük testleri ve performans analizleri sayesinde live geçişinden sonra bir sürpriz ile karşılaşma durumu yaşanmadı. Özel gün gibi çok yük beklediğimiz senaryoları da bu yük testleri sayesinde deneme fırsatı bulduk ve gerekli aksiyonları bularak tüm senaryolara hazır halde geçiş sürecini tamamladık.

5. Sonuçlar ve Kazanımlar

Bu proje, ekip olarak büyük ölçekli projelerin nasıl yönetileceği ve planlanacağı konusunda önemli deneyimler kazanmamızı sağladı. Aylarca süren yoğun bir çalışma sürecinde, onlarca farklı servis üstünde tüm ekipler koordineli olarak çalıştı.

İzole edilmiş veritabanı yapısı sayesinde dış kaynaklı kesintilerin önüne geçtik. Geçiş öncesi ortak veritabanı kullanımından dolayı yaşanabilecek olası bir kesintinin önüne geçmiş olduk.

Domain-Driven Design yaklaşımını benimseyerek, domain kurallarını net bir şekilde belirledik ve bounded context’leri doğru şekilde tanımladık. Bu süreçte yüzlerce farklı domain kuralı belirlendi. Bounded contextler tanımlandı. Analist ve development ekiplerinin ortak dili sayesinde, iş birimleriyle daha iyi iletişim kurabildik.

Dokümantasyon ve bilgi yönetimi konusunda da önemli adımlar attık. Sayfalarca teknik dokümantasyon ve analiz dökümanları hazırlandı. Kullanıcılara ve entegratörlere verdiğimiz dokümanlar güncellenerek kullanım kolaylığı sağlandı Bu dokümantasyonlar sayesinde, yeni ekip üyelerinin domaine adaptasyon sürecinde gözle görülür derecede bir düşüş bekliyoruz.

Teknik ve maliyet kazanımları açısından, veri tekrarının önlenmesi ve storage optimizasyonu sayesinde önemli maliyet düşüşleri sağladık:

- Ortak kullanılan legacy veritabanı boyutu %65 azaldı

- Storage tarafında disk kullanımı %20 düştü ve maliyetleri azaldı.

- Aylık veritabanı maliyetleri belirli bir oranda azaldı.

Performans artışı da önemli kazanımlarından biri oldu:

- API yanıt süreleri ortalama %35 iyileşti

- Veritabanı sorgu performansı %30 arttı

Geliştirme ve bakım kolaylığı açısından, daha temiz ve modern bir kod base’e sahip olduk:

- Kod tekrarı ciddi oranda azaldı.

- Test coverage oranı olarak otomasyon testi yazılmayan sistemimiz kalmadı.

- Ortalama bug fix süremiz kısaldı

- Yeni özellik geliştirme sürecinde gözle görülür bir fark gözlemlendi.

Genel değerlendirmede, kesintisiz geçiş başarısı ve ekip olarak başarı duygusu öne çıktı. Geçiş sürecinde veri kaybı, sistem kesintisi yaşanmadı ve herhangi bir rollback ihtiyacı duyulmadı.

Bu proje, gelecek projeler için güven artışı ve tecrübe kazanımı sağladı. Ekip üyelerinin %95'i projeden memnuniyetini belirtti ve benzer büyüklükteki projelerde çalışma konusunda kendilerini daha hazır hissettiklerini ifade ettiler.

Bu makalede, büyük ölçekli bir sistem geçişinin nasıl planlanıp yürütülebileceğini, karşılaşılan zorlukları ve elde edilen başarıları detaylı bir şekilde ele almayı amaçladık. Hem teknik hem de organizasyonel açıdan dikkat ettiğimiz ve yaşadığımız süreçlerin benzer geçiş süreçleri planlayan ekiplere yol gösterici olmasını umuyoruz.

Ürün Yapısı Geçişi: Eski Sistemden Yeni Sisteme Kesintisiz Geçiş was originally published in ÇSTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Initially, it might be complex to understand and hard to carry out. However, when you get used to it, you start to implement it autonomously.

These usages will make your code more readable, understandable, and reliable in the long term. Not only for other developers but especially also for you.

1. Use Meaningful Variable and Function Names

Always choose descriptive names that clearly reflect the purpose of the variable or function. Avoid vague names like a, b, or temp. The more meaningful the name, the easier it is for others (and yourself) to understand the code. For instance, instead of naming a variable x, name it something like totalPrice or itemCount to make its purpose obvious. Additionally, use camelCase for variable names and PascalCase for function and class names to follow common JavaScript conventions.

// Bad
let a = 5;
function doSomething() {
  return a * 2;
}

// Good
let numberOfItems = 5;
function calculateTotalPrice() {
  return numberOfItems * 2;
}

Pros of Using Meaningful Names:

• Readability: Code is easier to understand and follow.
• Maintainability: Developers can update the code more efficiently.
• Reduced Comments: Fewer comments are needed to explain what variables or functions do.

Cons of Using Poor Names:

• Confusing Code: Vague names make the code harder to interpret.
• Increased Maintenance Costs: More time spent deciphering variable meanings.
• Error-Prone: Hard-to-understand code leads to mistakes during development.

2. Keep Functions Small and Focused

Functions should perform a single task and ideally fit within a few lines of code. If a function grows too large or starts performing multiple tasks, consider refactoring it into smaller, more manageable functions. This improves the clarity of the code and enhances reusability. Smaller functions also make it easier to write unit tests.

However, it should not be forgotten that this is not 100% possible in some cases due to the complexity of the work. We can accept these as exceptions.

// Bad
function processOrder(order) {
  processPayment(order);
  updateInventory(order);
  sendConfirmationEmail(order);
}

// Good
function processPayment(order) {
  // logic for payment
}

function updateInventory(order) {
  // logic for inventory
}

function sendConfirmationEmail(order) {
  // logic for email
}

Pros of Small, Focused Functions:

• Code Reusability: Functions can be reused in different parts of the project.
• Testability: Smaller functions are easier to test individually.
• Maintainability: Modular functions simplify debugging and updating.

Cons of Large, Unfocused Functions:

• Difficult Debugging: Larger functions are harder to trace for bugs.
• Complex Codebase: Mixed responsibilities lead to confusing and messy code.
• Low Reusability: Functions that try to do too much are less reusable.

3. Use Constants for Magic Numbers

Avoid using hard-coded numbers, commonly known as “magic numbers” throughout your code. Instead, define them as constants with descriptive names. This improves readability and makes it easier to update values across the codebase.

Additional Tip: You can create enum or constant files for overused values over the project rather than file-related constants.

// Bad
let tax = price * 0.15;

// Good
const TAX_RATE = 0.15;
let tax = price * TAX_RATE;

Pros of Using Constants:

• Readability: Constants clearly describe the purpose of the value.
• Easy Updates: Changing the constant value updates it everywhere in the code.
• Reduced Errors: Prevents hard-to-find bugs caused by number misuse.

Cons of Using Magic Numbers:

• Confusing Logic: Direct numbers can be hard to interpret.
• Error-Prone: Changes require searching and updating multiple occurrences.
• Poor Documentation: Readers won’t know what a number represents without additional context.

4. Avoid Nested Loops and Conditionals

If your code has deeply nested loops or conditionals, it’s a good idea to refactor it. Such nested structures are difficult to follow and increase the risk of bugs. You can often flatten the logic using helper functions, early returns, or array methods like .filter() and .map().

// Bad
for (let i = 0; i < items.length; i++) {
  for (let j = 0; j < orders.length; j++) {
    if (items[i].id === orders[j].itemId) {
      processOrder(items[i]);
    }
  }
}

// Good
const itemOrders = orders.filter(order => items.some(item => item.id === order.itemId));
itemOrders.forEach(order => processOrder(order));

Pros of Avoiding Nested Structures:

• Better Readability: Code is cleaner and easier to follow.
• Lower Complexity: Fewer nested structures simplify the logic.
• Reduced Bug Risk: Less nested code means fewer opportunities for logic errors.

Cons of Using Nested Structures:

• Harder Maintenance: Deep nesting is difficult to modify or extend.
• Reduced Performance: Extra processing can slow down the program.
• Bug-Prone Logic: Complex nesting increases the risk of logic mistakes.

5. Use Arrow Functions for Simplicity

Arrow functions offer a concise way to write functions, especially for callbacks or functions with a single expression. They also preserve the context of this, which can avoid common pitfalls in traditional function expressions.

If the function is gold, the arrow function is a diamond.

// Bad
let numbers = [1, 2, 3];
let doubled = numbers.map(function(num) {
  return num * 2;
});

// Good
let doubled = numbers.map(num => num * 2);

Pros of Using Arrow Functions:

• Cleaner Syntax: Code looks simpler and more readable.
• Shorter Code: Fewer lines are needed for function declarations.
• No this Binding Issues: Arrow functions inherit this from their enclosing context.

Cons of Misusing Arrow Functions:

• Limited Use Cases: Arrow functions are unsuitable for defining class methods or object methods.
• Overuse in Complex Logic: Using arrow functions in complex logic can reduce clarity.
• Not Hoisted: Unlike function declarations, arrow functions are not hoisted.

6. Use Template Literals Instead of String Concatenation

Template literals allow you to embed expressions directly into strings, making the code more readable and less error-prone than string concatenation.

Additional information, if you do start to develop with linter, it will already be angry on every String Concatenation usage in case you don’t fix or turn off the warning.

// Bad
let message = 'Hello ' + userName + ', you have ' + itemCount + ' items in your cart.';

// Good
let message = `Hello ${userName}, you have ${itemCount} items in your cart.`;

Pros of Using Template Literals:

• Improved Readability: String construction is clearer and easier to follow.
• Dynamic Content: Easily embed variables and expressions.
• Reduced Errors: Less risk of missing spaces or incorrect syntax.

Cons of Using String Concatenation:

• Harder to Read: Concatenation creates long, hard-to-follow strings.
• Error-Prone: Easy to miss spaces or add incorrect punctuation.
• Poor Maintainability: Long strings are hard to adjust or update.

7. Commenting and Documentation

While clean code should largely speak for itself, comments can be used to clarify non-obvious logic or complex algorithms. Use comments sparingly and focus on why something is being done, rather than what is being done.

// Bad
let x = 5; // initialize x

// Good
// The following variable stores the price of the item after tax is applied
let priceWithTax = price * (1 + TAX_RATE);

Pros of Writing Clear Comments:

• Better Collaboration: Team members understand code intentions quickly.
• Reduced Learning Curve: New developers can grasp project logic faster.
• Easier Debugging: Proper comments can explain tricky logic or workarounds.

Cons of Poor or Excessive Comments:

• Cluttered Code: Too many comments make code harder to read.
• Outdated Information: Comments can become inaccurate over time if not updated.
• Reduced Focus: Over-commenting can shift focus from reading the actual code.

8. Use Destructuring

Destructuring provides a shorthand syntax for extracting values from arrays or objects and assigning them to variables. It makes the code more concise and easier to read.

// Bad
let person = { name: 'John', age: 30 };
let name = person.name;
let age = person.age;

// Good
let { name, age } = person;

Pros of Using Destructuring:

• Readable Code: Property extraction is clear and explicit.
• Reduced Boilerplate: Less repetitive code for variable declarations.
• Better Maintainability: Code updates are simpler when adding or removing properties.

Cons of Not Using Destructuring:

• Repetitive Code: Multiple variable declarations make code verbose.
• Harder to Follow: Readers may struggle to track property assignments.
• Increased Errors: Manually accessing properties is prone to typos and logical errors.

9. Use Proper Error Handling

Effective error handling prevents your application from crashing and helps identify bugs faster. Use try...catch blocks, error messages, and logging to gracefully manage unexpected issues. Avoid using generic error messages like "Something went wrong"; instead, provide meaningful messages and log the specific error details for debugging. Additionally, consider creating custom error classes to handle various error types systematically.

// Bad: No error handling
function fetchData(url) {
  const response = fetch(url); 
  const data = response.json(); 
  console.log(data); 
}

// Good: Proper error handling
async function fetchData(url) {
  try {
    const response = await fetch(url); 
    if (!response.ok) {
      throw new Error(`HTTP Error: ${response.status}`);
    }
    const data = await response.json(); 
    console.log(data); 
  } catch (error) {
    console.error(`Failed to fetch data: ${error.message}`);
  }
}

Pros of Proper Error Handling:

• Improved Debugging: Errors are easier to diagnose when detailed messages are logged.
• Better User Experience: Users are notified gracefully without application crashes.
• Enhanced Security: Proper handling prevents the display of sensitive system information to users.

Cons of Poor Error Handling:

• Hard-to-Debug Issues: Lack of clear messages can lead to extended troubleshooting.
• App Crashes: Unhandled exceptions may cause the application to stop working entirely.
• Security Risks: Revealing internal system details in public error messages can expose vulnerabilities.

10. Bonus: Consistent Formatting ( ESLint & Prettier )

Always follow a consistent code style, including indentation, spacing, and semicolon usage. Tools like Prettier or ESLint can help automate this and ensure consistency across your codebase.

// Bad
function greet(name){
console.log('Hello, ' + name);
}

// Good
function greet(name) {
  console.log(`Hello, ${name}`);
}

Pros of Consistent Formatting:

• Professional Appearance: Well-formatted code looks professional.
• Better Collaboration: Consistency makes it easier for teams to work together.
• Faster Debugging: Standardized structure simplifies debugging and reading.

Cons of Inconsistent Formatting:

• Harder Collaboration: Inconsistent style leads to confusion among team members.
• Reduced Readability: Misaligned code is harder to understand.
• Longer Development Time: Developers waste time reformatting code manually.

There are many more ways to write cleaner codes. But these are mostly used and experienced by many developers. You will encounter these examples a lot while browsing through Github repos.

However, it should not be forgotten that none of the above-mentioned items include an approach such as the ‘it must be used like this’ topic. The complexity of the structure, the team’s project development habits, and the requirements of the task will determine the needs.

Until next time, take care! 👋

Additional Part

You can reach me through the channels below,

LinkedIn | GitHub | Personal Website

Oğuzhan YÜKSEL

Frontend Developer at ÇSTech

📖 Useful Sources:

GitHub - ryanmcdermott/clean-code-javascript: Clean Code concepts adapted for JavaScript

Clean Code in JavaScript

Writing Clean Code in JavaScript: Tips and Tricks was originally published in ÇSTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

As someone working in the e-commerce sector, my curiosity about understanding the diversity in the e-commerce experiences of users from different cultures has solidified with a desire to conduct thorough research. Through sharing the information obtained from this research, I will describe the impact of culture on the e-commerce sector.

To remain competitive, e-commerce companies today need to develop strategies for sustainability and growth in local and global markets. In this competitive environment, the designs and user experiences of e-commerce platforms should be adapted to the cultural context of the targeted geography. In this article series, we will emphasize the importance of cultural differences in e-commerce designs and look at how these interactions affect design.

As of January 2023, the 5.16 billion internet users worldwide constitute a significant part of global online shopping, with 56.5% of internet users aged 16 to 64 making online purchases weekly. [1] This statistic indicates that most individuals with internet access engage in online shopping, highlighting the expansion of user bases on e-commerce platforms and their coverage of a large segment of potential customers.

To make this large-scale e-commerce experience more effective, design factors, especially language and culture, should be considered. While 58.8% of global websites provide services in English, the question of how many in the global population can understand these English sites is crucial. Unfortunately, this ratio is quite low, as only 6% of the global population speaks English as their native language, and 75% do not speak English at all. [2] In this context, design processes should consider not only English but also other languages and cultures. Understanding cultural diversity and language differences will make the e-commerce experience more inclusive and effective on a global scale.

Connection Between Language and Culture

Language is a tool that provides information about a community’s values, beliefs, and habits. The words, expressions, and grammar rules used form a cultural identity by reflecting the worldview of that community. Therefore, communication in a language should be culturally appropriate for the culture in which the language is spoken.

E-commerce companies should pay attention not only to the grammatical rules of a language but also to the cultural context of that language when designing their platforms. It is essential to align many elements, from color choices to symbolism, page layout to content tone, with the cultural expectations of the target audience. For example, the symbolic meanings of colors used on an e-commerce site in an Asian country can vary based on cultural beliefs in that region. Similarly, the addressing style and content tone in a language should show respect for the target audience’s values.

In the upcoming sections of this article series, I will delve into specific topics by categorizing areas differentiated by culture and explore in detail the impacts of cultural differences on these elements.

Color Usage: Colors play a significant role in intercultural communication as each culture attributes different symbolism to colors, triggering specific emotional responses. In this section, we will examine in detail the effects of color palettes used on e-commerce sites in cultural contexts. For instance, we will explore how a color may have positive connotations in one culture while being perceived differently in another.

Page Layout: Page layout has a substantial impact on the usability of an e-commerce site. However, expectations for page layout may differ across cultures. In this section, we will analyze the effects of different cultures on page layout preferences. For example, we will identify differences between Eastern and Western cultures regarding page layout expectations.

Site Content: Language and content tone significantly influence users’ interaction with a website. In this section, we will emphasize the necessity for the language used on e-commerce sites to be culturally sensitive. Additionally, we will discuss intercultural content strategies and user language expectations.

Site Interaction: User experience is determined by site interaction. In this section, we will focus on how cultural factors affect the interaction of users with e-commerce sites. For example, by addressing the responses and expectations of users from different cultures to interactive elements, we will examine the interaction strategies of e-commerce sites.

With this article and the subsequent series, I aim to provide a resource for e-commerce companies to understand the relationships between these fundamental design elements and cultural diversity, enabling them to create more effective and user-friendly designs in intercultural markets.

References

[1] https://datareportal.com/global-digital-overview

[2] https://www.shu.ac.uk/about-us/academic-departments/sheffield-business-school/alumni/articles/everyone-speaks-english-dont-they

[3]https://researchportal.murdoch.edu.au/esploro/outputs/doctoral/Usability-themes-in-high-and-low/991005543416607891

[4] https://www.researchgate.net/publication/278034641_Cross-Cultural_User_Experience_Design_Helping_Product_Designers_to_Consider_Cultural_Differences

[5] https://www.statista.com/statistics/262946/most-common-languages-on-the-internet/

The Impact of Cultural Diversity on E-commerce Designs — Part 1 was originally published in ÇSTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Web Content Accessibility Guidelines (WCAG), briefly, are a set of principles that must be adhered to for greater accessibility of all content on the web. Accessibility encompasses a variety of barriers, including visual, auditory, physical, speech, cognitive, language, learning, and neurological impairments.

According to the World Health Organization (WHO), 16% of the world’s population experiences disability. Unfortunately, much of the content on the web is not adapted to this class. Therefore, with a decision by the European Union, by June 28, 2025, companies in all EU member countries must adapt their products/services to these accessibility standards.

As designers, there are some principles within the scope of accessibility standards that we need to follow. Let’s briefly examine these principles without going into too much detail and provide some guidance. (I’m leaving the links to the relevant sources at the bottom.)

Pay attention to the contrast values of colors

Ensure that the contrast between colors is measured to ensure the readability of content and text. You can use “contrast checker” plugins in Figma or perform the necessary measurements on WebAIM. The basic limits are:

• Must provide a minimum validity ratio of 4.5:1.
• For large or bold fonts, a validity ratio of 3:1 is required.
• Logos and graphic elements are not subject to these rules.

Don’t rely solely on colors

Using color alone to convey information can make your website’s content inaccessible to many people.

• Ensure that links are not changed only in color; underline them to indicate to the user that they are clickable.
• In a scenario where an input field in a form is erroneous, don’t just turn the input’s border red; instead, make a structural change by thickening the border and support it with a subtext that specifies the cause of the error and how to resolve it, accompanied by an icon.

• Do not indicate a selected element solely through color; structural changes beyond color are also necessary for the appearance of the selected area. For example, you can add an underline beneath a navigation element to signify its selection.

Note: After designing, it is generally advisable to review your design in black and white mode or share it with others in your vicinity. This way, you can identify any errors that may exist.

Ensure that interface elements are clear and distinct

Users understand that interactive elements within the site contain interactions through their structure and the text they include. Therefore, ensure that interactive content elements are presented to the user in a clear and distinct manner.

• What makes a button a button is its form. Define a shape and create variations that will be consistent in structure. (If one button has a rounded border radius, the other should not have sharp corners.)

• Color the button and distinguish it from other elements. (Some button types like [ghost, outline, etc.] may resemble input types; separate them.)
• The text of buttons/links should be specific rather than generic. For example, on an e-commerce website’s “My Orders” screen, use text like “Cancel My Order” instead of just “Cancel.”
• Your form elements (inputs) should always have a title; do not rely solely on placeholder text (text inside an input when it’s empty).

Use alternative text for all non-text content

Add clear and concise alternative text for all content that does not contain text, whether it’s visual, graphical, or lacks textual information. This will enable programs like screen readers to read this type of content to the user.

• Add alternative text for all non-text content, such as visuals, videos, and audio, to ensure accessibility for users who rely on alternative means to consume content, like screen readers.
• There is no need for alternative text for elements that are purely decorative, such as separators or background decorations.

Ensure correct focus transitions using the “Tab” key on the keyboard

Some users with motor skill disabilities may struggle to use a mouse, so they navigate websites using a keyboard.

• Clearly indicate focus states during navigation done with the “Tab” key.

• Ensure that focus states logically progress according to the site hierarchy. For example, if the first element in the header at the top of the site is selected, pressing the “Tab” key on the keyboard should not jump directly to the “About Us” page in the footer; it should follow a logical sequence.

Useful Resources:

WCAG EU Decision https://digital-strategy.ec.europa.eu/en/policies/web-accessibility-directive-standards-and-harmonisation
WCAG Principles https://www.w3.org/TR/WCAG21/
WebAIM Contrast Checker https://webaim.org/resources/contrastchecker/
Accessible Color Palette Generator: https://toolness.github.io/accessible-color-matrix/

Accessibility Principles for Designers was originally published in ÇSTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

In the dynamic world of Kubernetes, efficiently managing resources is a challenge many DevOps engineers face. Enter the Vertical Pod Autoscaler (VPA), a powerful tool that dynamically adjusts resource requests for pods. In this article, we’ll delve into what VPA is, how it works, and why it’s a game-changer in optimizing resource management within Kubernetes clusters.

What is VPA?

Vertical Pod Autoscaler (VPA) is a Kubernetes component designed to tackle the challenge of adjusting resource requests for running pods. Unlike the Horizontal Pod Autoscaler (HPA), which scales the number of pod replicas based on observed metrics, VPA focuses on modifying the resource allocations of individual pods.

VPA continuously monitors metrics like CPU and memory utilization, and based on this data, it automatically adjusts the resource requests for pods. This dynamic adaptation ensures that pods receive the right amount of resources to operate optimally, preventing both resource starvation and wastage.

VPA Modes

VPA operates in three distinct modes: Auto, Initial, and Recreate.

• Auto Mode: In this mode, VPA dynamically adjusts resource requests for running pods. When it detects a need for changes, it gracefully evicts the pod, allowing Kubernetes to recreate it with updated resource requests.
• Initial Mode: Useful for setting initial resource requests when a pod is first created. VPA ensures that the pod starts with the appropriate resource allocations based on observed metrics.
• Recreate Mode: This mode is similar to Auto but more aggressive. It directly recreates pods without gradual adjustments, making it suitable for scenarios where immediate resource changes are critical.

Implementation

Setting up VPA in your Kubernetes cluster involves a few key steps. Firstly, deploy the VPA components, including the admission controller and the VPA custom resource definition. Configure the VPA settings, specifying which pods to target and the metrics to consider for adjustments.

git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler
./hack/vpa-process-yamls.sh print
./hack/vpa-up.sh
kubectl get pods -n kube-system | grep vpa

Use Cases

VPA shines in various scenarios, from optimizing resource usage in steady-state applications to handling sudden spikes in demand. Consider a scenario where a service experiences a sudden increase in traffic. VPA can dynamically adjust resource allocations to meet the demand, preventing performance degradation.

Let’s show it with an example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ubuntu-deployment
  namespace: test
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: ubuntu-container
          image: ubuntu:latest
          command:
            - sleep
            - '604800'
          resources:
            limits:
              cpu: 200m
              memory: 300Mi
            requests:
              cpu: 10m
              memory: 100Mi

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa-3
  namespace: test
spec:
  resourcePolicy:
    containerPolicies:
      - containerName: ubuntu-deployment
        controlledResources:
          - cpu
          - memory
        maxAllowed:
          cpu: 700m
          memory: 700Mi
        minAllowed:
          cpu: 5m
          memory: 50Mi
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ubuntu-deployment
  updatePolicy:
    updateMode: Auto

The VPA-Updater acts like a vigilant watcher for your app’s needs within Kubernetes. It keeps an eye on how your apps are doing, like checking a car’s performance during a race.

It looks at metrics, kind of like how we might check the speed and fuel usage in a race car. When it sees that your apps need more “juice” to run better, it helps increase their “fuel” (CPU and memory). And if it notices they’re using way too much “fuel” unnecessarily, it steps in to help cut back, making sure your system doesn’t waste resources.

In simple terms, this helper makes sure your apps have the right resources they need to perform at their best, just like a pit crew making quick adjustments to a racing car to keep it running smoothly on the track.

Best Practices

To make the most of VPA, consider these best practices:

• Regularly monitor VPA logs and metrics to ensure it’s effectively adjusting resources.
• Fine-tune VPA parameters based on your application’s characteristics and usage patterns.
• Test VPA in a staging environment before deploying it in production to understand its impact on your specific workloads.

Conclusion

In the ever-evolving landscape of container orchestration, tools like VPA play a crucial role in ensuring optimal resource utilization. By dynamically adjusting pod resource requests, VPA contributes to improved application performance, efficient resource usage, and ultimately, a smoother Kubernetes experience. Incorporate VPA into your toolkit, and witness the difference it can make in the world of DevOps.

Sources:

https://isitobservable.io/observability/kubernetes/how-to-autoscale-in-kubernetes-and-how-to-observe-scaling-decisions

Demystifying Kubernetes’ Vertical Pod Autoscaler (VPA): Optimizing Resource Management was originally published in ÇSTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ne İşe Yarar ?

Windows cihazlarda görev zamanlayıcısı ile bir programı veya PowerShell komutlarını belirli bir zamanda veya belirli koşullar karşılandığında otomatik olarak başlatmanıza yardımcı olacaktır.

Nasıl Çalışır ?

“Windows + R” tuşlarına basıp açılan pencereye “taskschd.msc” yazarak Task Scheduler konsolunu açıyoruz.

“Create Task” seçeneğine tıkladığınızda, yeni bir görev için ad ve açıklama girmeniz gerekecek. Programı yönetici ayrıcalıklarıyla çalıştırmak için “Run whether user is logged on or not” kutusunu işaretlemeniz gerekiyor. Örneğimizde, görevi bir hizmet hesabına atayarak, kullanıcının oturum açmış olup olmamasına bakılmaksızın görevi başlatmayı planlıyoruz.

Ardından “Triggers” sekmesine geçip “New” butonuna tıklıyoruz.

“Schedule” seçeneğini seçtikten sonra sol taraftan “Daily” seçeneğini belirleyerek, görevin çalışmasını istediğimiz saati girmeli ve oluşturacağımız Trigger’ın “Enable” seçeneğini aktif hale getirmeliyiz.

“Action” sekmesine gelerek, “New” butonuna tıklıyoruz.

Açılan pencerede “Action” sekmesini “Start a program” olarak belirliyoruz. Program/Script kısmına “powershell” yazıyor. Add Argument kısmına hazırlamış olduğumuz shell dosyasının yolunu belirtiyoruz.
Örn: [-File C:\script\pwshll.ps1]” “OK” Diyoruz.

“Condition” sekmesine geçiyoruz.

Power kısmında bulunan başlıklar seçili ise bunları kaldırmamız gerekmektedir.

“Settings” sekmesininde bulunan ayarları değiştirmeden bırakıyoruz.

Ayarlamaları bu şekilde tamamladığımız zaman “OK” diyerek çıkabiliriz. Karşımıza kullanıcı adı ve şifrenin sorulduğu ekran gelecektir. Bilgisayar üzerinde oturum açılmasa bile görevin çalışabilmesi için kullanıcı adı ve parola girerek “OK” diyoruz.

ÖNEMLİ: Bu komutun çalışabilmesi için “Hizmetler” kısmında bulunan servisin başlangıç türünün “Otomatik” olarak ayarlanmış olması gerekmektedir.

Belirtilen aşamaları tamamladıktan sonra sorunsuz bir şekilde powershell komutlarınızı görev zamanlayıcısı ile otomatikleştirmiş olacaksınız.

Bir sonraki içerikte görüşmek üzere.

Ozan Dilek

Linkedin

PowerShell Komut Dosyalarını Görev Zamanlayıcıyla Otomatikleştirme was originally published in ÇSTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, we’ll explore design patterns in JavaScript and React, offering explanations and practical examples. Whether you’re new to design patterns or looking to enhance your skills, this guide will help you apply these invaluable concepts to your projects and improve your software development endeavors.

Singleton Pattern:

The Singleton pattern ensures that a class has only one instance and provides a global point of access to it. This is useful for scenarios where you want to maintain a single point of control, such as a configuration manager or a shared resource.

class Singleton {
  constructor() {
    if (Singleton.instance) {
      return Singleton.instance;
    }
    Singleton.instance = this;
  }

  someMethod() {
    // Your code here
  }
}

const instance1 = new Singleton();
const instance2 = new Singleton();

console.log(instance1 === instance2); // true

Singleton can only have one instance, and any subsequent attempts to create new instances will return the original instance.

Proxy Pattern:

The Proxy pattern provides a surrogate or placeholder for another object to control access to it. It can be used for various purposes, such as lazy loading of resources or access control.

class RealImage {
  display() {
    console.log("Displaying the real image.");
  }
}

class ProxyImage {
  constructor() {
    this.realImage = new RealImage();
  }

  display() {
    console.log("Loading the image...");
    this.realImage.display();
  }
}

const image = new ProxyImage();
image.display();

ProxyImage serves as a proxy for the RealImage. It controls access to the RealImage and can perform additional tasks, such as loading the image before displaying it.

Factory Pattern:

The Factory pattern is a creational pattern that abstracts the process of object creation, allowing the client code to be decoupled from the specific classes being instantiated.

class Car {
  constructor(make, model) {
    this.make = make;
    this.model = model;
  }
}

class Bicycle {
  constructor(type) {
    this.type = type;
  }
}

class VehicleFactory {
  createVehicle(type, ...args) {
    if (type === 'car') {
      return new Car(...args);
    } else if (type === 'bicycle') {
      return new Bicycle(...args);
    } else {
      throw new Error("Unsupported vehicle type");
    }
  }
}

const factory = new VehicleFactory();
const car1 = factory.createVehicle('car', 'Toyota', 'Camry');
const bicycle1 = factory.createVehicle('bicycle', 'Mountain');

console.log(car1); // Car { make: 'Toyota', model: 'Camry' }
console.log(bicycle1); // Bicycle { type: 'Mountain' }

The VehicleFactory abstracts the creation of Car or Bicycleobjects. This separation allows you to create different types of vehicles or change the creation logic without modifying the client code.

This class-based Factory Pattern still provides the abstraction for creating objects and allows you to maintain a consistent interface for object creation while using modern ES6 class syntax.

Observer Pattern:

The Observer pattern defines a one-to-many relationship between objects, so when one object changes state, all its dependents are notified and updated automatically.

class Subject {
  constructor() {
    this.observers = [];
  }

  addObserver(observer) {
    this.observers.push(observer);
  }

  notify(message) {
    this.observers.forEach(observer => observer.update(message));
  }
}

class Observer {
  update(message) {
    console.log(`Received message: ${message}`);
  }
}

const subject = new Subject();
const observer1 = new Observer();
const observer2 = new Observer();

subject.addObserver(observer1);
subject.addObserver(observer2);

subject.notify("Hello, observers!");

The Subject maintains a list of observers, and when it changes state (in this case, sends a message), all registered observers are notified.

This is the end of the topics about Javascript Design Patterns. Now let’s move on to the React Design Patterns which are more widely used nowadays.

React Design Patterns

Container / Presentational Pattern

The Container/Presentational pattern separates the logic (Container components) from the rendering (Presentational components). Container components handle data and state management, while Presentational components focus on rendering.

// Container Arrow Function Component
import React, { useState } from 'react';
import Presentation from './Presentation';

const Container = () => {
  const [data, setData] = useState([]);

  // Logic and state management

  return <Presentation data={data} />;
};

export default Container; // Export the Container component

// Presentational Component
const Presentation = ({ data }) => {
  // Rendering logic using data
};

export default Presentation; // Export the Presentation component

Container components like Container handle data fetching and state management, while Presentational components like Presentation focus solely on rendering.

Higher-Order Component (HOC) Pattern:

A Higher-Order Component (HOC) is a function that takes a component and returns a new component with added behavior or props.

import React from 'react';

const withLogger = WrappedComponent => {
  return class ComponentWithLogger extends React.Component {
    componentDidMount() {
      console.log(`Component ${WrappedComponent.name} has mounted.`);
    }

    render() {
      return <WrappedComponent {...this.props} />;
    }
  };
};

const MyComponent = () => <div>My Component</div>;
const MyComponentWithLogger = withLogger(MyComponent);

Here, withLogger is a HOC that logs when a component is mounted. It enhances the MyComponent with additional behavior.

While HOCs were initially associated with class components, you can create and use HOCs with functional components using React hooks. In order not to make it too long, I will not give an example of functional component usage separately.

Provider & Compound Pattern:

The Provider pattern, frequently utilized in conjunction with the Context API, is a powerful tool for managing shared data in React. It allows you to pass data or functionality down the component tree without the need for explicit prop drilling.

import React, { createContext, useContext } from 'react';

const MyContext = createContext();

function MyProvider({ children }) {
  const value = { data: 'Some context data' };
  return <MyContext.Provider value={value}>{children}</MyContext.Provider>;
}

function ConsumerComponent() {
  const value = useContext(MyContext);
  return <div>{value.data}</div>;
}

The MyProvider component wraps its children with a context that provides shared data. Nested components like ConsumerComponent can easily access this data without the need for passing it explicitly through props. The Provider pattern simplifies data management and reduces the complexity of component communication.

There are many more design patterns available. You can use these examples as a starting point to discuss each design pattern’s purpose, benefits, and how they can be applied in JavaScript and React applications.

PS: In the React world, Functional components have become increasingly popular, and they offer a clean and concise way to implement these patterns in modern React applications. Being eye familiar with those would help to understand and write better code.

Until next time, take care! 👋

Additional Part

You can reach me through the channels below,

LinkedIn: https://www.linkedin.com/in/developeroguzyuksel/

GitHub: https://github.com/ooguzyuksel

Oğuzhan YÜKSEL

Frontend Developer ÇSTech

📖 References and Sources:

• JavaScript Patterns Workshop | JavaScript Patterns
• Learning JavaScript Design Patterns - The Examples
• Patterns.dev
• React Patterns

Design Patterns Widely Used by JavaScript & React Developers was originally published in ÇSTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

JavaScript is one of the milestones of web development. It is used to increase interaction on websites and add dynamism to the websites. The size of JavaScript varies depending on the size of websites. Since the JavaScript used in large projects will be large, the code must be clean, readable, and reusable. JavaScript Modules are used for this. In this article, I will explain what the JavaScript Module concept is, why it is needed, what solutions have been developed, how it is used, and what advantages it offers.

What is the concept of JavaScript Modules?

JavaScript modules are used to split your code into smaller, more manageable pieces rather than keeping it in a single file and moving those pieces to other files or projects. Modules can contain functions, variables, and objects that perform specific functions. With modules, code complexity decreases, code readability and reusability increase significantly and repetition is minimized.

Why are JavaScript Modules needed?

When JavaScript first came out, people’s interaction scenarios on websites were limited. For this reason, JavaScript files were small and consisted of code fragments. But over time, websites grew and many more scenarios emerged. With these developments, JavaScript codes have also grown and become more complex. As the codes grew larger, it became harder for developers to keep track. This is where JavaScript modules came into play. Instead of writing all the codes in a single file, the codes began to be written in modules.

Module Solutions

When JavaScript modules first came into use, there was no official standard or structure. That’s why different developers created their own solutions. CommonJS, AMD(Asynchronous Module Definition), UMD(Universal Module Definition), and ES Modules are widely used JavaScript module systems. Now let’s examine these module systems.

CommonJS

CommonJS aims to provide a standard way of writing JavaScript, especially for server-side applications. It has been used especially in Node.js projects. It was developed in 2009 by Kevin Dangoor, who worked as a software engineer at Mozilla Corporation. The module.exports object is used to export the codes in a module. We can use the require method to import these codes in another file. These operations ensure the synchronous loading of modules. Now, let’s take a look at its usage.

//user.js
function User(fullName, phone) {
  var returnObj = {
    fullName : fullName,
    phone : phone,
    contactInfo: 'Contact Info: ' + fullName + ' ' + phone
  }
  return returnObj
}

module.exports = User;

//main.js
const User = require('./user.js');
const person = User('James Bond', '5555555555');

console.log(person.contactInfo) -> Contact Info: James Bond 5555555555

AMD (Asynchronous Module Definition)

AMD is a module system designed specifically for client-side applications. It was developed by James Burke, who worked at Mozilla Corporation, in 2011 (https://github.com/amdjs/amdjs-api). Unlike CommonJS, modules are loaded asynchronously in AMD. It is a system adopted by the RequireJs library and is better in terms of performance and usability because it is loaded asynchronously. The define method is used to define modules. Let’s take a look at AMD’s usage.

//user.js
define([], function() {

  return {
    fullName: function() {
      console.log('James Bond');
    },
    phone: function() {
      console.log('5555555555');
    }
  };
});

//main.js
define(['user', 'otherUser'], function(user, otherUser) {
  console.log(user.fullName()); -> James Bond
});

UMD (Universal Module Definition)

UMD is a universal module system that supports features from AMD and CommonJs, which can be used in both client-side and server-side applications. UMD controls the environment in which the module is run. It provides the flexibility to use it on both the client and server side. You can review this module system, developed in 2015, from Addy Osmani’s repository: https://github.com/umdjs/umd
Due to its syntax structure, I think it may cause complexity in projects.

//user.js
(function (root, factory) {
  if (typeof define === 'function' && define.amd) {
      //for AMD
    define([], factory);
  } else if (typeof exports === 'object') {
      //for CommonJS
    module.exports = factory();
  } else {
    //for Browser
    root.User = factory();
  }
}(typeof self !== 'undefined' ? self : this, function () {
  //Methods
  function contactInfo(fullName, phone){
    return 'Contact Info: ' + fullName + ' ' + phone;
  };
  //The part of the module to be exported
  return {
      contactInfo: contactInfo
  }
}));

//main.js
var User = require('./user');
var result = User.contactInfo('James Bond', '5555555555');
console.log(result); -> Contact Info: James Bond 5555555555

ES Modules

ECMAScript (ES) Modules represent the entry of the JavaScript world into a more modern era. Module support was added to JavaScript with ECMAScript 6 (ES6) in 2015. It can be used in client-side and server-side applications and provides support for asynchronous module loading. Syntax of the ES Module is also much simpler than other module solutions. It manages the data flow between modules using the import and export keywords.

Among the solutions offered for modules, the current solution is ES Modules. However, it took quite a long time to reach this official solution. The different module systems created in this process have led to incompatibility and complexity in the JavaScript ecosystem.

Now, let’s take a look at the use of ES Modules.

//user.js
export const user = (fullName, phone) => {
  var returnObj = {
    fullName : fullName,
    phone : phone,
    contactInfo: 'Contact Info: ' + fullName + ' ' + phone
  }
  return returnObj
}

//main.js
import { user } from './user.js'
const person = user('James Bond', '5555555555');

console.log(person.contactInfo) -> Contact Info: James Bond 5555555555

Since ES Modules are the current method used at the moment, I would like to discuss some terms and usage patterns related to import and export in subheadings.

export default: We can export multiple functions, variables, or objects to a different file by using the ‘export’ keyword. In the example above, if there was an age calculation function in addition to the ‘user’ function, we could export it by adding the ‘export’ keyword to the beginning of this function in the same way. Additionally, we could export the two functions without using the ‘export’ keyword as follows: export {user, ageCalculate}While importing, we could also import two functions using the ‘import’ keyword: import {user, ageCalculate} from ‘./user.js’This usage method is very useful in cases where we want to transfer more than one function, variable or object. However, if we only want to export a single function in a file, the ‘export default’ keyword may be more useful. We can import the function we exported with ‘export default’ with a different name. In the example below, the results for ‘User’ and ‘Profile’ will be the same.

//user.js
export default User = (fullName, phone) => {
  ......
}

//main.js
import User from './user.js' 
//or 
import Profile from './user.js'

• alias: When we want to change the name of a function while importing it, we can use the “as” keyword. This method is generally used to prevent functions with the same name from conflicting in different files.

import {user as person} from './user.js'

• namespaces: We can use “* as” keywords to import all functions within a single object. We can import all the functions we export in a file with a single name.

import * as profile from '/user.js'
profile.ageCalculate();
profile.user();

• combine exports: When we need multiple modules in a single file, we can create a new file and import the modules we want to use there. When we need several modules in one file, we do not need to open a new file. However, when we need a lot of modules, we can collect the modules in a new file as in the example below. Then, we can write much cleaner code using this module directly. I use this method frequently and I think it increases the readability and reusability of the code.

// combine.js
import * as profile from 'user.js';
import * as calc from 'calc.js';
....

// main.js
import * as combine from 'combine.js'

combine.profile.ageCalculate();

• dynamic import: We can use the dynamic import feature to import the module we want to use only when necessary. In this way, we can make the code more efficient and control the modules we need better. You can see an example of using dynamic import in the code block below.

//main.js
if(a == b) {
  const {user} = await import('./user.js');
  user('James Bond', '5555555555');
}

The Advantages of Modules

Let’s summarize the advantages I mentioned when talking about modules.📝

• Code Readability
• Reusability
• Ease of Teamwork
• Ease of Debugging
• Performance Improvements

Conclusion

JavaScript modules are an essential part of modern web development. It is the preferred tool for developers to split code into small independent pieces and use these pieces as needed. They enable better organization and reuse of code in small and large-scale applications and make the development process more efficient.

The modules I use frequently make my development process easier. Thanks to modules, I think that making the code more readable and understandable is important for the sustainability of the project. For this reason, I recommend that every developer learn about modules and use them in their projects. 🤗
Best regards.

Resources

• JavaScript Reference Guide: JS module ecosystem - LogRocket Blog
• JavaScript Modules: A Beginner's Guide
• JavaScript modules - JavaScript | MDN

JavaScript Modules: Strategies to Improve Code Quality and Efficiency was originally published in ÇSTech on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi everyone!

In recent years, the web development world has witnessed the development of various server-oriented rendering models, in part following the widespread adoption of Single Page Applications (SPAs). In this article, we will discuss Streaming SSR, which aims to eliminate some of the disadvantages of Server Side Rendering (SSR), one of the most popular rendering patterns.

To better comprehend the impact of these rendering patterns, we will also often refer to Web Vitals metrics such as TTFB, TTI, FPC or CLS. You can revisit these metrics for a more comprehensive understanding at this link: https://web.dev/articles/user-centric-performance-metrics

So, what exactly is Streaming SSR, and how does it differentiate itself in the realm of web development? Let’s embark on a journey to explore this exciting new rendering pattern.

What is Server-Side Rendering (SSR)?

Server Side Rendering is one of the popular rendering patterns where web pages are initially rendered on the server before being sent to the client’s browser. In contrast to client-side rendering, where the browser handles most of the rendering work, SSR performs the rendering on the server.

Here’s how it works:

1. A request is sent from the client to the server.
2. On the server, HTML is generated. The server has the ability to create new HTML content for each request. This HTML is then sent to the browser. (TTFB point)
3. The browser parses and renders this HTML. At this point, we have a UI that can be displayed to the user, but the user cannot interact with it because we need JavaScript.
4. The browser sends a request to fetch the necessary JavaScript bundle and downloads it.
5. The browser executes the JavaScript and performs hydration. (TTI Point)

Some key benefits of Server-Side Rendering are:

1. Improved SEO: Search engines can easily crawl and index the content because the initial page load is fully rendered on the server. This can lead to better search engine rankings compared to purely client-side rendering, which search engines may have difficulty parsing.
2. Accessibility: SSR can enhance accessibility because the initial HTML content is readily available, making it easier for screen readers and other assistive technologies to interpret the content.
3. Better User Experience: Since users receive a fully rendered page, they can start consuming the content more quickly, providing a better user experience. Also no flicker UI issues or CLS problems.

Is everything about SSR so good? Unfortunately, no. Like any rendering pattern, SSR has strengths and weaknesses too. We will examine two potential drawbacks of Server-Side Rendering (SSR), which are Initial Waiting Time which is related Time to First Byte (TTFB) metric and The Interactive Delay which is related Time to Interactive (TTI) metric.

TTFB — The Initial Waiting Time: One downside of SSR is the prolonged Time to First Byte (TTFB), which is the time it takes for the first byte to reach the user’s browser. This delay occurs because SSR involves rendering all HTML on the server, including bundling JavaScript, which requires waiting for essential data requests and executing rendering logic. As a result, users may experience a blank screen during the initial loading process, which can impact the user experience.

TTI — The Interactive Delay: In the context of SSR, Time to Interactive (TTI) can be delayed. While the initial HTML may be visible, full interactivity is postponed as the browser loads and executes JavaScript. This delay can affect the overall user experience.

A new rendering pattern has entered our lives with React 18 to mitigate these two adverse effects: Streaming SSR.

What is the Streaming SSR?

Streaming SSR is a method that improves TTFB and TTI while performing server-side rendering. The logic behind streaming is that we have a concept called Node streams, which allows us to continuously transfer data in pieces.

In standard SSR, rendering all the HTML that makes up our page on the server and then transferring all the necessary JS for that HTML to the client via a bundle, as discussed in the previous section, revealed the disadvantages of TTFB and TTI. Streaming SSR provides a solution by rendering each component separately and creating JS bundles on a component-by-component basis, allowing us to stream everything in pieces (we called them chunks) that we will show on the page.

Let’s try to understand how it works by examining it step by step:

1. A request is sent from the client to the server.
2. The server now returns a mechanism for data transfer using node streams along with a basic HTML file to the browser. (This basic HTML file also contains the necessary data for SEO, so we don’t have any SEO disadvantage.)
3. The client receives this HTML and parses it just like it behaves in SSR. Node stream data flow also starts at this point.
4. The server transmits the UI of the completed rendering components and the necessary JS in chunks to the browser.
5. The browser executes and hydrates these chunks, making them ready.

One of the most notable benefits of this approach is the elimination of the need to wait for the entire server-rendered content to be generated. Consequently, the Time to First Byte (TTFB) is significantly reduced.

Another noteworthy advantage pertains to the process of hydration. In traditional Server-Side Rendering (SSR), the entire execution of a substantial JavaScript bundle was required. This bundle encompassed code for all the elements on the page. However, with the new approach, we can selectively execute only the necessary code for a specific portion, leading to a vastly improved Time to Interactive (TTI).

As a result, the moment the hydration of the initial chunk is completed, the Time to Interactive (TTI) becomes nearly instantaneous. This signifies that the browser becomes interactive at this very point.

Streaming SSR Implementation w/NextJs 13

We have completed the theoretical part. Now let’s learn how to implement this new pattern with Next.js.

With NextJS 13, data fetching methods have changed a bit from previous versions. Now, with default server components, you can fetch data directly within a component without using any effect hooks or server-side props such as getServerSideProps.

For example, you can see a standard SSR page structure below:

export default async function Page() {

  /**
   * To shorten the TTFB time, requests are optimized by parallelizing them.
   */
  const productsPromise = getProducts();
  const personsPromise = getPersons();
  const plansPromise = getPlans();

  const [productData, personsData, plansData] = await Promise.allSettled([
    productsPromise,
    personsPromise,
    plansPromise
  ]);

  return (
    <div>
      <Products data={productData} />
      <Persons data={personsData} />
      <Plans data={plansData} />
    </div>
  );
}

In this structure, before the user can view the page, all requests must first be completed, and then all components on the page must be created on the server side using this data. The HTML and JS resulting from this process are sent to the browser.

So how do we implement streaming SSR in this structure?

1. Component-Specific Data Fetching

Each component should be in charge of getting its own data. The main idea is to separate the rendering of components and make sure that any component with its data ready can be shown on its own. So, we need to start splitting up our data requests for each component.

2. React Suspense

We need to wrap Component with Suspense to tell React that this component can be rendered with streaming SSR.

We already knew the Suspense and were used for Code Splitting. With React 18, Suspense allows us to create streamable components. For more detail look at this React Doc.

Let’s look below implementation closely:

export default function Page() {

  return (
    <div>
      <Suspense fallback={<Skeleton/>}>
        <Persons />
      </Suspense>
      <Suspense fallback={<Skeleton/>}>
        <Plans />
      </Suspense>
      <Suspense fallback={<Skeleton/>}>
        <Products />
      </Suspense>
    </div>
  );
}

In Streaming SSR, every component wrapped with Suspense completes its own rendering after completing its own fetching and is then streamed to the browser. This means that we don’t need to wait for all three requests to complete and the entire page rendering to finish, as we would in a standard SSR example. Also after the first hydration (it means TTI point) browser becomes user-interactive. So that the user doesn't have to wait for other components that are still rendering.

Another advantage of streaming is that you can even use it externally for a child component on your page. There is no limitation to this. Thus, you can apply this method even to the bottom child of nested components.

In addition to these, Next.js 13 also provides a Loading UI feature that relies on streaming. This helps improve the user experience by displaying skeletons or what you want to display in the content section of your page until the Time To First Byte (TTFB) is completed. This way, users can see a loading indicator or placeholders until the actual content is ready, enhancing the overall UX. For more details follow the link.

Also, I created a basic demo that includes standard SSR page, SSR + Loading UI page and Streaming SSR page.

You can review the live demo here and reach out source code here.

Conclusion

In this article, we have dived into the fascinating world of Streaming Server-Side Rendering (SSR), an exciting new rendering pattern that has emerged in the ever-evolving landscape of web development.

Streaming SSR comes as a promising solution to address some of the longstanding challenges associated with traditional Server-Side Rendering (SSR), namely Time to First Byte (TTFB) and Time to Interactive (TTI) delays. In addition, streaming SSR brings brand new options to hybrid structures such as CSR + SSR, which we use to optimize performance. This is really exciting.

As ÇSTech, we closely follow and care about innovations such as Streaming SSR for a better UX and DX, and try to implement them in our current applications.

As I always say, you can always reach me at the addresses below for your questions or suggestions.

Until we meet again, stay in tech.

Oğuzhan Sofuoğlu

Frontend Developer @ÇSTech

Github | Linkedin | Personal Website

References:

• Streaming Server-Side Rendering | JavaScript Patterns
• Streaming Server-Side Rendering
• React Conf 2021 Recap - React
• File-system conventions: loading.js | Next.js
• User-centric performance metrics | Articles | web.dev

Server-Side Rendering Evolved: Unlocking Faster TTFB and TTI with Streaming SSR was originally published in ÇSTech on Medium, where people are continuing the conversation by highlighting and responding to this story.