Training days. Rest days. Travel days. Bad sleep. Good sleep.

Day after day, data kept accumulating — heart rate, HRV, sleep, strain, recovery.
And for the most part, I ignored it.

Not because I don’t believe in data.
But because most personal metrics, without a decision system, are simply noise.

Then one metric appeared — and it hit harder than expected.

The Wake-Up Call I Didn’t See Coming

On May 14th, I turned 39.5, my actual birthday is November 14th 1985.

That same day, WHOOP introduced a new feature: WHOOP Age.

Out of curiosity, I checked it.

The result stopped me cold.

My biological age was calculated as 5.5 years older than my real age.

I didn’t feel old.
I trained regularly; or I thought so.
I performed at a high cognitive level every day.

But this number felt different.

Not because it was flattering or not —
but because it was a system-level signal, not a vanity metric.

And it forced a question I couldn’t ignore:

If this were an AI system in production, would I accept this output without investigation?

Why This Metric Was Different

By then, I had already seen hundreds of metrics:

• HRV
• Resting heart rate
• Sleep stages
• Recovery percentages
• Strain scores

Most of them fluctuated daily.
Most were emotionally easy to dismiss.

WHOOP Age was different.

It wasn’t a daily score.
It was a long-horizon aggregation — a proxy for cumulative system stress.

In AI terms:

• Lower volatility
• Higher signal
• Much harder to explain away

That’s exactly why it worked.

The Common Mistake With Personal Data

Most people respond to uncomfortable metrics in one of two ways:

1. Panic and overcorrect
2. Ignore the metric entirely

Both reactions are system failures.

In AI systems, when performance degrades, we don’t react emotionally.
We ask structured questions:

• Which inputs influence this output?
• Which variables are controllable?
• Where is the feedback loop broken?

So I treated myself like a production system.

Turning Wearable Data Into a Decision System

I didn’t try to “fix” the age metric directly.

That would be equivalent to training on the label, which is a classic modeling mistake.

Instead, I focused on upstream variables.

Step 1: Eliminate Noise

I stopped reacting to daily fluctuations.

I ignored:

• Single bad sleep nights
• One-off low recovery days
• Isolated strain spikes

I focused only on trends, not events.

This alone removed most of the emotional friction.

Step 2: Define Non-Negotiable Rules

I introduced explicit decision rules:

• Low recovery does not mean no training
  It means reduced intensity, not inactivity
• Consecutive high-strain days trigger enforced recovery
• Degrading sleep trends cap intensity automatically
• Increased workload requires proportional recovery investment

No motivation required.
No daily debate.

This mirrors how resilient AI systems are governed.

Step 3: Review Weekly, Not Daily

Daily optimization leads to overfitting.

So I reviewed progress weekly, not daily:

• Recovery stability
• Training consistency
• Cognitive energy
• Subjective stress levels

The question was never:
“Was today good?”

It was:
“Is the system improving?”

The Outcome (7.5 Months Later)

After 7.5 months of consistent, rule-driven behavior:

• I matched my real age
• Then surpassed it

As of today, my biological age is 1.2 years younger than my chronological age.

No hacks.
No extreme interventions.
No obsession.

Just:

• Signal selection
• Clear decision rules
• Closed feedback loops

The Deeper Lesson

This experience reinforced something I’ve seen repeatedly in enterprise AI initiatives:

Data doesn’t create change.
Systems do.

Most people don’t fail because they lack information.
They fail because they lack decision architecture.

The same pattern applies to:

• AI platforms
• Organizations
• Human performance

Why I’m Writing This Blog

In my professional work — as a senior AI and data leader — I design systems that operate under real constraints and real consequences.

This blog will explore:

• Applied AI and agentic systems
• Data-driven decision design
• Leadership lessons from production environments
• Translating engineering discipline into real life

Sometimes the system is software.
Sometimes it’s human.

The principles remain the same.

Final Thought

That number — “5.5 years older” — didn’t motivate me.

It forced me to redesign the system.

And that made all the difference.

Are you a Sitecore developer or an AI enthusiast itching to bring a whole new level of intelligence to search experiences? Do you ever wonder how conversational interfaces and smarter search could be harmoniously integrated into your Sitecore platform?

If so, you’ve landed in the right place! Welcome to the kickoff of an exciting blog series designed to take you through the journey of implementing Retrieval Augmented Generation (RAG) into Sitecore Search.

