What is AEM?

AEM (Adobe Experience Manager) is a CMS used to:

• Create websites
• Manage content
• Manage digital assets
• Run workflows
• Deliver content to users

Think of AEM as:

🏢 A big content factory

High-Level AEM Architecture

Main Parts:

User Browser
     ↓
Dispatcher (Cache)
     ↓
Publish Server
     ↓
Author Server
     ↓
Oak Repository

Core Building Blocks of AEM

AEM mainly works on:

1. Sling
2. Oak
3. OSGi
4. JCR

Let’s understand each in simple language 👇

What is Sling?

Sling is the web framework used by AEM.

It handles:

• URL mapping
• Request processing
• Component rendering

Simple Example:

When user hits:

/content/site/home.html

Sling:

1. Finds the resource
2. Finds its resourceType
3. Maps it to component
4. Renders HTL file

Sling Flow

URL
  ↓
Sling resolves resource
  ↓
Component found
  ↓
HTL renders
  ↓
HTML returned

What is Oak?

Oak is the database engine of AEM.

It stores:

• Pages
• Components
• Templates
• Assets
• Workflows
• Users

Oak implements JCR.

Content Structure in Oak

Everything is stored as a tree:

/content
    /site
        /home
            jcr:content
                title = "Welcome"

Oak stores:

• Nodes
• Properties
• Binaries

What is JCR?

JCR = Java Content Repository (Specification)

It defines:

• How content is stored
• How to query content
• How versioning works

Important:

JCR = Rules
Oak = Engine implementing those rules

What is OSGi?

OSGi manages:

• Services
• Bundles
• Configurations

Example:

• Servlet
• Scheduler
• Service class

Everything in AEM runs as an OSGi bundle.

Full Request Lifecycle in AEM

Let’s understand what happens when user opens a page.

1. User hits URL
2. Dispatcher checks cache
3. If not cached → request to Publish
4. Sling resolves resource
5. Oak fetches content
6. Component HTL renders
7. HTML sent back

How Everything Connects

User Request
      ↓
Dispatcher
      ↓
Sling (routing)
      ↓
Oak (content)
      ↓
Component (HTL)
      ↓
Response

Simple Real-World Analogy

Think AEM like a restaurant:

• Sling = Waiter (takes order)
• Oak = Kitchen storage
• OSGi = Kitchen manager
• HTL = Chef preparing dish
• Dispatcher = Reception desk

30-Second Interview Summary

AEM architecture is built on Sling for request resolution, Oak as the JCR repository for content storage, and OSGi for modular services. When a user requests a page, Sling resolves the resource, Oak retrieves content, and HTL renders the response.

Key Takeaways

✔ Sling handles request
✔ Oak stores content
✔ JCR defines structure
✔ OSGi manages services
✔ Dispatcher caches content

Bonus Points :

1. When a user hits /content/site/home.html, Sling resolves the URL to a JCR resource stored in Oak.
2. Sling reads the sling:resourceType of that node and maps it to the corresponding component.
3. The component’s HTL file renders the content, and the final HTML is returned to the browser.

Visual: Sling URL Decomposition

Example URL:

/content/site/home.print.a4.html

Breakdown:

• /content/site/home → Resource Path
• print → Selector
• a4 → Selector
• html → Extension

Sling uses this structure to decide:

• Which resource?
• Which script?
• What format?

Visual: Sling Request Flow Inside AEM

Flow:

Browser Request
      ↓
Dispatcher
      ↓
Sling Resolver
      ↓
Oak Repository
      ↓
Component (HTL)
      ↓
HTML Response

Visual: Oak Repository Structure

Oak stores content as a tree:

/content
   /site
      /home
         jcr:content
            title = "Welcome"

Sling fetches this node and renders it.

When a URL like /content/site/home.html is requested, Sling resolves the resource from Oak, maps its resourceType to a component, executes the HTL script, and returns the rendered HTML.