We’re not just scratching the surface here; we’re diving deep. By the end of this series, you won’t just understand what RAG is and why it’s a game-changer for Sitecore Search. You’ll also have actionable insights, code snippets, and the know-how to implement these advanced features into your own projects.

Why This Series Matters

In a time where AI became the new normal, and an era where machine learning and natural language processing are altering the fabric of digital interactions, simply having a functional search feature is no longer enough. Users are beginning to expect smarter, more contextual, and conversational experiences that understand not just what they’re saying, but what they’re trying to achieve. This is where the combination of Retrieval Augmented Generation (RAG) and Sitecore Search comes in—offering a capability that can make search experiences more intelligent and user-centric.

As we look towards the future, the role of search in content management systems like Sitecore will only become more critical and complex. This series is not just about meeting the status quo; it’s about preparing for the future. RAG is a cutting-edge technology that is gaining traction for its capabilities in information retrieval and conversational agents. By integrating this with Sitecore Search, we’re setting the stage for a paradigm shift in how search functionalities can be designed and delivered.

Whether you’re a Sitecore developer looking to implement the latest advancements in search capabilities, a UX/UI designer aiming to create more intuitive and meaningful user journeys, or a product manager focused on adding value to your platform—this series has something for you. We’ll provide both the theoretical background and the practical guidelines needed to make these advanced concepts a reality in your projects.

We won’t just talk theory; we’ll walk you through real-world applications and case studies where the integration of RAG with Sitecore Search has made a tangible difference. These insights will not only validate the concepts but also provide you with actionable strategies to implement them.

What Will You Learn?

Understanding the basics of Retrieval Augmented Generation (RAG) is key to unlocking its full potential. We’ll dissect this advanced natural language processing technology, explaining its components, its architecture, and how it functions. This foundational knowledge will set the stage for deeper explorations and implementations.

Sitecore Search is a powerful tool that can do much more than you might think. We’ll give you an in-depth look at its capabilities, going beyond the basics to show you how you can customize and extend it to meet specific needs or solve complex challenges.

Combining RAG with Sitecore Search may sound daunting, but we’ll make it straightforward. Through step-by-step guides, code snippets, and troubleshooting tips, you’ll learn how to integrate these technologies seamlessly. You’ll also gain insights into optimizing the performance and usability of your new, intelligent search feature.

Ever wondered how to create a conversational interface that can interact with your Sitecore data? We’ll walk you through the process, showing you how RAG can turn your Sitecore Search into a conversational agent that understands and responds to user queries in a more natural and intuitive manner.

To bring all these concepts to life, we’ll showcase real-world examples and case studies that demonstrate the power and potential of integrating RAG with Sitecore Search. These tangible insights will not only add credibility to the concepts but also offer you a blueprint for your own implementations.

Series Overview

• Blog Post 1: Retrieval Augmented Generation (RAG) and the Future of Sitecore Search
• Blog Post 2: How to “Chat with Your Own Data” using Retrieval Augmented Generation
• Blog Post 3: Implementing “Chat with Your Own Data” in Sitecore Search
• Blog Post 4: Full Demo: Retrieval Augmented Generation Transforms Sitecore Search

Summary

We are on the point of a technological revolution that promises to redefine the way we think about search experiences in Sitecore. By merging cutting-edge technologies like Retrieval Augmented Generation with robust platforms like Sitecore Search, we’re stepping into a new era of user interaction and engagement. This series aims to be your comprehensive guide through this transformative journey, equipping you with both the theoretical knowledge and practical skills needed to be at the forefront of this evolution.

Next Steps

The stage is set, and the players are ready. All that’s missing is you! Are you prepared to embark on this enlightening journey to revolutionize Sitecore Search and, by extension, the way users interact with your platform?

• Subscribe Now: Don’t miss out on any installments of this series. Subscribe to our blog to get notifications straight to your inbox.
• Share: If you find this series to be of value, please don’t hesitate to share it within your professional network. The more people we can educate on these advancements, the more robust and user-friendly our future platforms will become.
• Engage: We value your insights and questions. Feel free to leave comments on the blog posts or engage with us on social media. Your interaction enriches the community dialogue and may even influence the focus of future posts in the series.

The third post of the series is a bit new, as there aren’t any samples (that I could find). I will show how to add a native mobile app client (iOS for this post but Android works the exact same).
This will enable you first to authenticate against the Sitecore Identity, then secondly (later posts coming) consume protected APIs (whether Sitecore native or custom ones).

Recap

So let’s recap how the identity system works and the moving parts of it.

1- There is an Identity Provider, which holds users, passwords, information about them, should be a trusted party that knows how to authenticate.
2- There are a few protected resources (data called identity resources, and methods called Api resources).
3- There are Clients that want to consume these protected resources.

How it works again?

0- Step zero (pre requisites) a Client configuration needs to be added at the Identity Provider so when it comes back for permission the IdP would know how to handle it, where to redirect, what are the protected resources it can ask for, what is the mechanism used to secure, verify and send tokens back to the client and some other details we’ll see in the configs in a bit.
1- Client app connects to the Identity Provider and asks for permission (access) to get some or all of those protected resources (scopes).
2- Control is at Identity Provider now (through a web redirect or a web popup) and asks the user to login and let’s him know what protected resources the client wants to access (can optionally ask for consent).
3- Client app get control back with a token that can usually have both (data) and permission to access methods (id_token and access_token).

Sitecore side Add the configuration

Same as we discussed before, we add client configuration at the identityServer.xml, which resides at the <instance>.identityserver\sitecore\Sitecore.Plugin.IdentityServer\Config folder.

Notable properties for native apps:

AllowOfflineAccess: This configuration when set to true allows the client app to keep and request a refresh token, which is used later to request a new token when the one it has expires, it can do this silently (without redirecting the user to relogin to the IdP.

RedirectUri: This piece of information is very important, in native apps the redirectUri needs to a schema based uri, that should be registered inside your iOS/Android app so the redirection happens correctly, details here.

AllowedGrantType: This property is a collection that accepts one or many grant types, one important thing to note here, that mobile native apps Must run on authorization_code grant type. It provides a way to retrieve tokens on a back-channel as opposed to the browser front-channel. It also support client authentication.

RequireClientSecret: In OAuth1.0 there was a required secret with clients, but in OAuth2.0 it became optional, and actually not recommended to add use client secrets for public apps (mobile and javascript / ones that don’t run on a server)

Building the client app

As I mentioned before the scope of this post will be adding an iOS client only, but Android is pretty much the same.

In the world of web, I mentioned the great IdentityModel open source project written in .NET (and supports all platforms, if you build Xamarin apps go ahead with that).

In the mobile native world there is a similar, popular well written and widely used open source project AppAuth it has iOS, Android and Mac implementations.

For the sake of this post, I will use the sample app that comes with the library. Assuming you are an iOS developer I am sure you already have cocoapods installed (a package manager something similar to npm in the world of Apple dev iOS/MacOSX) .

All you need to do (which I have done) go to your projects directory and run pod try AppAuth in your preferred command line tool , I use iTerm if you haven’t tried it yet, give it a spin.

Once you have your project ready, go to the AppAuthExampleViewController.swift file and add your parameters, I have added the full file as a github gist here.
https://gist.github.com/AmrElsehemy/59b2b30c98125fe2352995cdce07d7ca

Notable changes to make it work!

1- Set the issuer url, this is the url of the Sitecore Identity server (!NOTE: this is not the instance url, it’s the identity server) at line 27

2- Set the client id, this has to match the one you just configured in SI in our case AwesomeAppId at line 35

3- Set the redirectUrl to the same one you added in the config, usually this also needs to be registered as the schema url for your app in the info.plist (not required to make this sample work) this to be found at line 42.

4- Sitecore Identity has it’s own scope when it comes to profile data, so you need to change the scope request from profile to sitecore.profile to make it work changes at line 386.

How it looks

It start from Auto login (which tries to discover the connect/authorize/token urls on it’s own).
Then opens an embedded web view so the user can enter his sitecore credentials
Finally upon correct login, the web view closes and returns with the correct access token so the app can use it to understand information about the logged in user or alternatively use it as a Bearer token to get more information from APIs protected by Sitecore Identity server.

References

• https://www.oauth.com/oauth2-servers/client-registration/client-id-secret/
• https://tools.ietf.org/html/rfc7636
• https://aaronparecki.com/oauth-2-simplified/
• https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07
• https://github.com/openid/AppAuth-iOS/blob/master/Examples/README-IdentityServer.md
• https://guides.cocoapods.org/using/getting-started.html

In this part I will show some coding and how to build an external web application that uses the Sitecore Identity server to authenticate users, and to connect to the Sitecore instance APIs.

Remember in the first part of this series, I showed that the default implementation comes with a default client named Sitecore, which is the Sitecore instance itself protected by the identity server.

In this code sample I will show 2 things:

1. Configuring/Adding a Client App in the Sitecore Identity (SI)
2. Building an App that uses SI as a token issuing authority that protects the Sitecore instance apis and data.

So let’s get started,

Configuring a Client

Sitecore Identity (SI) has the clients configured in the file <instance>.identityserver\sitecore\Sitecore.Plugin.IdentityServer\Config\identityServer.xml here we will add a new client with some default properties.

<WebAppClient>
   <ClientId>WebAppClient</ClientId>
   <ClientName>Web App Client</ClientName>
   <AccessTokenType>0</AccessTokenType>
   <AllowOfflineAccess>true</AllowOfflineAccess>
   <AlwaysIncludeUserClaimsInIdToken>false</AlwaysIncludeUserClaimsInIdToken>
   <AccessTokenLifetimeInSeconds>3600</AccessTokenLifetimeInSeconds>
   <IdentityTokenLifetimeInSeconds>3600</IdentityTokenLifetimeInSeconds>
   <AllowAccessTokensViaBrowser>true</AllowAccessTokensViaBrowser>
   <RequireConsent>false</RequireConsent>
   <RequireClientSecret>false</RequireClientSecret>
   <AllowedGrantTypes>
      <AllowedGrantType1>hybrid</AllowedGrantType1>
      <AllowedGrantType2>client_credentials</AllowedGrantType2>
   </AllowedGrantTypes>
   <RedirectUris>
      <RedirectUri1>{AllowedCorsOrigin}/signin-oidc</RedirectUri1>
   </RedirectUris>
   <PostLogoutRedirectUris>
      <PostLogoutRedirectUri1>{AllowedCorsOrigin}/signout-callback-oidc</PostLogoutRedirectUri1>
   </PostLogoutRedirectUris>
   <AllowedCorsOrigins>
      <AllowedCorsOrigin1>https://localhost:44343</AllowedCorsOrigin1>
   </AllowedCorsOrigins>
   <AllowedScopes>
      <AllowedScope1>openid</AllowedScope1>
      <AllowedScope2>sitecore.profile</AllowedScope2>
      <AllowedScope3>sitecore.profile.api</AllowedScope3>
   </AllowedScopes>
   <UpdateAccessTokenClaimsOnRefresh>true</UpdateAccessTokenClaimsOnRefresh>
</WebAppClient>   

Adding the Client Code

Now that we configured our client so the identity server knows about it, we will build the application itself. In this sample I started from a plain ASP.NET Core 2.2 MVC application.
The folks behind the IdentityServer4 also built client tools https://github.com/IdentityModel which make it easy to authenticate against OpenIDC and OAuth2 servers.

For a change I will use the new Razor Page Model, instead of the traditional View Controllers. But first things first, after adding the nuget for IdentityModel we need to register and configure the services we will need in the Startup.cs as shown.

using IdentityModel;
using Microsoft.AspNetCore.Authentication.Cookies;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.IdentityModel.Tokens;
using System;
using System.IdentityModel.Tokens.Jwt;

namespace WebAppClient
{
    public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }

        public IConfiguration Configuration { get; }

        // This method gets called by the runtime. Use this method to add services to the container.
        public void ConfigureServices(IServiceCollection services)
        {
            JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

            services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

            services.Configure<CookiePolicyOptions>(options =>
            {
                options.CheckConsentNeeded = context => true;
                options.MinimumSameSitePolicy = SameSiteMode.None;
            });

            services.AddAuthentication(options =>
            {
                options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = "oidc";
            })
            .AddCookie(options =>
            {
                options.ExpireTimeSpan = TimeSpan.FromMinutes(60);
                options.Cookie.Name = "mvcimplicit";
            })
            .AddOpenIdConnect("oidc", options =>
            {
                options.ClientId = "WebAppClient";
                options.Authority = "https://sc910.identityserver";
                options.RequireHttpsMetadata = false;
                options.GetClaimsFromUserInfoEndpoint = true;
                options.ResponseType = "code token";

                options.Scope.Clear();
                options.Scope.Add("openid");
                options.Scope.Add("sitecore.profile");
                options.Scope.Add("offline_access");
                options.Scope.Add("sitecore.profile.api");

                options.SaveTokens = true;

                options.TokenValidationParameters = new TokenValidationParameters
                {
                    NameClaimType = JwtClaimTypes.Name,
                    RoleClaimType = JwtClaimTypes.Role,
                };
            });
        }

        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseExceptionHandler("/Error");
                app.UseHsts();
            }

            app.UseHttpsRedirection();
            app.UseStaticFiles();
            app.UseCookiePolicy();

            app.UseAuthentication();
            app.UseMvcWithDefaultRoute();
        }
    }
}