It allows tasks to run automatically at specific times without manual intervention.

Why do we use Scheduler?

Common real-world use cases:

• Delete old logs daily
• Sync data every hour
• Send reports every morning
• Clean expired cache nightly
• Import/export data automatically

Example:

Instead of manually deleting logs daily, you configure a scheduler to do it at midnight automatically.

Scheduler Execution Flow

AEM Starts
     ↓
OSGi Configuration Loaded
     ↓
Scheduler Component Activated
     ↓
Scheduler Registered with Cron Expression
     ↓
run() Method Executes Automatically
     ↓
Task Runs at Scheduled Time

Ways to Implement Scheduler in AEM

Method 1: Whiteboard Pattern (OLD)

Uses deprecated annotations.

Not recommended now.

Method 2: Scheduler API (Recommended)

Uses:

• OSGi annotations
• Sling Scheduler
• Configurable cron expression

This is the modern and production-safe approach.

Implementation Using Scheduler API

We create scheduler in two parts:

1. OSGi Configuration
2. Scheduler Service

Step 1 — Create OSGi Configuration

File

GeeksSchedulerConfiguration.java

Code

package com.site.myproj.core.OSGIConfig;
import org.osgi.service.metatype.annotations.*;
@ObjectClassDefinition(
        name = "AEM Scheduler Configuration",
        description = "Scheduler Configuration"
)
public @interface GeeksSchedulerConfiguration {
    @AttributeDefinition(
            name = "Scheduler Name",
            description = "Unique scheduler name"
    )
    String schedulerName() default "My Scheduler";
    @AttributeDefinition(
            name = "Cron Expression",
            description = "Cron job expression"
    )
    String cronExpression() default "0 0/1 * * * ?";
}

Purpose

This creates a configuration in Felix console so scheduler timing can change without code changes.

Step 2 — Create Scheduler Service

File

GeeksScheduler.java

Code

package com.site.myproj.core.schedulers;
import com.site.myproj.core.OSGIConfig.GeeksSchedulerConfiguration;
import org.apache.sling.commons.scheduler.*;
import org.osgi.service.component.annotations.*;
import org.osgi.service.metatype.annotations.Designate;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
@Component(service = Runnable.class, immediate = true)
@Designate(ocd = GeeksSchedulerConfiguration.class)
public class GeeksScheduler implements Runnable {
    private static final Logger LOGGER =
            LoggerFactory.getLogger(GeeksScheduler.class);
    private int schedulerID;
    @Reference
    private Scheduler scheduler;
    @Activate
    protected void activate(GeeksSchedulerConfiguration config) {
        schedulerID = config.schedulerName().hashCode();
        addScheduler(config);
    }
    @Deactivate
    protected void deactivate() {
        scheduler.unschedule(String.valueOf(schedulerID));
    }
    private void addScheduler(GeeksSchedulerConfiguration config) {
        ScheduleOptions options =
                scheduler.EXPR(config.cronExpression());
        options.name(String.valueOf(schedulerID));
        options.canRunConcurrently(false);
        scheduler.schedule(this, options);
    }
    @Override
    public void run() {
        LOGGER.info("Scheduler executing task...");
    }
}

Important Code Explanation

@Component

Registers class as OSGi component.

@Activate

Runs when component starts.

@Deactivate

Stops scheduler on shutdown.

scheduler.schedule(…)

Registers task.

run()

Actual logic runs here.

Cron Expression Examples

Expression Meaning0 * * * * ?Every minute 0 0/5 * * * ?Every 5 minutes0 0 0 * * ?Midnight daily0 0 12 * * ?Noon daily

Cron format:

Seconds Minutes Hours Day Month DayOfWeek

Deploy and Test Scheduler

Step 1 — Deploy Code

Run:

mvn clean install

Deploy package to AEM.

Step 2 — Check Component Status

Open:

http://localhost:4502/system/console/components

Search for scheduler class.

Status should be:

Active

Step 3 — Configure Scheduler