There is not much difference between View Controllers and Razor Page Models in this sample, with one exception, that you get the current context using HttpContext instead of the Context property.
I added a Secure Page which renders the values it receives from the Sitecore Identity.

@page
@using Microsoft.AspNetCore.Authentication
@model WebAppClient.Pages.SecureModel
@{
    ViewData["Title"] = "Secure";
}

<h1>Secure Page</h1>

<h2>Claims</h2>

<dl>
    @foreach (var claim in User.Claims)
    {
        <dt>@claim.Type</dt>
        <dd>@claim.Value</dd>
    }
</dl>

<h2>Properties</h2>

<dl>
    @foreach (var prop in (await HttpContext.AuthenticateAsync()).Properties.Items)
    {
        <dt>@prop.Key</dt>
        <dd>@prop.Value</dd>
    }
</dl>

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc.RazorPages;

namespace WebAppClient.Pages
{
    [Authorize]
    public class SecureModel : PageModel
    {
        public void OnGet()
        {

        }
    }
}

References

• https://himadritechblog.wordpress.com/2019/02/26/sitecore-identity-part-2-identity-client-and-resource-authorization/
• https://doc.sitecore.com/developers/91/sitecore-experience-management/en/sitecore-identity.html
• https://identityserver4.readthedocs.io/

One of the major updates that came in Sitecore 9.1 is Sitecore Identity, this blog post will introduce a basic understanding for how it works.

Sitecore Identity usually abbreviated (SI) is a new feature introduced in Sitecore 9.1. SI doesn’t replace the old identity mechanism, but actually builds on top of the current authentication mechanism in 9.0 and uses the Federated Authentication feature to act as an external authentication source. SI is a wrapper built on top of the open source widely accepted IdentityServer4 which itself is an OpenID Connect and OAuth 2.0 framework for ASP.NET Core, it is also deployed as a separate service (as a part of breaking the monolith into micro-services architecture).

IdentityServer4 on it’s own enables many goodies, including Authentication as a Service, Single Sign-on/Sign-out, Access Control for APIs also it can act as a Federation Gateway as well.

How it works

Starting Sitecore 9.1 the default deployment includes and uses the new Sitecore Identity, under the hood SI server uses  identityserver-contrib-membership which enables IdentityServer4 use the old ASP.NET 2.0 Membership Database, of course as anything else in Sitecore this is highly customizable and can be overridden and changed to another implementation using dependency injection.

In the world of OAuth and Open ID Connect there are usually 3 moving parts which are the (Client – Identity Server – Resources)

The flow starts from the user, using a client (can be a web app, mobile, bot or even an iot device) and wants to login or request access to a protected resource.
Then the flow is sent to the identity server (which the client is registered in) requesting access to specific resources (can be identity or access to other resources or api, which again is registered in the identity server).
The identity server checks the credentials against the required/configured grant types (more on this later). And then returns to the client caller with the token required for access (which can be stored in a cookie in case or web or used for authorization in case of native) . This is a very simple workflow very brief and skipping a lot of details that might not be relevant to the scope of introduction.

In Sitecore 9.1

So how this is organized in Sitecore, the default implementation comes with an identity server installed which is the token issuer and authority, by default it’s installed at a default url is https://{instanceName}.identityserver. The configuration for the SI server in the Sitecore instance in the \App_Config\Sitecore\Owin.Authentication.IdentityServer\Sitecore.Owin.Authentication.IdentityServer.config configuration file. And that’s where the configuration is added in the instance to make it know about the SI server, specifically in the sitecore/federatedAuthentication/identityProviders node.

On the other hand in the SI server sitecore is configured as a Client, and that is configured in the identity server site root in the path \sitecore\Sitecore.Plugin.IdentityServer\Config\identityServer.xml, in the below image is a snippet of what is actually defined.

Some key values to notice in the configuration, the ClientId (Sitecore) which should be unique for each client app, and the AllowedScopes which tells the identity server which resources can this client ask for.
AllowedGrantTypes this tells identity server how can this client interact with it to acquire tokens, there is a handful of standard grant types out there, and you can combine a few together but some constraints apply for security. For more information check the supported grant types in the identity server.
In this case the Sitecore client is configured to use two grant types, hybrid for user centric operations and client credentials for server to server communication.