Open:

http://localhost:4502/system/console/configMgr

Search:

AEM Scheduler Configuration

Set cron expression.

Save.

Step 4 — Check Logs

Open:

crx-quickstart/logs/error.log

You should see:

Scheduler executing task...

every configured interval.

Where Can You Test Scheduler?

You can test scheduler in:

1. Local AEM Instance

http://localhost:4502

2. AEM Dev Environment

Company Dev server.

3. AEM Cloud Dev Instance

Cloud Manager environments.

Recommended Testing Method

Add temporary log:

LOGGER.info("Running scheduler test");

Then watch logs.

Common Mistakes

Forgetting unschedule
Hardcoding cron expression
Running heavy DB operations directly
Multiple schedulers with same name

Real Enterprise Use Cases

• Product feed import
• DAM cleanup
• Cache refresh
• User sync
• Report generation

Interview Answer Summary

What is Scheduler in AEM?

Scheduler allows automatic execution of tasks at scheduled times using Sling Scheduler and cron expressions.

How is it implemented?

Using Runnable service + Scheduler API + OSGi configuration.

Final Execution Flow Diagram

AEM Start
   ↓
OSGi Config Loaded
   ↓
Scheduler Activated
   ↓
Cron Trigger
   ↓
run() Executes
   ↓
Task Completed

Summary

An AEM Scheduler is used to automatically run tasks at specific times, similar to setting an alarm for your code. It is commonly used for activities like cleaning old logs, syncing data, refreshing cache, or generating reports without manual effort. In AEM, the recommended way to implement a scheduler is by using the Sling Scheduler API along with OSGi configuration and a class implementing the Runnable interface, where the run() method contains the logic to execute. Once the component is active, the scheduler runs automatically based on a defined cron expression, which specifies the execution timing. Developers can test and monitor scheduler execution through the AEM component console, configuration manager, and log files. A cron expression follows the format Seconds, Minutes, Hours, Day, Month, and Day of Week, for example 0 * * * * ? runs every minute, 0 0/5 * * * ? runs every five minutes, and 0 0 0 * * ? runs daily at midnight.

Overview

Public-facing AEM applications must be protected against:

• Bot traffic
• Spam submissions
• Brute-force attacks
• DDoS attempts
• API abuse

Security is implemented using:

reCAPTCHA Implementation in AEM

reCAPTCHA is provided by Google to verify human users.

Typical Flow

User → AEM Page → reCAPTCHA → Token Generated
      → Token submitted → AEM Servlet
      → Google verification → Accept/Reject

Step-by-Step Implementation

Step 1 — Generate reCAPTCHA Keys

1. Register domain in Google reCAPTCHA console
2. Select version:

• v2 Checkbox
• v2 Invisible
• v3 Score-based

You receive:

Site Key
Secret Key

Step 2 — Store Keys in AEM

Create OSGi configuration:

/apps/project/config/com.project.core.services.RecaptchaConfig.cfg.json

Example:

{
  "siteKey": "SITE_KEY",
  "secretKey": "SECRET_KEY",
  "verifyUrl": "https://www.google.com/recaptcha/api/siteverify"
}

Step 3 — HTL Frontend Changes

Add reCAPTCHA script:

<script src="https://www.google.com/recaptcha/api.js" async defer></script>

Add widget in form:

<form method="POST" action="/bin/contact">

  <input type="text" name="name">

  <div class="g-recaptcha"
       data-sitekey="${recaptcha.siteKey}">
  </div>

  <button type="submit">Submit</button>

</form>

Step 4 — Servlet Implementation

Create servlet:

@Component(service = Servlet.class,
 property = {
  "sling.servlet.paths=/bin/contact",
  "sling.servlet.methods=POST"
 })
public class ContactServlet extends SlingAllMethodsServlet {
protected void doPost(SlingHttpServletRequest req,
                       SlingHttpServletResponse resp)
                       throws IOException {
   String token = req.getParameter("g-recaptcha-response");
   if(verifyToken(token)) {
       resp.getWriter().write("Success");
   } else {
       resp.getWriter().write("Captcha Failed");
   }
 }
}

Step 5 — Token Validation Logic

Server validates token:

private boolean verifyToken(String token) {
    // HTTP call to Google API
    // send secret + token
    return true;
}

Step 6 — Dispatcher Rule Protection

Block direct servlet access if needed:

/filter {
  /0001 { /type "allow" /url "/bin/contact" }
}

WAF Implementation

A Web Application Firewall (WAF) protects applications from attacks.

Common enterprise providers include Cloudflare and Amazon Web Services.

WAF Placement

User
  ↓
CDN
  ↓
WAF
  ↓
Dispatcher
  ↓
AEM Publish

WAF Blocks

• SQL injection
• XSS attacks
• Bot traffic
• DDoS
• malicious headers
• suspicious IP ranges

WAF Setup Steps

1. Configure domain behind CDN/WAF.
2. Enable managed firewall rules.
3. Enable bot protection.
4. Enable rate limiting.
5. Restrict admin URLs.

Example blocked paths:

/system/console
/crx/de
/apps/*
/libs/*

Rate Limiting Implementation

Rate limiting prevents request flooding.

Example:

Max 100 requests per minute per IP

Option 1 — CDN/WAF Level (Recommended)

Example rule:

If IP > 100 req/min
Block for 10 minutes

Best performance since AEM is not hit.

Option 2 — Dispatcher Level

Example:

/filter {
  /0002 {
    /type "deny"
    /url "/bin/contact"
    /limit 100
  }
}

Option 3 — Servlet Level (Not Recommended)

Map<String, Integer> requests;

Count requests per IP.

Poor scalability.

Recommended Production Architecture

User
  ↓
CDN
  ↓
WAF + Rate Limit
  ↓
Dispatcher Cache
  ↓
AEM Publish

Forms use:

reCAPTCHA → Servlet Validation

Best Practices

Always validate captcha on backend
Keep secret keys secure
Apply rate limits on APIs/forms
Use dispatcher caching
Protect AEM consoles
Enable logging & monitoring

Interview Questions & Answers

Q1. Why use reCAPTCHA in AEM?

To prevent automated bots from submitting forms or abusing endpoints.

Q2. Where should captcha validation happen?

On backend servlet only.

Q3. What is WAF?

A firewall protecting applications from web attacks.

Q4. Difference: WAF vs reCAPTCHA?

reCAPTCHAWAFValidates userFilters trafficForm-levelNetwork-level

Q5. Best place for rate limiting?

CDN/WAF layer.

Q6. How do you protect AEM publish?

Using:

• Dispatcher filters
• WAF
• Rate limiting
• reCAPTCHA

Q7. Why not rate-limit in servlet?

Consumes AEM resources and fails at scale.

Q8. What happens if captcha API fails?

Fallback error handling or allow retry.

Q9. How do you secure /bin endpoints?

Dispatcher allow rules + authentication + rate limiting.

Q10. How do enterprises protect AEM?

Using multi-layer protection:

CDN + WAF + Dispatcher + Captcha + Auth

Final Summary

AEM applications are secured using three main mechanisms: reCAPTCHA, WAF, and rate limiting. reCAPTCHA is integrated into forms to prevent automated bots from submitting spam by validating users on the backend before processing requests. A Web Application Firewall (WAF) sits in front of AEM to block malicious traffic such as injection attacks, bot floods, and unauthorized access attempts before they reach the publish servers. Rate limiting further protects the system by restricting how many requests a user or IP address can make in a given time, preventing abuse and server overload. Together, with dispatcher filtering and proper backend validation, these measures ensure that AEM environments remain secure, performant, and protected from automated and malicious traffic.

Introduction

Modern digital applications no longer rely on server-rendered HTML alone. Content today must be delivered across multiple channels including websites, mobile applications, smart devices, and third-party platforms.

A headless CMS architecture enables this flexibility by separating content management from content presentation.

Adobe Experience Manager (AEM) provides a robust enterprise-grade headless implementation using:

• Content Fragment Models
• Content Fragments
• GraphQL APIs

This article explains the full setup process and architectural understanding of AEM as a Headless CMS.

1. What Is a Headless CMS?

A headless CMS is a content management system that stores and governs structured content but does not render HTML pages.

Instead of returning fully built web pages, it exposes structured data (typically JSON) through APIs.

Traditional CMS:

• Backend renders HTML
• Frontend consumes complete pages

Headless CMS:

• Backend exposes structured content
• Frontend applications render UI independently

This architecture allows the same content to power multiple digital experiences.

2. AEM Headless Architecture Overview

AEM’s headless implementation is built around three core layers:

1. Content Fragment Models
   Define the content schema.
2. Content Fragments
   Store the actual content in structured form.
3. GraphQL Endpoint
   Exposes content through a read-only API.

High-level flow:

Content Fragment Models
→ Content Fragments (stored in DAM)
→ GraphQL Endpoint
→ Frontend Applications

The schema is automatically derived from the models, and the API is generated by AEM.

3. Environment Prerequisites

AEM as a Cloud Service or Local SDK

GraphQL support is built-in and requires no additional installation.

AEM 6.x On-Premise

You must install Adobe’s official GraphQL feature package before using GraphQL endpoints.

Without this package, the GraphQL console and endpoints will not be available.

4. Preparing AEM for Headless Implementation

4.1 Create a Configuration Container

Navigate to:

Tools → General → Configuration Browser

Create a configuration container (example: wknd) and enable:

• Content Fragment Models
• GraphQL

This creates a workspace at:

/conf/wknd

All models and GraphQL endpoints should be created within this configuration container.

4.2 Create Content Fragment Models (Define the Schema)

Content Fragment Models define the structure and validation rules of your content.

Example: Author Model (under /conf/wknd)

Fields:

• firstName — Single Line Text
• lastName — Single Line Text
• types — Enumeration or Tags
• photo — Content Reference

Example: Article Model (under /conf/wknd)

Fields:

• title — Single Line Text
• slug — Single Line Text
• author — Fragment Reference (Author model)
• body — Rich Text
• publishDate — Date/Time

These models form the GraphQL schema automatically.

Field Design Best Practices

Each important field should include:

• A meaningful placeholder
• A clear description
• Proper validation

Example: Slug Field

Field Label: Slug
Property: slug
Type: Single Line Text

Validation pattern:

^[a-z0–9]+(?:-[a-z0–9]+)*$

Error message:
Use lowercase letters, numbers, and hyphens only.

This ensures clean, consistent URLs and predictable API responses.

5. Create Content Fragments

Content Fragments are instances of the models.

Navigate to:

Assets → Files → Create Folder
Example folder:

/content/dam/cfm

Create fragments using the previously defined models.

Example: Author Fragment

firstName: Martin
lastName: Kleppmann
types: DATA
photo: /content/dam/wknd/digital/team-3.jpg

Example: Article Fragment

title: Clean Code
slug: clean-code
author: Robert Martin
publishDate: 2008–08–11

These fragments are now queryable via GraphQL.

6. Create a GraphQL Endpoint

Navigate to:

Tools → General → GraphQL → Create

Example:

Name: wk-ep
Path:
/content/cq:graphql/wknd/endpoint

The endpoint exposes all models under the selected configuration container.

7. Using the AEM GraphQL Query Editor

Open:

Tools → General → GraphQL → Query Editor

Select your endpoint (e.g., wk-ep).

The interface includes:

• Endpoint selector
• Query editor
• Documentation explorer
• Query variables panel
• Results panel

The documentation explorer automatically reflects the schema generated from your models.

8. Executing Your First Query

Example query:

query {
  articleList {
    items {
      title
    }
  }
}

After execution, the response will be:

{
  "data": {
    "articleList": {
      "items": [
        {
          "title": "Clean Code"
        }
      ]
    }
  }
}

This demonstrates how structured content is returned as JSON.

9. Persisted Queries (Production Best Practice)

In production environments, avoid exposing raw GraphQL queries directly.

Instead:

1. Save the query using “Save As” in Query Editor.
2. This creates a persisted query.
3. The frontend calls it using HTTP GET.
4. The response becomes cacheable via Dispatcher or CDN.

Example endpoint format:

/graphql/execute.json/wknd/article-list

Benefits:

• Improved performance
• Cache-friendly architecture
• Enhanced security
• Cleaner frontend integration

10. Publishing Considerations

To make content available externally:

• Publish Content Fragment Models
• Publish Content Fragments
• Publish the GraphQL endpoint

Ensure replication is properly configured in your environment.

11. End-to-End Flow Summary

1. Define schema using Content Fragment Models.
2. Create structured content using Content Fragments.
3. AEM auto-generates GraphQL schema.
4. Frontend applications query the endpoint.
5. JSON data is rendered by the frontend.

Conclusion

AEM Headless CMS provides a structured, scalable approach to delivering content across multiple channels.

By combining:

• Content Fragment Models for schema definition
• Content Fragments for structured data
• GraphQL for API delivery
• Persisted Queries for production readiness

AEM enables enterprise-grade headless architecture suitable for modern digital ecosystems.

Understanding these core building blocks allows teams to build flexible, future-ready applications while maintaining strong content governance.

If you are working on AEM 6.4+, 6.5, or AEM as a Cloud Service, understanding CAConfig is essential for building scalable and maintainable multi-site architectures.

Let’s break it down clearly.

What Is Context-Aware Configuration (CAConfig)?

Context-Aware Configuration is an AEM feature that allows you to store configuration separately from content and dynamically resolve it based on where a page lives in the content tree.

Instead of:

• Hardcoding configuration inside components
• Storing configuration under /content
• Writing custom path-based logic

AEM encourages storing configuration under:

/conf

Content branches then reference their configuration using:

cq:conf = /conf/<site-or-chapter>

This makes configuration:

• Reusable
• Structured
• Environment-friendly
• Site-specific
• Cleanly separated from content

Why Does AEM Need CAConfig?

Imagine a multi-site structure like:

/content/shaw/co
/content/shaw/tx
/content/shaw/ny

Each chapter might require:

• Different email configurations
• Different API endpoints
• Different header/footer behavior
• Different feature flags
• Different third-party integrations

Without CAConfig, you might:

• Duplicate configurations across pages
• Write custom logic to check paths
• Embed configuration into components

Instead, you create:

/conf/shaw/co
/conf/shaw/tx
/conf/shaw/ny

Each content branch points to its respective configuration.

That’s what “context-aware” means:

The configuration changes dynamically depending on the page context.

Is CAConfig the Recommended Approach?

Yes — absolutely.

CAConfig is the recommended approach in:

• AEM 6.4+
• AEM 6.5
• AEM as a Cloud Service

Modern AEM project archetypes are built around /conf.

If you’re building an enterprise multi-site solution, CAConfig is not optional — it’s best practice.

When Is CAConfig Necessary?

You should use CAConfig when:

• You have multiple sites or chapters
• You need site-level or regional configuration
• You want a clear separation between content and configuration
• Authors need to manage configuration via AEM

You may not need it if:

• The website is small and static
• Configuration is fixed and identical everywhere
• Everything is managed purely via code

But in enterprise environments — it is essential.

The Replication Challenge in CAConfig

Here’s where things get interesting.

AEM stores:

• Content under /content
• Configuration under /conf

However, replication was originally designed to publish content — not configuration dependencies.

So when you publish:

/content/shaw/co

AEM does NOT automatically publish:

/conf/shaw/co

Even though the page depends on it.

That’s why teams often face issues where:

• Pages work in author
• But break in publish
• Because configuration wasn’t activated

Why Doesn’t AEM Auto-Replicate Configuration?

There are valid reasons:

• /conf can be shared across multiple sites
• Some customers prefer managing configuration via CI/CD
• Adobe avoids automatically replicating dependencies

So dependency-based replication is not enabled by default.

How wcm.io Solves the Gap

The wcm.io AEM Mocks & Utilities library provides an extension that enhances replication.

With wcm.io:

1. Page is activated
2. cq:conf reference is detected
3. Related /conf path is identified
4. Both content and config are replicated

It essentially makes activation dependency-aware.

This is not a hack.

wcm.io is:

• Widely adopted
• Enterprise trusted
• Open-source
• Common in real-world AEM projects

Many large implementations use it.

When Would You NOT Use wcm.io?

You might skip it if:

• Configuration is managed only via deployment pipelines
• Authors are not allowed to change /conf
• You treat configuration strictly as code

Some enterprises prefer:

“All config changes go through CI/CD.”

In that case, replication dependencies are irrelevant.

But if authors publish configuration changes via Quick Publish, wcm.io makes perfect sense.

CAConfig vs OSGi Configuration

A common confusion is:

“What’s the difference between CAConfig and OSGi config?”

Here’s a simple breakdown:

Use:

• CAConfig for site-level functional settings
• OSGi for backend/system behavior

They serve different purposes.

How CAConfig Resolves Internally

When a component requests configuration:

1. AEM looks at the current page
2. Checks its cq:conf property
3. Resolves the corresponding /conf path
4. Searches upward if needed
5. Returns the matching configuration

This makes configuration inheritance possible.

Real-World Enterprise Scenario

In a multi-region implementation like:

/content/sh_page/{chapter}

With:

/conf/sh_page/{chapter}

Each region can:

• Have independent integrations
• Use separate API endpoints
• Toggle features independently
• Deploy safely without affecting others

That’s exactly what CAConfig was designed for.

Final Thoughts

Context-Aware Configuration is not just a feature — it’s a foundational architectural pattern in modern AEM.

If you’re building enterprise multi-site solutions:

• CAConfig is correct
• Using /conf is best practice
• Managing replication properly is necessary
• Tools like wcm.io can help close real-world gaps

A clean separation between content and configuration is what allows AEM to scale properly in complex implementations.

Visual Summary

### **Function Syntax**

In JavaScript, there are two main ways to declare a function. One of which is to use the `function` keyword.

### **Basic Syntax**

The syntax is:

`function f(a, b) {

. const sum = a + b;

. return sum;

}

console.log(f(3, 4)); // 7`

In this example, `f` is the name of the function. `(a, b)` are the arguments. You can write any logic in the body and finally `return` a result. You are allowed to return nothing, and it will instead implicitly return `undefined`.

### **Anonymous Function**

You can optionally exclude the name of the function after the `function` keyword.

`var f = function(a, b) {

. const sum = a + b;

. return sum;

}

console.log(f(3, 4)); // 7`

### **Immediately Invoked Function Expression (IIFE)**

You can create a function and immediately execute it in Javascript.

`const result = (function(a, b) {

. const sum = a + b;

. return sum;

})(3, 4);

console.log(result); // 7`

Why would you write code like this? It gives you the opportunity to ***encapsulate*** a variable within a new ***scope***. For example, another developer can immediately see that `sum` can’t be used anywhere outside the function body.

### **Functions Within Functions**

A powerful feature of JavaScript is you can actually create functions within other functions and even return them!

`function createFunction() {

. function f(a, b) {

. const sum = a + b;

. return sum;

. }

. return f;

}

const f = createFunction();

console.log(f(3, 4)); // 7`

In this example, `createFunction()` returns a new function. Then that function can be used as normal.

### **Function Hoisting**

JavaScript has a feature called ***hoisting*** where a function can sometimes be used before it is initialized. You can only do this if you declare functions with the `function` syntax.

`function createFunction() {

. return f;

. function f(a, b) {

. const sum = a + b;

. return sum;

. }

}

const f = createFunction();

console.log(f(3, 4)); // 7`

In this example, the function is returned before it is initialized. Although it is valid syntax, it is sometimes considered bad practice as it can reduce readability.

### **Closures**

An important topic in JavaScript is the concept of ***closures***. When a function is created, it has access to a reference to all the variables declared around it, also known as it’s ***lexical environment***. The combination of the function and its enviroment is called a ***closure***. This is a powerful and often used feature of the language.

`function createAdder(a) {

. function f(b) {

. const sum = a + b;

. return sum;

. }

. return f;

}

const f = createAdder(3);

console.log(f(4)); // 7`

In this example, `createAdder` passes the first parameter `a` and the inner function has access to it. This way, `createAdder` serves as a factory of new functions, with each returned function having different behavior.

### **Arrow Syntax**

The other common way to declare functions is with arrow syntax. In fact, on many projects, it is the preferred syntax.

### **Basic Syntax**

`const f = (a, b) => {

. const sum = a + b;

. return sum;

};

console.log(f(3, 4)); // 7`

In this example, `f` is the name of the function. `(a, b)` are the arguments. You can write any logic in the body and finally `return` a result. You are allowed to return nothing, and it will instead implicitly return `undefined`.

### **Omit Return**

If you can write the code in a single line, you can omit the `return` keyword. This can result in very short code.

`const f = (a, b) => a + b;

console.log(f(3, 4)); // 7`

### **Differences**

There are 3 major differences between arrow syntax and function syntax.

1. More minimalistic syntax. This is especially true for anonymous functions and single-line functions. For this reason, this way is generally preferred when passing short anonymous functions to other functions.
2. 2. No automatic hoisting. You are only allowed to use the function after it was declared. This is generally considered a good thing for readability.
3. 3. Can’t be bound to `this`, `super`, and `arguments` or be used as a constructor. These are all complex topics in themselves but the basic takeaway should be that arrow functions are simpler in their feature set. You can read more about these differences [here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions).

The choice of arrow syntax versus function syntax is primarily down to preference and your project’s stylistic standards.

### **Rest Arguments**

You can use ***rest*** syntax to access all the passed arguments as an array. This isn’t necessary for this problem, but it will be a critical concept for many problems. You can read more about `…` syntax [here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax).

### **Basic Syntax**

The syntax is:

`function f(…args) {

. const sum = args[0] + args[1];

. return sum;

}

console.log(f(3, 4)); // 7`

In this example the variable `args` is `[3, 4]`.

### **Why**

It may not be immediately obvious why you would use this syntax because you can always just pass an array and get the same result.

The primary use-case is for creating generic factory functions that accept any function as input and return a new version of the function with some specific modification.

By the way, a function that accepts a function and/or returns a function is called a ***higher-order function***, and they are very common in JavaScript.

For example, you can create a logged function factory:

`function log(inputFunction) {

. return function(…args) {

. console.log(“Input”, args);

. const result = inputFunction(…args);

. console.log(“Output”, result);

. return result;

. }

}

const f = log((a, b) => a + b);

f(1, 2); // Logs: Input [1, 2] Output 3`

– -

### **Solutions to Problem**

Now let’s apply these different ways of writing JavaScript functions to solve this problem.

### **Function Syntax**

### **Arrow Syntax**

### **Arrow Syntax + Rest Arguments**

JS Day 1 marks the beginning of our journey into the world of JavaScript, one of the most widely used programming languages in the world. On this day, we will start from the basics and cover fundamental concepts such as variables, data types, and basic syntax. We will also delve into more complex topics like functions and control flow. This day is crucial for building a strong foundation in JavaScript, so make sure to pay close attention and practice as much as possible.