In this post I showed the basic out of the box features of Sitecore Identity in 9.1, in the next posts of this series I will show more customizations, how to add a custom client besides the Default Client, how to add your own APIs and protect them using the (SI), also I will show how to add different clients native mobile and chatbots, finally how use the SI as a gateway and enable external custom identity providers like Azure AD or Google.

In the previous posts, I gave a very brief introduction and getting started with Sitecore JSS, and then I tried to recreate a very minimal JSS app without using any out of the box client tools.

In this post I will show how to use the Sitecore JSS tools to reuse your own template.

Basic Template Generation

Sitecore JSS comes with tons of features and capabilities, the one I am exploring today is the jss create command, the official documentation already has a great starting point to let you know what’s there and how to extend it. Also, just typing in the command line jss create –help will give a great starting point.

So as you can see from the available options, there is already a couple few ways to make an app from a custom template.

1. By specifying your own repository using the –repository parameter, this repository should be public and accessible from your command line (there is no way to point to a non github repo or a private repo, but there is a workaround).
   • Also, works with –branch to change the active branch
2. By specifying a folder on the local hard disk using the –source parameter with value having the folder containing the template (which as written in the tool Good for private templates.)

One customization option here is to give the template generator a starting hostname using the –hostName parameter.

Advanced Template Generation

What actually happens when calling the jss create app template a set of tasks are executed.

First, the cli tool tries to copy the template from the source (built-in, custom repo or source folder. Next it tries to run npm install, to get the folder ready for you. After installing the required packages, the tool starts setting the package name to <the app name you chose> some default renaming happens here.

Then it’s up to you and use the magic of jss-create.js, which is a file that you add in the source (repo or folder) that gets executed and self deleted from destination folder. You can use it for any customization, renaming or moving bits that you need to add. If you add some default files with <tokens> to be replaced upon creating new projects this is the right place to add your replacing logic.

Sample demo

In the last post, I built a bare bones jss application, I will reuse it and make it as a template to show off the power of jss create.

So for the sake of the demo, I copied the old bare-bones-jss-app into a new folder and named it bare-bones-jss-template and then ran this command.

jss create app-one bare-bones-jss-template -s /Users/amr/Projects/Blog

As expected the cli did it’s job, a new folder name app-one was created with the contents of the template, npm install was called, and I ended up with the lovely ASCI Sitecore logo as shown here

One thing to notice, the top yellow line Template bare-bones-jss-template did not have a jss-create.js in its root to invoke. No template configuration will be performed. And that means the application will just be a copy with no special names replacement done.

Now I will borrow the default jss-create.js in the react default template and show what happens.

const { applyNameToProject } = require('@sitecore-jss/sitecore-jss-cli/dist/create');
/**
 * @param {object} argv Arguments passed to `jss create` script
 * @param {string[]} nextSteps Array of default 'next steps' to show at the console
 * @returns {string[]} The next steps to display to the console user (enables customization from this script)
 */
module.exports = function createJssProject(argv, nextSteps) {
  console.log(`Executing create script: ${__filename}...`);

  applyNameToProject(__dirname, argv.name, argv.hostName);

  return nextSteps;
};

After adding this file, we just need to add “@sitecore-jss/sitecore-jss-cli”: “^11.0.2” to devDependencies in package.json, since it’s required in the file. To understand what applyNameToProject does you can peek into the source code of that method here. You will figure out that it’s trying to find a config.appName entry from the package.json file to use it for renames. So let’s add that as well.

"config": {
    "appName": "bare-bones-jss-template"
  },

And there you go, run again the jss create command line. And all files and settings are renamed for you to start deploying.

jss create app-two bare-bones-jss-template -s /Users/amr/Projects/Blog

Now we are back on track, after poking around the default tooling to understand what is happening under the hood. Next is doing actual customization and adding your own stuff. renaming other files or creating new ones all from the beginning.

Even the list of steps that are displayed after the ASCI Sitecore logo can be customized. From within the jss-create.js file you can change/add to the nextSteps array.

  nextSteps.push('* Watch a movie');

I hope this post has been useful and beneficial to you, as it was a lot of fun and learning for me.

In this post, I will build the simplest ever jss application without using the default template, and deploying it to Sitecore with the bare minimum, this will help to understand all the moving parts under the hood.

I will start of from facebook’s create react app template (which is also used as a base for the default jss react template, it’s kind of a standard for bootstrapping react apps nowadays).

Let’s create the app, if you don’t already have create-react-app cli installed, follow the instructions here.

npx create-react-app bare-bones-jss-app

This creates most of the work for us, now we have a react based application wired with some default settings, to see what you hae dne go into the folder and npm start, you will end up with localhost:3000, and the beautiful react nuclear logo spinning in place.

Our steps to accomplish are task is as follows:

1. Add the application/site configuration
2. Add the applicaition items and artifacts
3. Move the build folder (packaged project) to Sitecore root.

1- Adding a site configuration for Sitecore JSS

For Sitecore to recognize any site within it’s implementation, it needs to registered and configured appropriately.

From the default template /sitecore/config/app.config you will notice this description in the file

<!--
JSS Sitecore Configuration Patch File
This configuration file registers the JSS site with Sitecore,
and configures the Layout Service to work with it. 
Config patches need to be deployed to the Sitecore server.

Normally `jss deploy config` can do this for local development. 
To manually deploy, or to deploy via CI, this file can be placed in 
the `App_Config/Include` folder, or a subfolder of it, 
within the Sitecore site.
-->

So that’s what we are going to do, we will build it first then manually deploy it in the App_Config/Include folder. For the JSS sites/apps the minimum requirement is to have a configuration node for both a site and an application as follows:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" 
                xmlns:set="http://www.sitecore.net/xmlconfig/set/" 
                xmlns:role="http://www.sitecore.net/xmlconfig/role/">
  <sitecore>
    <sites>
      <site patch:before="site[@name='website']"
            inherits="website"
            name="bare-bones-jss-app"
            hostName="bare-bones.dev.local"
            rootPath="/sitecore/content/bare bones"
            startItem="/home"
            database="master" />
    </sites>
    <javaScriptServices>
      <apps>
        <app name="bare-bones-jss-app"
             sitecorePath="/sitecore/content/bare bones"
             useLanguageSpecificLayout="true"
             inherits="defaults"
        />
      </apps>
    </javaScriptServices>
  </sitecore>
</configuration>

Second step is to add the minimum artifacts to operate a Sitecore JSS site, which are basically :

1. An App
2. A route
3. A Layout

All JSS item templates are added into your instance after installing the JSS server update package, the highlighted portion are the out of the box templates, they are all placed under Foundation folder, to adhere to the Helix recommendation.

Now create your items, as shown

After adding your 3 items, make sure to attach the Layout to the route.

Third and Final step is to build and copy the output bundle of the create react app to the sitecore instance folder, by default jss apps live under root/dist/ which is configurable as most of the things in Sitecore.

Before building and copying, we just need to add Server Side Rendering support, since it is used by default in integrated mode and to add components in experience editor requires the server to return rendered HTML for it to find the component in.

Since it’s not the scope of this post to discuss SSR, I will not detail what was done/skipped, I just added a minimalistic server.js along with it’s webpack config, the full source code of this post is available here to examine and explore different files.

Finally, after stitching all the parts, the result is charming, we have a minimal JSS app with LayoutService enabled, and runs in the Experience Editor.

In later posts, I will try to build up bits and pieces until I achieve the default template, so I can learn along the way.

.

Having said, I decided to start blogging about this awesome technology hopefully to give back to the community and to learn more through the process.

So let’s begin.

What is Sitecore JSS ?

Sitecore JSS is a way to develop JavaScript-based frontends with a Sitecore backend.

The official home of JSS is https://jss.sitecore.com, it’s a great resource for getting started I will try not to repeat what is already described greatly over there.

Sitecore JSS, is an extension that works on sitecore 9.0.1 and later, JSS has two parts

1. Server side, installed on Sitecore
2. Client side, can actually be anything (that can work with http)

JSS server side is a normal Sitecore Package with the regular sitecore artifacts (dlls, Views, configs, and of course sitecore items). This is a closed source part and has different versions for each supported Sitecore backend

JSS client side is a mix of node npms and templates for React, Vue and Angular for web experiences, there is also an experimental template for React native for mobile. Not like the server side part, all the client side templates and tools are open-sourced here. https://github.com/Sitecore/jss

I will follow up with more posts to get into each side in much more details.

So now let’s explore what comes out of the box when running the very first set of commands

npm install -g @sitecore-jss/sitecore-jss-cli
jss create my-first-jss-app react
cd my-first-jss-app
jss start

And you have a running jss site and a folder ready to for your customizations as shown in these figures

For this blog post I will give a very brief introduction for the folders/files included in the default react template.

data contains lots of yaml files which are used for two purposes, first to be used as a source of data when running in disconnected mode (no sitecore backend), second are used to build the items that get transferred to sitecore on deploy/importing jss apps (more on this in a later post)

node_modules  any javascript developers knows what’s this

public holds all the public assets e.g. (fav.ico and index.html files)

scripts since everything sitecore is super extensible, this folder has some helper scripts each having a separate role, (will describe each in a later post)

server when deployed to sitecore, the application takes advantage of Server Side Rendering SSR, this folder has the entry point and configuration for server side rendering

sitecore contains some secondary files that are not needed when working disconnected but are very important and define how things should work in sitecore when being deployed.

src this should be the main entry point for all the client side application code that gets to be compiled for the end result.

That’s all of this short fast post.

As you already expect from the title, this article will be on ASP.NET Core I will make it short and simple.

The dummy app I will be building will be on Movies. Here is how it looks when you create a new project and pick ASP.NET Core Empty.

After choosing a name and creating the project, Visual Studio just gives you a plain web project with some nugets being restored, on the first run just as expected you get an old pretty Hello World in your default browser.

Now let’s explore the template and understand what we get for free with this Empty template and start building up our application.

As shown in the previous image, we got two files generated for us Program.cs and Startup.cs and the Movies.csproj itself which contains relevant information to tell Visual Studio what to do with this applicaiton.

Now let’s examine the Program.cs file 

This file actually has a Main method, something we didn’t see for a while in Web projects, ASP.NET Core apps need a host to run. This host implements IWebHost interface, that exposes the features and services needed to start a host.

The lines above first create an instance of the WebHostBuilder, a class helper that builds and configures a host, first configuration stated is UseKestrel is actually telling the host to use Kestrel server, the next configuration UseContentRoot is the telling the host where it should find content files to serve as you can see it takes the current directory as a parameter. UseIISIntegration on the other hand is added to support integration in IIS/IIS Express and is used to specify a reverse proxy to the internal server done by Kestrel. UseStartup tells the host how to configure middleware and services, and as you can see this is the link between the two files, it tells the host to use an instance of the Startup class in the other file. And Finally it builds this host and returns an instance configured for this role.

The next line host.Run() is the one that actually runs the web application and blocks the calling thread until host shutdown. There is also an alternative non-blocking method host.Start().

The next file Startup.cs is the actual ASP.NET configuration that will be used, and we will revisit this file a lot in the subsequent posts and topics.

There is not a lot to describe in this file, it is pretty simple (so far). Two methods are declared one of them for adding services. And the other for intial configuration.

As you can see dependency injection is built into .NET Core and natively supported, if you noticed the using statements, you will the Microsoft.Extensions.DependencyInjection to handle that. So all the parameters values will be located and binded in the runtime behind the scenes, all you have to do is ask for an object implementing an IApplicationBuilder, or IHostingEnvironment or even an ILoggerFactory and you will get a concrete implementation for you to use; there are a lot more like these to come when we explore more and get deeper into ASP.NET Core.

The first line in the method adds a Console logger, on Windows if you run using Kestrel, you would always get a Command window for you and you can see the log traces everytime you do something on the web page. Here on the Mac when using Visual Studio this Logger will be embeded inside the Application Output window.

One intersting thing about ASP.NET Core, that it is really just a Core any service you need to be added or configured, you have to ask for it!! Even the old exception page (the yellow screen of death) which is now a cute light blue screen of death telling you what happend wrong, also not that we only tell the Application Builder to add this DeveloperExceptionPage only in Developement environment, this is a good practice because you don’t want to expose your internal code exceptions in production, you’d probably want to build a custom 500 Error page. Adding this developer exception page is actually adding a “Middleware” to the pipeline, a topic which we will talk about a lot soon.

And the last line is a terminating middleware to the pipeline command, that listens to the requests coming up to this server. It takes a delegate (handler) parameter and as you can see this is the place we are getting “Hello World” from, where we just write a plain text to the Repsonse of the current context.

That was all for this post, very basic no code was actually written, but I believe this post seves as an intrduction to ASP.NET Core and a beginner to the upcoming posts.