A dynamic page is generated on the fly when a user requests it, rather than being statically generated at build time. This is particularly useful for pages that rely on external data, such as product pages, category pages, or search pages. For this article, we are going to use an FAQ Article detail as an example.

This article aims to shed light on one of the most significant changes we've made in Front-Commerce 3.x, making it easier for you to understand.

2.x: file-based routing, Enhancers and Page components​

In Front-Commerce 2.x, dynamic pages were implemented using core components from Front-Commerce.

This included file-based routing, which was implemented by Front-Commerce itself on top of React Router. This allowed developers to map the rendered component to a specific URL by creating a file in the web/theme/routes/.

// The route file was almost empty and only used to declare the Page component
import FaqDetails from "theme/pages/FaqDetails";

export default FaqDetails;

The Page component was responsible for fetching data from the GraphQL API and rendering the page once all the required data was available.

import React from "react";
import Link from "theme/components/atoms/Typography/Link";
import EnhanceFaqDetails from "./EnhanceFaqDetails";
import { H1 } from "theme/components/atoms/Typography/Heading";
import VoteWidget from "theme/modules/Faq/VoteWidget";
import Wysiwyg from "theme/modules/WysiwygV2";

const FaqDetails = (props) => {
  const slug = props.match.params.slug;

  return (
    <div className="container">
      <div>
        <Link to="/faq">⬅️ Back to list</Link>
        <br />
        Slug: {slug}
      </div>
      {props.loading && <p>Loading…</p>}
      {props.faqEntry && (
        <div>
          <H1>{props.faqEntry.question}</H1>
          <Wysiwyg content={props.faqEntry.answer} />

          <VoteWidget faqEntry={props.faqEntry} />
        </div>
      )}
    </div>
  );
};

export default EnhanceFaqDetails(FaqDetails);

Pages delegated the fetching of data to Enhancers (HOCs), which were responsible for retrieving data from the GraphQL API and handling rendering states before feeding it to the Page component.

// The Enhancer was responsible for fetching data and handling rendering states
import graphqlWithPreload from "web/core/apollo/graphqlWithPreload";
import compose from "recompose/compose";
import FaqDetailsQuery from "./FaqDetailsQuery.gql";
import withEntityNotFound from "theme/modules/PageError/NotFound/withEntityNotFound";

export default compose(
  graphqlWithPreload(FaqDetailsQuery, {
    options: (props) => ({
      variables: {
        slug: props.match.params.slug,
      },
    }),
    preloadOptions: (args) => ({
      variables: {
        slug: args.match.params.slug,
      },
    }),
    props: ({ data }) => ({
      loading: data.loading,
      error: !data.loading && data.error,
      faqEntry: !data.loading && data.faqGetBySlug,
    }),
  }),
  // It could also be combined with other Enhancers
  // such as Loadable for a full page loading state
  // Loadable((props) => !props.loading, LoadingComponent),
  withEntityNotFound({
    isFound: (props) => props.loading || props.faqEntry,
  })
);

Enhancers HOCs had several responsibilities and could combine different HOCs from Front-Commerce to achieve the desired result.

For instance, they could combine graphqlWithPreload for fetching data with preloading, withEntityNotFound and Loadable for handling different rendering states. User restricted pages could leverage checkAuth for checking user authentication and redirecting to the login page if necessary.

Plain Remix routes in 3.x!​

In Front-Commerce 3.x, dynamic pages are implemented using a different approach: we've replaced our custom file-based routing with Remix routes.

Remix routes now have more responsibilities than 2.x routes. They export a loader function that is responsible for fetching data from the GraphQL API and passing it to the Page component (main export of the route).

Route loaders can also be used to handle errors (with the ErrorBoundary export), redirections (with the redirect response) and many other checks. Routes code is usually simpler to reason about than Enhancers, with less indirections.

Here is an example of a route that fetches a question from the GraphQL API and renders it using a <FaqDetail /> Page component (that is a plain React component). As you can see, all the logic belongs to the route!

// The route is now a .tsx file, which allows us to use TypeScript and JSX syntax.

import { json } from "@front-commerce/remix/node";
import { useLoaderData } from "@front-commerce/remix/react";
import type { LoaderFunctionArgs } from "@remix-run/node";
import FaqDetail from "theme/pages/FaqDetail";
import { isRouteErrorResponse, useRouteError } from "@remix-run/react";
import { FaqDetailDocument } from "~/graphql/graphql";
import { FrontCommerceApp } from "@front-commerce/remix";

// The route exports a `loader` function that is responsible
// for fetching data and throwing errors, ensuring that
// the main component is only rendered in the "happy path".
export const loader = async ({ context, params }: LoaderFunctionArgs) => {
  const { slug } = params;

  // The `loader` uses the `FrontCommerceApp` class to access the Front-Commerce
  // core from Remix. In this example, we use it to fetch data from the GraphQL
  // unified API (similar to the one you're used to).
  const app = new FrontCommerceApp(context.frontCommerce);
  const response = await app.graphql.query(FaqDetailDocument, { slug });
  if (!response.faqEntry) {
    throw new Response("Question not found", { status: 404 });
  }

  return json({
    question: response.faqEntry,
  });
};

// The main component is a plain React component that receives
// the data from the loader, using Remix fetching primitives (`useLoaderData`)
// both on the server and on the client.
export default () => {
  const { question } = useLoaderData<typeof loader>();

  return <FaqDetail question={question} />;
};

// The route also exports an ErrorBoundary component that is responsible
// for displaying errors. It can be used to display a custom error page.
export const ErrorBoundary = () => {
  const error = useRouteError();

  if (isRouteErrorResponse(error)) {
    return <div>FAQ : question not found</div>;
  }
};

Conclusion​

We hope this article helped you understand how dynamic pages are implemented in Front-Commerce 2.x and 3.x.

Here is a table comparing the different concepts between 2.x and 3.x:

We've made several changes to make it easier for you to build your projects. You can now use Remix routes in a natural way, while still leveraging the power of Front-Commerce with a cleaner separation of concerns.

Join us again for the next article in our Developer Guide series!

Front-Commerce 2.x: Navigating the Configuration Maze​

In Front-Commerce 2.x, configuring your application was not really as intuitive as it was the result of several iterations over time. While the configuration file played a central role, certain aspects raised concerns:

• Unclear naming conventions: The usage of names like webModules, modules, and serverModules in the configuration file introduced ambiguity, making it less intuitive for developers to discern their purposes.
• Distributed configuration files: Configuration settings were spread across various files in src/config, leading to a decentralized structure. This distribution added complexity, making it harder to manage and maintain a holistic view of the application's configuration.
• Dynamic configuration needs: Different modules necessitated separate configurations, extending beyond the main configuration files. This diversity in configuration areas, such as Content Security Policies (CSP) or having to install separated npm packages with specific versions, added an additional layer of intricacy for developers to navigate.
• Overrides challenges: Some "Extension components", such as getAdditionalDataComponent for Payment and Shipping methods, were designed specifically for to be overridden when installing modules.

Here's a snippet of how configuration file (front-commerce.js) looked like in 2.x:

module.exports = {
  name: "Front Commerce DEV",
  url: "http://www.front-commerce.test",
  modules: [
    "./modules/datasource-elasticsearch",
    "./theme-chocolatine",
    "./modules/front-commerce-b2b",
  ],
  serverModules: [
    { name: "FrontCommerce", path: "server/modules/front-commerce" },
    {
      name: "Elasticsearch",
      path: "datasource-elasticsearch/server/modules/magento2-elasticsearch",
    },
    { name: "Magento2", path: "server/modules/magento2" },
    { name: "Magento2GraphQL", path: "server/modules/magento2-graphql" },
    { name: "Magento2Commerce", path: "server/modules/magento2-commerce" },
    { name: "Magento2B2B", path: "front-commerce-b2b/server/modules/magento2" },
  ],
  webModules: [
    { name: "FrontCommerce", path: "./src/web" },
    { name: "Theme Chocolatine", path: "./theme-chocolatine/web" },
    { name: "FrontCommerce B2B", path: "./modules/front-commerce-b2b/web" },
  ],
};

While it served its purpose, these challenges paved the way for a more streamlined and user-friendly approach in subsequent versions.

Front-Commerce 3.x: An unified, simplified configuration file​

Fast forward to v3, and we've completely refactored how a Front-Commerce app configuration was defined. The configuration is now made through a single file, front-commerce.config.js, which includes all the necessary information for running a Front-Commerce app. Let's break down the key enhancements.

import { defineConfig } from "@front-commerce/core/config";
import themeChocolatine from "@front-commerce/theme-chocolatine";
import magento2 from "@front-commerce/magento2";
import adobeB2B from "@front-commerce/adobe-b2b";
import storesConfig from "./app/config/stores";
import cacheConfig from "./app/config/caching";
import appCSPProvider from "./app/config/cspProvider";

export default defineConfig({
  extensions: [themeChocolatine(), magento2({ storesConfig }), adobeB2B()],
  stores: storesConfig,
  cache: cacheConfig,
  configuration: {
    providers: [appCSPProvider()],
  },
  v2_compat: {
    useApolloClientQueries: true,
    useFormsy: true,
  },
  pwa: {
    appName: "Front-Commerce",
    shortName: "Front-Commerce",
    description: "My e-commerce application",
    themeColor: "#fbb03b",
    icon: "assets/icon.png",
    maskableIcon: "assets/icon.png",
  },
});

Single Source of Truth​

In contrast to v2, the v3 configuration file is now the single endpoint for all things application-related. All extensions are registered through this file like before, but it now also features the various configuration previously found in src/config/*.js files, such as stores and caching configuration. This makes using the configuration details much more reliable in the app.

Typing with TypeScript​

Leveling up the developer experience, the v3 configuration file is now fully typed using TypeScript. Autocomplete and type checking bring a greater level of clarity and confidence when writing your app’s configuration, while also giving a quick sneak peek of each extension features and customizations.

Extension API​

As said above, v2’s “modules” have evolved into "extensions" in v3. Their registration is now a eased through a simplified extension API (defineExtension() and defineRemixExtension()) which streamlines the process and makes your application more modular and extensible. Each extension can directly define their own needs so that their usage is simplified in front-commerce.config.js

This subject however deserves a whole article to be written about it — **stay tuned** 👀.

Themes​

Theme overrides, once defined via webModules, are now an integral part of the configuration. Registering them becomes as straightforward as any other extension, streamlining the overall architecture, and further reducing the main configuration file responsibilities.

No more use of src/config/*.js​

V3 eliminates the need for separate configuration files (src/config/*.js) for stores and caching. Previously, those files were imported and used by components all over the codebase. Now, those are directly included in front-commerce.config.js, promoting a cleaner and more organized setup. This configuration is accessible through a shared “config” that is available in all key location in the code.

Embracing the change​

The transition from V2 to V3 marks a paradigm shift in how we approach configuration. With a consolidated and type-safe configuration file, we are confident developers can embrace a more efficient and enjoyable development experience. In upcoming version, further specific extension points will be added to complete our “configuration arsenal”, and make it even better than before.

Please let us now what you think about this, and stay tuned for the Front-Commerce Advent Calendar’s next article!

In Front-Commerce, we’ve always ensured that every applications could be turned into a PWA to improve the user experience. To achieve this, developers can rely on standard web features and technologies that we name “the PWA Stack”. Front-Commerce acts as a technical enabler to ease the lives of developers to create and maintain this stack.

In this blog post, we will explore the evolution of this “PWA Stack”, from its manual asset generation approach in Front-Commerce 2.x to the streamlined and automated process introduced in Front-Commerce 3.x.

What does the PWA Stack consist of?​

The PWA Stack, is our term to describe the different assets, technologies and practices turning websites into web applications with native app-like capabilities.

A PWA is built on the principles of progressive enhancement and web standards. It provides the ability to a website for being installed and run on various devices. The stack consists of three main components: the manifest, service workers, and app shell.

The manifest is a JSON file that describes the application and its behavior, including details such as the name, icons, start URL, and display mode.
Service workers are scripts that run in the background and enable features such as offline access, push notifications, and background synchronization.
The app shell is the minimal HTML, CSS, and JavaScript needed to power the user interface when the application is launched.

These components must be combined together to create reliable, fast, and engaging web experiences that are accessible to all users, regardless of their device or network conditions.

In Front-Commerce, the PWA Stack empowers developers to generate and register these components in a cohesive way so they can have a minimal setup working out-of-the box, so they can focus on developing code adapting the user experience to match their specific needs (or stick with the default minimal PWA setup).

2.x: a default PWA Stack to override​

In Front-Commerce 2.x, the process of generating PWA assets is ready when starting a project. It however requires manual customization by integrators and developers.

Developers must override the manifest.json and app-shell.html in their project and modify its content to match their project, including the name, short_name, colors, and icons. While this provide flexibility, it also introduce complexity and the potential for human error.

One common pitfall is that developers often forgot to customize the PWA assets entirely or partially, leading to a generic and less effective PWA implementation when going live (hopefully we detect this when auditing the site, but it can then be forgotten or not prioritized).

Another problem we found over time, is that developers don’t necessarily want to invest in advanced customization or don’t understand clearly each of these components responsibilities. It could lead to partially working experiences.

We provided guidance on how to customize the PWA Stack components provided by Front-Commerce to ensure that the website is recognized as a Progressive Web Application (PWA), but as any guide … it doesn’t enforce anything!

3.x: simplicity first​

In Front-Commerce 3.x, we approached the PWA Stack in a different way.

We focused on providing a simple and efficient way for integrators to describe the PWA Stack with metadata, and for Front-Commerce to derive all the required stack automatically.

This approach not only reduces the burden on integrators and developers but also ensures consistency and adherence to PWA best practices.

Technically, you will adapt the following configuration in your front-commerce.config.ts configuration file.

import { defineConfig } from "@front-commerce/core/config";
import themeChocolatine from "@front-commerce/theme-chocolatine";

export default defineConfig({
  extensions: [themeChocolatine()],
  // […]
  pwa: {
    appName: "ACME Store",
    shortName: "ACME Store",
    themeColor: "#fbb03b",
    icon: "public/pwa-icon.png",
    maskableIcon: "public/pwa-masked-icon",
    cacheTTLInMs: 7 * 24 * 60 * 60 * 1000,
  },
});

It only takes a few minutes to define, then Front-Commerce takes care of generating all assets required for your PWA Stack consistently.

The PWA assets are generated in adherence to best practices and include all different icon variations in the manifest, so each device can use the most adapted to their specifications.

Advanced customization​

While the default PWA Stack is sufficient for most projects, we also want to provide more advanced customization options for developers who want to go further.

In Remix, routes are a great abstraction over the network layer. They allow to describe the data requirements for a given page, and could be used in the context of a PWA to provide a fallback when the data is not available. That's the goal of the Remix PWA project.
In Front-Commerce 3.x, our PWA Stack is using Remix PWA under the hook, but doesn't expose extension points for you to leverage its full power yet.

We're looking for your feedback and use cases to help us prioritize the next steps. Please reach out to us if you have specific PWA use cases in mind!

Join us again for the next article in our Developer Guide series!

We're launching Front-Commerce v3 on Product Hunt. Please support us by upvoting Front-Commerce and sharing it with your network.

This launch aims to introduce Front-Commerce to a broader audience, especially those who are not yet familiar with our product.

Read more for a step-by-step guide explaining how to upvote. It will take less than 1 minute!

We're so grateful that you're interested in upvoting our launch on Product Hunt. It’s really important for us.

Here's a step-by-step guide to help you through the process:

1. Head over to our Product Hunt “Front-Commerce 3.0” launch page
2. Click on the upvote button.
3. You'll then be prompted to log in or create an account if not already logged it. You can use your Google, Twitter or LinkedIn account for a quick signup.
4. ⚠️ After logging in, click on the upvote button again 🤷. This time, your vote will be recorded and added to the product's total score near the UPVOTED button.
5. Congratulations! You've successfully upvoted our launch on Product Hunt. Your vote helps the product gain more visibility, and could potentially lead to more users and customers.
6. Bonus: Spread the word!
   • Share this article in your open space, on Slack communities you’re part of,
   • Retweet us on X
   • Share our announcement on LinkedIn

Thank you for being a part of the Front-Commerce community. Keep up the great work! 🎉

Join us again for the next article in our Developer Guide series!

Now, with Front-Commerce v3, we are excited to bring all our experience from the past seven years to the Remix ecosystem.

Read more to discover how Front-Commerce extends Remix to incorporate all the features available in Front-Commerce v2.

Front-Commerce 2.x: the “all-inclusive” solution​

When Front-Commerce was created, React and GraphQL were still evolving with limited frameworks for developers to use. Most of the ecosystem relied on Create React App for client-side rendered applications or Gatsby for static site generation.

Our team understood that server-side rendering was a more accurate option for eCommerce storefronts, which is why we made it a core feature of Front-Commerce.

With the release of Front-Commerce 2.x, we integrated all the necessary features you would need into the core: from bundling and server-side rendering, to routing and HTTP caching.

To illustrate, the components of a Front-Commerce 2.x app look like this:

Key highlights of a Front-Commerce 2.x:

• Front-Commerce must be an Express.js Node application.
• During server-side rendering (SSR), developers can only use Front-Commerce's extension points to access server-side-rendered data.
• Front-Commerce only supports the addition of Express middlewares at specific extension points.
• Hydration is managed by Front-Commerce with some restrictions such as inability to register global React context providers

Front-Commerce 3.x: leveraging Remix​

Fast-forwarding to 2023, the industry has seen the emergence of several stable and popular frameworks, with Next.js and Remix at the forefront. After careful consideration, we decided to adopt Remix for several reasons previously outlined in another article.

Our priority has always been to ensure that the development experience with Front-Commerce is seamless and consistent with how these technologies can be used outside of Front-Commerce. This approach not only ensures that agencies can efficiently onboard new developers, but also guarantees that projects developed with Front-Commerce are future-proof and can evolve with the industry.

To achieve this, we've made a fundamental change: we made Front-Commerce usable in any standard Remix applications. This is a change for developers familiar with Front-Commerce 2.x, but it means that developers have more freedom and autonomy.

In short: you own your Remix application, Front-Commerce brings the batteries powering your composable storefront.

Technically, the components of a Front-Commerce 3.x app look like this:

Key points to take away from this:

• Your application is based on a standard Remix app.
• Launch your application using Front-Commerce's CLI, which takes care of running additional tools such as GraphQL Codegen, Sass compilation, TypeScript, and more.
• Front-Commerce provides additional features such as Extensions, theme management, configuration, and GraphQL unified schema.
• To initialize Front-Commerce, certain key components such as Remix’s server.ts must bootstrap it.
• You interact with a FrontCommerceApp from your loaders and actions to use Front-Commerce.
• The skeleton contains a boilerplate: it is completely transparent when creating a new application.
• Currently, Front-Commerce only supports @remix-run/express, but it has been designed to be easily portable to other deployment targets (Cloudflare, Netlify, Vercel, etc.) in the future.

How do you feel about this?​

We’re aware that it may not be totally clear for you yet. We recommend to keep this in mind while reading the rest of our Advent Calendar Series that will dive into each component, and provide practical examples of using every Front-Commerce feature in a Remix application.

If you have any questions or concerns, feel free to keep the conversation going: we’ll be happy to answer!

Join us again for the next article in our Developer Guide series!

Creating new Front-Commerce projects quickly has endless advantages: build a minimal reproduction case for reporting issues, quickly test solutions, explain concepts to colleagues, or prototype for potential customers.

In this article we’ll explain how we made this process as smooth as possible, so you could start from a fresh, minimal state within seconds.

The importance of a starting point​

When we started working on Front-Commerce, we wanted to make sure that starting a new project would be as easy as possible.
We made a deliberate choice to offer a "starter" project containing all the essential boilerplate code needed to launch a fully functional Front-Commerce application locally.

The maintenance of this project presents several challenges, which may not be immediately apparent:

• have a good DX (this is the first impression newcomers will have of Front-Commerce),
• keep it up-to-date with the latest versions of Front-Commerce and dependencies,
• find the right balance (amount of code) between
  • a good starting point with many examples for newcomers,
  • as minimal as possible so new long-term projects don't have to remove unnecessary code.
• convenient to use in different scenarios (workshops, demos, examples, reproduction cases, etc.)

2.x: with the skeleton repository​

In Front-Commerce 2.x, we have introduced a skeleton repository, which serves as a foundational Front-Commerce project pre-configured for a Magento2 setup.

Developers can clone the git repository, update specific configurations with their Magento2 instance information, and they are good to go!
For connecting a different stack, additional changes are required. Read our 2.x installation guide for the exact steps.

Recognizing the need for tangible and actionable examples, we have launched a new examples repository.
These example modules can be seamlessly integrated into a Front-Commerce's skeleton project, demonstrating practical applications of concepts outlined in our documentation.

The use of the skeleton and examples repositories has become increasingly prevalent in our support activities, offering a more effective means of illustrating concepts through concrete examples.
This approach has also proven to be more user-friendly and has evolved into a mechanism for generating short-lived reproduction cases when reporting a bug.

3.x: with the create-remix CLI command​

In Front-Commerce 3.x, we have reevaluated and redefined our approach, driven by two primary objectives:

1. Simplified project initiation: it should take less than 30 seconds to start a new project from scratch, with a minimal configuration
2. Unified use cases: we want to use a consistent process for both our internal use cases and our users, unifying the experience across the board.

Front-Commerce's skeleton is a Remix Stack​

Front-Commerce 3.x is built on Remix, you know this!
Remix is a framework that provides a CLI command to create new projects, called create-remix.

Naturally we decided to embrace the Remix way of doing things, and we turned our skeleton into a Remix Stack.
A Remix Stack is a Remix project that can be used as a template for create-remix.

Launching a new Front-Commerce 3.x project from scratch should be as straightforward as running:

npx create-remix hello-front-commerce --template https://new.front-commerce.app/
# or with pnpm
pnpm dlx create-remix hello-front-commerce --template https://new.front-commerce.app/

Please follow our detailed Installation page if you want to try it out.

A "minimal" mode​

For technical reasons (and design flaws), it was not possible to start a Front-Commerce application without a remote service in 2.x.
We reworked our core to make it possible in 3.x. We call this mode the "minimal" mode, as it doesn't require any remote service.

This mode is perfect for evaluation purposes, workshops, and for creating reproduction cases when reporting an issue or testing an idea.

Technically, a "minimal" Front-Commerce application is an application with a single extension: @front-commerce/theme-chocolatine.

The skeleton is now part of Front-Commerce's repository​

If you want to find the code of our skeleton, you can find it in our main repository.

We decided to move it there for several reasons:

• it's easier for us to maintain, as its code can be updated in the same changeset as Front-Commerce's code
• it allows us to use the same code than our users when working on core features
• it makes our core repository a standard Front-Commerce project repository, deployable on Front-Commerce Cloud without any special treatment

It has no impact whatsoever on our users, but we find it interesting to share this information with you: we're dogfooding our own product in a better way now! 😉

Examples and demos are also part of the skeleton​

As of writing, we have reorganized the code for our demos under the skeleton directory, and a similar transition is underway for our examples.

In Front-Commerce 3.x, a notable feature is the ability to package everything as an extension. Leveraging this functionality, we have encapsulated our examples and demos as extensions, housed in the ./example-extensions subdirectory of the skeleton.

When initiating a new project, you can enable any of these extension by registering them in the front-commerce.config.ts file.
For those embarking on a new "long-term" project, the extra-step of removing the ./example-extensions directory will set you on the right path.

Our rationale behind this approach is that the ability to swiftly run a demo or example locally far outweighs the trade-off of having additional code in the skeleton.

What’s next?​

We're still working on improving the experience of starting a new project, and want to ensure that it fits your use cases.

In the pipeline, we are gearing up to introduce the following changes:

• an installation CLI with prompts to help you configure it initially (register and install the extensions you want to use, populate the .env file, etc.)
• migration of all our examples to Front-Commerce 3.x.
• increased utilization of minimal reproduction cases during support interactions.

❓ We would greatly appreciate your input on the following:

• what additions would you like to see in the skeleton?
• how can we further reduce friction in your daily use cases?
• are you interested in a "Fake store" extension that populates your local storefront with sample products, categories, etc.?

Join us again for the next article in our Developer Guide series!

In today’s article, we’ll explain why we switched from a single Git dependency to several npm packages from a private registry.

2.x: a single Git dependency​

In a Front-Commerce 2.x project, the core is distributed as a single Git dependency. To install or update it, use the following command:

npm install git+ssh://git@gitlab.blackswift.cloud/front-commerce/front-commerce.git#2.27.0

You get all the code, directly from our private Git repository. While this approach may seem convenient and straightforward, it comes with some drawbacks:

• SSH Access Setup: Setting up SSH access to our private repository, including in your Docker development stack and CI environment, can be a source of misunderstanding and frustration for your team.
• Unnecessary Code: You receive all the code, even the portions you don't use, which can be confusing when browsing the codebase.
• Unnecessary Dependencies: You also get all the dependencies of modules you don't use, potentially leading to conflicts with your application dependencies and increasing the size of your node_modules and project folder.

This approach also has direct engineering consequences in the way the code is designed and released.

For instance, we have to rely on our own patterns and conventions to expose a public API.
In 2.x, developers can use almost any internal module (resolvers, factories, adapters…). Even if an exported class or function was designed for internal use in a first place, we have to be very careful about breaking changes when we wanted to refactor it.

3.x: transition to a set of npm packages​

In Front-Commerce 3.x, we have transitioned to a set of npm packages, which are now published on a private GitLab registry. To install or update these packages, use the following command:

npm install @front-commerce/core@3.1.1

Authentication​

Instead of using SSH, you can employ any private registry technique to install the packages. For instance, you can use a .npmrc file:

//gitlab.blackswift.cloud/api/v4/projects/24/packages/npm/:_authToken=<your_gitlab_token>
@front-commerce:registry=https://gitlab.blackswift.cloud/api/v4/projects/24/packages/npm/

Modularized Packages​

The core has been restructured into several distinct packages, each serving a specific purpose:

• @front-commerce/core: the fundamental elements of Front-Commerce, including the GraphQL API, React components, Configuration, Caching, and more, as known from 2.x.
• @front-commerce/remix: provides low-level adapters and public API for accessing @front-commerce/core features in a standard Remix project (more details on this later this month 😉)
• @front-commerce/compat: offers a compatibility layer that enables the use of 2.x features and removed APIs in a 3.x project, ensuring a seamless and progressive transition.
• @front-commerce/theme-chocolatine: serves as our base theme, featuring a fully-equipped storefront with a set of React components and styles to build upon.
• All other packages are features, packaged as Front-Commerce Extensions. These can be selectively chosen and combined based on your project's specific requirements. Examples include:
  • @front-commerce/adobe-b2b,
  • @front-commerce/algolia,
  • @front-commerce/contentful,
  • @front-commerce/magento2,
  • @front-commerce/paypal,
  • etc.

All packages are versioned in unison and align with our Front-Commerce versioning.
We decided to bump the version number for every release, even in the absence of change in the package. This approach facilitates easy identification of the Front-Commerce version used in your project and simplifies communication about it.

Similar to the process in 2.x, you can update all @front-commerce/* packages simultaneously.

Advantages​

This new approach offers several benefits:

• It matches the way you work with other dependencies in your projects.
• Package exports are explicit, exposing only what is intended for external use. This clarity makes it easier to discover what's here for you to use and enables us to provide better backward compatibility guarantees.
• You will install only the necessary components, avoiding unnecessary bloat.

To illustrate this last point, let's compare the size of a Front-Commerce 2.x node_modules folder with a 3.x one, on our Magento2 demo project:

• Front-Commerce 2.x: 1.3 GB
• Front-Commerce 3.x: 321 MB 🎉

We hope you'll enjoy this new approach as much as we do! We eagerly await your feedback.

Join us again for the next article in our Developer Guide series!

As we get into 2024, we wanted to take a moment to reflect on our most important release so far: Front-Commerce Remixed!

Let’s dive in!​

In these series, we’ll break down specific development tasks tackled in Front-Commerce projects. We’ll compare how it was done in 2.x, and its counterpart in the present, so we can all learn and grow together.

Over the years, we've gained valuable insight into how our product can better serve our users. As we introduced new features and more projects and teams were providing feedback, we noticed some recurring themes.

We recognize that developers are continually seeking ways to streamline their workflow and improve their development process. That's what drove our vision for the changes we brought in Front-Commerce Remixed.

A series made for you!​

Small, easy to digest, knowledge bites even when you're on the go. Regular new articles that can fit into the busiest of workdays. Keep track of all the articles in this series by referring to the index we've provided below (we’ll keep it up-to-date):

1. 🎉 Introducing the Front-Commerce Developer Guide series! 🎉 (you're reading it!)
2. Front-Commerce: your project’s dependency
3. How-to create a new Front-Commerce project?
4. Remix extended for Composable Commerce
5. We're launching on Product Hunt! 🚀
6. PWA Stack: from manual to automated asset generation
7. Front-Commerce 2 vs 3: a cleaner, more powerful configuration file
8. Dynamic page implementation: a side-by-side comparison

We Value Your Feedback!​

From the entire FC team, we want to say thank you for your continued support and feedback that has helped us to create and continuously refine the best possible product for developers and merchants.

Let’s make it a conversation! 🗣️
Your thoughts and feedback on these articles, new APIs, or features are always welcome. We're eager to chat and listen to your ideas and suggestions. Don't hesitate to share your thoughts with us on Slack, support channels or email. We're in this together!

Stay tuned!​

Stay tuned for tomorrow's post, where we'll start diving into concrete changes between Front-Commerce versions 2.x and 3.x.

Follow us on Twitter, LinkedIn or subscribe to our RSS feed (simple and efficient!) so you don’t miss an article.

At Front-Commerce, we conduct thorough audits on our client projects and provide recommendations to improve website performance and user experience. In this blog post, we will discuss the key points we measure during our audits.

🚀 Performance​

Performance is a critical factor in the success of an e-commerce store. A slow website can lead to frustrated customers and lost sales. During our audits, we measure the performance of our client's websites in two key areas: server and webperfs.

Server​

During our audits, we check if the website's server is performing well. We make sure that things like cache and data loaders are implemented correctly to improve server performance. We also verify if the cache strategies are properly implemented to reduce the number of requests made to external services. Another thing we check is that the server-side rendering (SSR) is implemented properly to improve the TTFB. We also ensure that there are no memory leaks that can negatively impact the application's stability.

Webperfs​

Another important part of our performance audit is the webperfs analysis. webperfs measures the website speed, responsiveness, and overall user experience. This includes checking if the website's fonts and images are optimized for the store and if the JavaScript bundle size is at an optimal level. We also check if important pages are preloaded to improve the perceived performance for end users.

🎨 Theme customization​

We understand that every e-commerce store has unique branding requirements. During our audits, we check if the website's theme has been customized to match the client's branding guidelines. We also ensure that any customizations do not negatively impact the website's performance or user experience.

🦻 Accessibility​

We believe that all websites should be accessible to everyone, regardless of their abilities. During our audits, we check if the website meets accessibility standards, such as having proper alt tags for images, keyboard navigation support, and proper contrast ratios.

🖌️ Styleguide​

Consistency is key when it comes to creating a great user experience. During our audits, we check if the website's style guide is consistent throughout the website. We also ensure that the website's typography, colors, and spacing are in line with the client's branding guidelines.

📨 Links received by e-mail​

A customer journey extends beyond the web UI and encompasses email interactions. That is why we also check the links that are received by email, as it ensures that customers can access the correct pages of the website, leading to a better overall user experience.

🔗 Audit broken links in the store​

In a project, developers could have forgotten to update a hardcoded link, or content writers may have contributed unfinished content or made typos. That's why during our audits, we perform a thorough check for broken links and provide recommendations to fix them, ensuring that the website's user experience and SEO are not negatively impacted.

🔍 SEO​

Having good SEO is crucial to driving traffic to the website. During our audits, we check for the following:

404 & redirections​

We check for any 404 errors and ensure that the website has proper redirections in place. This is especially important when migrating to Front-Commerce from another platform, as the links may not be in the same format. This can cause 404 errors for any pages previously crawled by search engine robots, such as Google.

Robots.txt​

We ensure that the website's robots.txt file is properly configured to allow search engines to crawl the website's pages.

Sitemap​

We check if the website has a sitemap.xml file and that it is correctly generated. More information about this can be found here

Meta tags and microdata​

We ensure that the website's meta tags and microdata are properly configured to improve the website's search engine rankings and visibility when sharing on social platforms.

📱 PWA (Progressive Web App)​

We ensure that the store meets the standards for a PWA. We provide recommendations to improve the website's PWA capabilities.

📈 Analytics​

During our audits, we check if the website has proper analytics tracking in place. This helps our clients to make data-driven decisions to improve their website's performance and user experience. More information about this can be found here.

🧑‍💻 Code quality audit​

Auditing code quality in a project is essential for several reasons. Firstly, it helps identify and rectify potential bugs, vulnerabilities, and performance issues, ensuring a more stable and secure application (as mentioned above). Secondly, it promotes maintainability and ensures that the project can be updated during its life. By adhering to Front-Commerce best practices, developers can upgrade to newer Front-Commerce versions more easily and with less risk of introducing bugs. Finally, our code quality audit encourages consistent coding standards and improves overall code readability. This leads to a more robust, efficient, and sustainable codebase.

🪄 Application stability​

Application stability is a crucial aspect of a composable architecture, like the one used by Front-Commerce. It refers to the website's ability to remain resilient to external systems outages, such as server downtime or configuration errors. Ensuring stability is essential for a front-end solution like Front-Commerce, as it directly impacts the user experience and the website's ability to drive sales. Front-Commerce conducts thorough audits to identify potential issues that could affect stability and provides recommendations to improve resilience and ensure a reliable website.

✨ Magic Button​

We believe in going above and beyond for our clients. During our audits, we look for opportunities to add additional features to the website that will improve the contribution experience and improve the merchant’s team productivity. Our Magic Button feature allows contributors to seamlessly improve the content on the website with direct links to the content source. We ensure that the contribution mode activation is secure and that any custom content is wrapped with the StorefrontContent component. More information about this can be found here.

☁️ Prod server & CI​

We check if the website is properly deployed to the production server and if the continuous integration (CI) process is working correctly. This ensures that the website is always up-to-date and running smoothly.

🗒️ Audit logs​

After conducting a thorough audit of the website, it's important to keep track of any bugs or issues that may arise once the site is live. While we analyze the codebase and test the application during the audit, we believe that analyzing application logs and monitoring metrics is also crucial once the site is live. This allows us to detect any smaller bugs or performance issues that may have been missed during testing. We follow up on our audits with log analysis a few days after the project is live to ensure that everything is running smoothly and to address any issues that may arise. By addressing these smaller issues, we can improve the overall quality of the application.

☑️ Checklist before production​

Before we proceed with the audit, we have a checklist that should ideally be done by integrators in the project. This checklist includes items such as verifying that the environment is properly configured, that the data has been properly migrated, and that there are no broken links or missing assets. You can find a detailed checklist in our documentation here.

Conclusion​

In summary, audits are essential for ensuring that e-commerce websites meet the high standards necessary to drive sales and provide an exceptional user experience. At Front-Commerce, we take great pride in conducting comprehensive audits and providing our clients with actionable recommendations to enhance their website's performance and user experience. By partnering with us, our clients can rest assured that their website is optimized for success and delivering the best possible experience for their customers.

This Performance section is introduced with the following sentence:

Performance is essential to improve user experience, but also to reduce server load and thus increase the site's traffic capacity.

So the point of the whole section is not only to increase the performances i.e. in that case, the time it takes to generate a page but also to increase the scalability of the application i.e. according to Wikipedia, the property of [the application] to handle a growing amount of work.

To measure the number of external requests, you can use one of our debug flags. For instance, here I'll use a very basic setup where Front-Commerce is connected only to a Magento2 instance, so I can add DEBUG=axios in the environment to have some information about external requests. Depending on your actual setup, you might need other values to also count requests to Prismic or any other external service.

Also, we are mainly interested in the most popular pages of the site. Commonly, the homepage is most visited page. By default, we also check the category and the product pages. Depending on your project, this list can be slightly different.

Number of external API calls versus performance​

Note: Performance is a very wide topic. By performance here, we are looking at the time needed to generate a page server side. This is very easy to measure with a curl based command:

$ time curl -s http://example.com/my/url > /dev/null

On a Front-Commerce setup configured without cache and connected to a Magento2 instance, 27 requests to Magento2 APIs are needed to generate a category page. Each of these requests takes a significant amount of time, sometimes several hundred of milliseconds. While when caches are enabled, if everything is in cache, no external request is made.

Without surprise, the time needed to generate the page is completely different:

• without cache, on my local setup, it took between 5 and 6 seconds;
• with everything already cached, it took between 200 and 300 milliseconds.

It's 20 times faster! The example is a bit extreme, but I guess you get the point. Also, without external requests, the response time is somehow similar to any external API call. This means that if on a page you have one external API request left, getting rid of it might divide the response time by two. Worth a try, don't you think?

Number of external API calls versus scalability​

Measuring the scalability is harder. It is done with load tests that involves running some scenarios to simulate traffic peaks (usually inspired by past events) in a production like environment. That's definitely not something you can do reliably on your local environment in 10 minutes. That being said, we always see a clear correlation between the number of external requests and the scalability of the application.

Commonly, the target of those external requests (the Magento2 instance in my previous example) becomes the bottleneck of the application especially if some popular pages requires several API requests to the same service i.e. one page generated by Front-Commerce entails n requests to one external service.

Depending on how Front-Commerce is hosted, it can also be the bottleneck because it will be busy waiting for some APIs to reply 😀.

The conclusion is simple: when it comes to external request, the less the better. After having said that, it remains the hard work of optimizing the application and the recipe is classic:

1. is the external request strictly needed ? In some case, it might be an opportunity to discover useless code or to discuss feature;
2. if it is strictly needed then you need to add more cache to the application either by leveraging the dataloader mechanism or by using the cache at resolver level if your project embeds content from Prismic.

A typical remote developer kit will often include a laptop and one or more monitors. In my case, because I already had a multi-monitor setup for my personal desktop PC, all I needed was to come up with a way to homogenize and make it work with the company’s provided laptop.

My current setup: VS Code Remote Development​

What is it ?​

VS Code Remote Development is an extension pack for Microsoft’s widely used IDE VS Code. It allows developers to “use a container, remote machine, or the Windows Subsystem for Linux (WSL) as a full-featured development environment”. What it means, is that you will have your source code located on a single place, and you will be able to update it seamlessly from another system using VS Code.

Note: see our blog post on installing a WSL development environment if you're interested.

The requirements are:

• For the client, pretty much anything capable of running VS Code (with special needs for containers for Microsoft Windows due to Docker’s own requirements)
• For the host, a wide range of systems are supported. If you’re not using a “mainstream” OS or distribution, you might want to check the requirements section of the extension pack’s Marketplace page.

In this blog post, we’ll only talk about the SSH connections, so you will need to ensure that your host has an SSH Host set up. If you don’t, you can follow Microsoft’s guide on how to setup one. For example, on Ubuntu, you can the command sudo apt-get install openssh-server.

Installation​

That’s where this method shines.

The package installation on the client side is really simple: you’ll only have to install the Remote Development extension pack from Visual Studio Marketplace on your local machine’s VS Code. This will provide your IDE with all needed extensions to work on your remote environment.

Once that’s done, you will notice two new icons

• One in your Activity Bar (the vertical bar on the left of VS Code) which is the “Remote Explorer”. Clicking on it will reveal the explorer’s sidebar, in which where you will be able to see your different connections.

• One in the left of your Status bar (the horizontal bar at the very bottom of VS Code’s window), which will display what host the current window is “attached” to.

In our case, we’ll create a new SSH connection by clicking on the icon in the Status bar, and select “Connect Current Window to Host…” in the popup that appears:

Then, select “Add New SSH Host…”, and type in the ssh command you’d normally use to connect to your host machine; typically ssh <my_user>@<my_host>. You might be asked to enter your host user’s password, and then VS Code will install all the necessary packages on your host machine (you will notice a notification stating “Setting up SSH Host on …”).

And that’s it! Hopefully once that is done, you'll already be set to develop on your host from your local machine. You’ll notice the icon in your Status bar is now showing the host you’re connected to, and you’ll be able to see the new connection in the Remote Explorer.

Password-less connection with VS Code Remote Development​

One thing that might get tiring using VS Code Remote, is that you might need to type your password each time you open a new VS Code window or each time your it gets disconnected from your host, if your internet or local network connection has hiccups for example. To solve this issue, I configured the SSH connection so that is uses a RSA key I created for this purpose. Here’s how it is done:

Create a new key​

You can use ssh-keygen to create one. it is available on most Linux subsystems, and on Windows Powershell.

ssh-keygen -q -b 2048  -f "./<myhost>_rsa" -t rsa

This will create two files: <myhost>_rsa (the private key) and <myhost>_rsa.pub (the public key). The private key will stay on your client (typically in the ~/.ssh/ folder on Linux subsystems)

The public key will need to be copied onto your host. On Linux systems you will need to add the content of the public key to the end of the ~/.ssh/authorized_keys file. If the file doesn’t exist, copy your public key in ~/.ssh/, rename the file to authorized_keys and give it a permission of 600:

chmod 600 ~/.ssh/authorized_keys

Make VS Code use the key​

On your client IDE, go to the Remote Explorer, and click the cog icon next to the SSH section, and then open the config file shown in the popup by clicking on it:

In this file, you’ll find the connection you set up and its configuration. In order to make VSCode use the key you created, add these lines to the configuration section:

Host <my_host>
  HostName <my_host>
  User <my_user>
  Port 22
  PreferredAuthentications publickey
  IdentityFile "~/.ssh/<my_host>_rsa"

After this, VS Code should not ask for your user's password again!

Pros and cons​

Every method has its own advantages and disadvantages, and using this one certainly does not make any exception to this rule.

Pros​

Ease of use​

As stated in during the installation part, one of the most convenient points of this method is the ease of use. Installation is really easy and well documented on VS Code docs, and within VS Code itself. Configuring it on a brand new machine should not take more than a few minutes, and you will immediately have access to all of your host’s installed extension without needing to authenticate to your Microsoft of Visual Studio account.

Connectivity​

Similarly, any terminal opened on the client will actually be an ssh connection on your host, and VS Code is (most of the time) able to analyze your local app’s log to automatically forward the right port on your local machine, which means you will be able still connect to localhost:XXXX on your local machine during development, without any server running locally. If VS Code does not detect the local port correctly, you will only have to add it quickly through the Command Palette "Forward a Port" command.

Portability​

On the hardware side, my host (laptop, in my case) still stays as portable as ever, as I would only have to put in in my bag and I’ll still be able to develop on-the-go the same way I do on my desktop, without having to unplug anything (beside the laptop’s charger). And once I’m back, I can reuse my home setup.

Development and tests​

Finally, having such a setup with two machines is also an advantage for development. Two machines means potentially two OSs, and it can become handy to test some code on two completely different, yet very “real” environments. In my case, My desktop runs on Windows and my laptop on Ubuntu, meaning I can easily test OS-specific features if the need arises (it used to be really useful for Internet Explorer, luckily gone are those days! 😅), while keeping the Linux CLI environment I prefer.

Cons​

Here’s a catch though: two machines, also means two running machines, which in turn means more energy consumption as well. This is definitely not an environment friendly method!

During specific use cases, I sometimes encounter issues with port forwarding that force me to get back to my laptop’s keyboard, for example when using Docker with Traefik, VS Code is sometimes confused about what port to forward and where to forward it to.

On the hardware side, this method renders your laptop (or host) a bit less useful, as most of the time you’ll work at home you won’t touch it much, besides turning it on or off. We will see in the next part other methods I tried that actually uses both machines actively.

On the management side, depending on how you manage your local machine, and how (if) you use it outside of work, you’ll have to take extra care of not mixing work and personal things, which can be extra tricky for some, especially if you’re pretty new to working at home.

Comparison with other methods I have tried​

Why not use a dock ?​

Most docks are really great at what they are meant to do. Unfortunately, this doesn’t include sharing peripherals between devices, which was my goal here. I still use my dock, however in my current setup, because I use the same keyboard / mouse for both my machines, it would mean plugging / unplugging those everyday which is kind of painful.

Using both machine efficiently: Synergy / Barrier​

This was by far my most preferred method. Synergy (and its open source clone Barrier) is a keyboard and mouse sharing software, that enable a single pair of peripherals to work on many different machines at the same time. Unlike VS Code remote (or SSH) only, using Synergy you are able to actually use every device’s UI as well, and coupled to VS Code Remote, you can basically use “any” number of machines the same way you’ll be using one.

Unfortunately, I had a bug on Ubuntu using Barrier that made me stop using this method some times ago as I couldn’t find a solution. If this issue was to be fixed however, I would hop in the Barrier train any day!

Another point of view: the Virtual Machine way, and Tmux​

That’s a solution that requires a bit more setup, and isn’t really compatible with VS Code either, but might be interesting for Vi / Vim and terminal power users out there. Tmux is a terminal multiplexer, a software capable of running multiple terminal session in a single windows. This also allows terminal session to be “saved” and accessed from another device, meaning using terminal based editors, your could pickup your work right where you left it seamlessly, from pretty much any terminal on OSs supporting tmux (even from your phone!). Coupling Tmux with a Virtual-machine hosted source code, it would be one of the best method I can think of in terms of accessibility and portability (given you always have an internet connection where you go, which is not a hard requirement to satisfy in 2023).

However, because I’m not yet accustomed to terminal based IDEs, I only used this method for very small tasks and personal projects.

Conclusion​

My current setup is not definitive, nor perfect. I keep updating and tweaking it as time goes on. For example, another solution I might look up in the future is KVMs, a physical interface that connect peripherals to devices, the same way as Synergy does on the software side. Those have been out for a while, but compatibility was not great for a long time.

I think every developer should invest a bit of their time to think about their setup from time to time. A lot of time is spend at our desks, and we now have all kind of tools, whether they be software or hardware, to make our lives better, so let’s take advantage of them!

I hope you enjoyed this quick tour of my own setup, and if you want to learn more about other topics related to development, please tune in for more blog posts!

It can really help you navigate in an application or switch between different applications and contexts without any friction. We'll also illustrate the Unix philosophy, and provide tips for gradually adopting these practices.

I hope you find this helpful!

Why using your keyboard more?​

As developers, we spend a lot of time typing on our keyboard. For typing code of course, but also for searching, documentation (issue tracker, wiki…) and communicating with others (Slack, Teams, Discord, emails…).

Now, think about how you switch context between different applications.

You’re writing code in a text editor, but want to ask a question to a teammate on Slack:

• do you leave your keyboard to fetch your mouse (or trackpad)?
• do you use “Alt + Tab”?
• do you switch to a different virtual desktop? (using the keyboard)?

When on Slack:

• do you use your mouse to select the person or channel you want to write to?
• do you use “Ctrl + K” (or “Cmd + K) to navigate there?

Try both approaches: with your mouse, and with your keyboard. How long does it take between the last character you typed in the editor and the first one you typed in Slack’s message input?

In this example, you might find that navigating to this new context without removing your fingers from the keyboard leads to a smoother experience. It removes friction.

When your brain thinks about asking on Slack, within a few keystrokes you’re ready to type your message, and a few keystrokes later you’re back in your text editor, ready to type the next line of code. Context switching has been reduced to its minimum, helping you to focus on the task at hand.

This is just an example of context switching, but be aware of it and you’ll see that it happens all day long:

• going back and forth between our code editor and our browser
• searching for information on the internet
• navigating in our emails or issue tracker
• committing our code changes and pushing them to the repository to open a Pull Request
• searching content in a file or a tree of files
• switching to a different project, or directory
• etc…

By rediscovering the keyboard shortcuts for each application you use, you can significantly reduce the time it takes to switch between contexts.

Most applications have a variety of keyboard shortcuts that allow you to navigate and perform actions quickly and efficiently. By taking the time to learn these shortcuts and incorporating them into your workflow, you can streamline your work and reduce friction throughout your day.

Why using your terminal more?​

I find it important to learn shortcuts for the applications you’re using the major part of your day.

For developers, these applications would be something like: a text editor, a browser, an instant messaging app and of course (don’t underestimate it) your operating system!

During your career, you’ll change the applications you use. Your team could switch from Slack to Teams, you’ll move away from WebStorm to VSCode, you change job and the new company uses Linear instead of Jira, Outlook instead of Gmail…

Every time, it will mean that you will have to learn new shortcuts again. These changes don’t occur very often, so it is acceptable. After all, you spend most of your day using these applications so the investment on learning how to use them efficiently is worth it.

There are however a lot of tasks (you may not yet realize it) you can perform outside those applications.

What if I told you that you can invest time in learning how to reduce friction:

• for your most common tasks
• in a way that is gradually adoptable in your current workflow
• with the ability to improve continuously without ever restarting from scratch
• … for the rest of your career (and your life)

This is exactly what your terminal allows.

You’ll be able to achieve a wide range of tasks thanks to the ecosystem of tools embracing a simple yet powerful philosophy: the Unix philosophy!

The Unix philosophy​

Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

The Unix philosophy is a set of guidelines that emphasizes simplicity, modularity, and the use of small, specialized tools that can be combined to perform complex tasks. It encourages the use of plain text for data storage and communication, and favors the use of pipes and filters to process data.

It offers a number of benefits:

• flexibility: text streams can be manipulated in many different ways. It removes the barrier of what you can do. You’ll be able to combine small simple programs together, in order to achieve exactly what you want to do, and make it more complex if needed. A “pipeline” of commands is also more resilient to changes: if data, source or process change you can adapt by changing only one “step”
• improved efficiency: automate things or find information by typing a command in your terminal is often faster than navigating in an application and going through several screens and forms
• greater control over your data: manipulating text allows you to interact with lots of systems and APIs, you’re not locked-in a specific vendor and can create bridges between most of your tools… as soon as you can get data in a textual format (i.e: output a list of files, get data from an API call, output Git history as text…)
• portability: these tools are widely available on different systems. Your skills and knowledge are valid in different contexts: you can use them on servers, on your current laptop… and the next ones.

By focusing on small, specialized tools that can be combined in different ways, you can tailor your daily environment to your specific needs and preferences.

Over time, you’ll bring new tools or change some of them without having to learn everything again.

You’ll improve your environment and adapt practices incrementally and continuously, as you make complex tasks easier to perform or automate repetitive processes. Weeks after weeks, you’ll work more efficiently.

OK, I’m sold! What’s next?​

Great! I’m glad that you want to reduce friction in your daily activities. I suggest that you start now, with baby steps.

Be aware of your hand position at every time, and learn to detect when your fingers are about to leave your keyboard. That’s the trigger!

Whenever this trigger occurs, stop and start asking yourself:

• what was I about to do?

• is it possible to achieve this without leaving the keyboard?

  • search in your application “Keyboard shortcuts” help page
  • search on internet
  • … or ask ChatGPT! Here is a prompt you can use as a base:

  I want you to act like a Unix user, and explain each tool individually.

  Q: how would you get the content from a JSON URL (https://dummyjson.com/users) and filter the first five "names" starting with a "S", sorting them alphabetically and outputting them as uppercased text in a file in the /tmp directory.

  A: let's think step by step

  After a few trial/errors you could end up with this one-liner:

  curl https://dummyjson.com/users | jq -r '.users[] | select(.lastName | startswith("S")) | .lastName' | sort | tr '[:lower:]' '[:upper:]' > /tmp/names.txt
  

• try to do it with a shortcut or a command, and note it down to try to remember it next time. You can also use cheat sheets (I personally started with physically printed cheat sheets on my desk!).

You’ll be surprised to see how many shortcuts exist in the tools you already use, and you will start discovering terminal commands or new programs

This article is already long enough. In a future article I’ll go through some of the shortcuts and commands I use on a daily (hourly?) basis.

Follow this space!

You have two options for installation: you can either follow the full installation guide, or you can refer to the best practices for setup, which includes a step-by-step setup guide and explains important concepts such as File Storage.

Install WSL (📑 docs)​

ℹ️ If you have already followed the full install guide, you can skip this step.

To install Ubuntu, open PowerShell or Windows Command Prompt in administrator mode by right-clicking and selecting "Run as administrator", then enter the wsl --install command.

After running the WSL install command and restarting, Ubuntu will be installed by default. You may change the distribution name by passing in a new name with the -d flag: wsl --install -d <Distribution Name>.

However, I suggest staying with Ubuntu. 🙂

Update and upgrade packages (📑 docs)​

When starting a new development project, updating your packages is always a good idea. After setting up your Unix account, you can simply run this one-liner to update the package manager:

sudo apt update && sudo apt upgrade

$ cat /etc/wsl.conf
  [network]
  generateResolvConf = false # disables auto generation of resolv config
  generateHosts = false # disables auto generation of hosts /etc/hosts

$ cat /etc/resolv.conf
  nameserver 1.1.1.1

sudo chattr -f +i /etc/resolv.conf

Set up Windows Terminal (📑 docs)​

You can install any terminal, but personally, I prefer using the Preview build because it ships features much faster than the normal version. For example, the GUI feature only arrived around a year later on the standard version, and I have never found it to be really stable.

To install, visit the Microsoft Store Apps for either:

• Windows Terminal Preview
• Windows Terminal

And as mentioned above, GUI is supported! That means you can run Linux GUI apps on WSL 😇

File storage (📑 docs)​

To open your WSL project in Windows File Explorer, enter: explorer.exe . Be sure to add the period at the end of the command to open the current directory.

Install Node.js on WSL (📑 docs)​

We will be using Node Version Manager (nvm). Follow these steps to install it on Ubuntu (or a similar distribution):

1. Open your command line.
2. Install cURL using the following command: sudo apt-get install curl. cURL is a tool used for downloading content from the internet in the command-line.
3. Go to the nvm repository and find the latest release.
4. Install nvm using the following command:

   curl -o- <https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh> | bash
   

Setting up your shell (Zsh + Oh My Zsh)​

This step is optional, but you may want to use Zsh and Oh My Zsh if you are looking for a more customizable and powerful shell experience.

Installing zsh​

To install zsh, open the Ubuntu app installed from the App Store and run the following command in the terminal:

sudo apt-get install zsh

Once it's installed, type zsh in the terminal. It will prompt you to choose some configuration options. We will do this later on while installing oh-my-zsh, so choose option 0 to create the config file and prevent this message from showing again.

Installing oh-my-zsh​

Before anything else, you need to have git installed on your system. You can install it by running the following command in a terminal:

sudo apt-get install git

After installing git, you can then use curl to install oh-my-zsh.

sh -c "$(curl -fsSL <https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh>)"

This command will clone the repository and replace the existing ~/.zshrc file with a template from oh-my-zsh.

Installing OhMyZsh Plugins​

We can supercharge our command line by adding some oh-my-zsh plugins. First, open the zsh config by running vim ~/.zshrc. Next, find the line plugins= and add the desired plugins.

plugins=(git nvm history zsh-autosuggestions jsontools command-not-found zsh-syntax-highlighting)

I have listed my favorite plugins here, but feel free to use your own set based on your needs. You can find a list of plugins here. Additionally, I use 3rd party plugins that must be pulled separately:

• https://github.com/zsh-users/zsh-autosuggestions (installation instructions)
• https://github.com/zsh-users/zsh-syntax-highlighting (installation instructions)

Enable NVM autoload in zsh​

Enabling the nvm autoload plugin allows you to use the appropriate node version based on the specifications in a .nvmrc file in any of your projects. This feature is especially helpful when working on multiple projects with different node versions, as it eliminates the need to switch between incompatible versions. With nvm autoload, you can easily switch between projects while ensuring you are using the correct node version.

zstyle ':omz:plugins:nvm' autoload yes

Useful gists for aliases​

To create an .aliases file in your home directory, run the command touch ~/.aliases. Then, ensure that it is sourced in your .zshrc file by adding source ~/.aliases to it.

Next, you can add the aliases and configurations used in the terminal by following the instructions in this link.

You will notice that there is an alias for npm. This is to detect which package manager to use by searching for the nearest lock file. An alternative to this is ni, which is highly recommended.

Git Credential Manager setup (📑 docs)​

The credential manager can assist with any HTTPS authentication, utilizing the Windows Credential Manager.

To download the latest version, visit the repository at https://github.com/GitCredentialManager/git-credential-manager/releases.

After installation and configuration, you should also add it to your Linux shell.

git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager-core.exe"

VSCode (📑 docs)​

To get started, download and install VSCode. Then, add the remote development extension.

That's it you should be ready to start developing in WSL.

alias code="/mnt/c/Users/%userprofile%/AppData/Local/Programs/Microsoft\ VS\ Code/bin/code"

Microsoft PowerToys: Utilities to customize Windows (📑 docs)​

As you're setting up your Windows development environment, you might be interested in exploring some of the additional tools available to you. One of my personal favorites are the Microsoft PowerToys, a set of utilities designed to help streamline and customize your Windows experience for greater productivity. Install Microsoft PowerToys to keep tweaking Windows!

Here are a few PowerToys features that I find particularly useful:

FancyZones​

If you want to easily manage the position of each application window on your Windows desktop, check out FancyZones. This tool allows you to customize the size and positioning of your snapping grid with efficient layouts that suit your needs.

Keyboard Manager​

With the PowerToys Keyboard Manager, you can redefine keys and shortcut combinations on your keyboard. For instance, you can swap the A key for the B key. You can also swap Ctrl + C for ⊞ Win + C. This will copy text when ⊞ Win + C is pressed. If no specific application is targeted in the PowerToys Keyboard Manager, the changes will apply globally across Windows.

File Explorer Preview Pane​

The Preview Pane is an existing feature in Windows File Explorer that lets you see a preview of a file's contents in the view's reading pane. PowerToys enhances this feature by adding support for multiple file extensions, including Markdown, SVG, PDF, and G-code. It also adds support for source code files with more than 150 file extensions.

ColorPicker​

This Windows color picker is a must-have tool for designers and themers. It allows you to easily select colors from any application and customize them to your liking. The interface is user-friendly and you can copy colors to your clipboard in different formats, including hexadecimal, RGB, and HSL. This tool simplifies color palette management and is lightweight. Download it today to improve your design work!

Text Extractor utility​

Text Extractor allows you to copy text from anywhere on your screen, including inside images or videos.

To activate the capture feature, use the shortcut (default: ⊞ Win + Shift +T). This will display an overlay on your screen. Click and hold your primary mouse button, then drag to capture the text. The captured text will be saved to your clipboard.

Run Utility​

PowerToys Run is a quick launcher for power users that includes additional features without sacrificing performance. It is open source and modular, allowing for additional plugins to be added.

To use PowerToys Run, simply press Alt + Space and start typing!

Enable ‘God Mode’​

God Mode will give you access to all of Windows’ control panels from one folder. To enable it right-click on the desktop and select New > Folder. Re-name the new folder with this bit of code:

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

Sharing SSH keys between Windows and WSL 2 (📑 docs)​

1. If you have setup ssh in windows you can copy it to your linux

   cp -r /mnt/c/Users/<username>/.ssh ~/.ssh
   

2. Fix the permissions

   chmod 600 ~/.ssh/id_rsa
   

3. Add keychain to linux

   sudo apt install keychain
   

4. Run the keychain every time you start a shell instance, you can append this to the top of your .zshrc file.

   eval ``keychain  --quiet --eval --agents ssh id_ed25519
   command clear # this is why we add it to the top so that we can still se other outputs, I have not yet found a better way of silencing the keychain export messages
   

Conclusion​

You have just learned how to set up WSL on your Windows machine and create a powerful and efficient development environment. By following this guide, you have installed WSL and updated packages, set up Windows Terminal and installed Node.js and Git. These tools will help you code faster, easier, and more securely.

🥳 Congratulations on completing this guide! We hope you enjoyed it and found it useful. If you want to learn more about other topics related to development, stay tuned as our blog will be growing!

Three targets: developers, merchants and customers​

The first challenge is not really technical. As stated in the introduction, we try to address three main personas:

• the developers integrating our solution to create an online store for…
• a merchant willing to sell something to…
• a customer seeking a product.

Anybody having at least a small experience as a software editor knows that properly addressing one persona can already be challenging, so you can guess what it is like with three, even if they don’t necessarily want opposing features, more targets mean more constraints.

Let’s take a deliberately extreme example 😃 They all want a performant store.

The customer:

I want a performant and great shopping experience even in the middle of nowhere with a low to average 3G connection.

The merchant:

Can I have a great shopping experience for my customers? And also, I want to put very high quality photos and videos online. In addition, I want my pages to be always highly up to date with customer specific and very dynamic content. And next Friday is Black Friday! The website needs to scale, it’s the biggest selling event of the year.

The developers:

The merchant wants a performant and scalable website. Is your software doing that out of the box or can it be done by turning on a setting?

I guess you get the idea, each target adds a set of constraints. It’s no surprise that pleasing everyone is difficult but it’s also a stimulating challenge.

Extensibility​

As a software meant to be integrated by developers, Front-Commerce needs to be extensible so that it can serve different use cases. The most obvious reason is that each merchant wants its own customized store implementing a dedicated shopping experience.

In addition, each project needs a specific set of features and while we try to support as many as possible out of the box, having an extensible architecture allows the developers to fill the gaps. As far as I’m concerned, it’s always a pleasure to see very unexpected or specific features nicely implemented even if I would never have imagined it could exist.

It’s also worth mentioning that in the world of composable architectures and headless commerce, extensibility is a key feature.

Backwards compatibility and upgradability​

Being able to implement a project is nice but that’s only the very beginning of the story. At some point, new features and fixes for bugs will be needed. The challenge here is to be able to deliver those without breaking anything.

On a practical level, that means we try to follow semantic versioning by regularly providing patch releases containing only bug fixes and every six weeks, we release a minor version with new features. Those minor versions always have a migration guide to make the upgrade process as frictionless as possible. And what about a major version? In the last couple of years, we have not released any, but I’ve heard that something is cooking 😇

In the code, this has a quite deep impact. When changing code, we have to keep in mind both existing projects using our software and new ones. We also have to think about how APIs are being used before we can make any changes to them. This forces us to carefully encapsulate our API’s to reduce their surface as much as possible. This has a tendency to limit the extensibility and the versatility so as usual when it comes to code, the key is to find the right trade-off.

Anything else?​

Oh yeah, I could have approached the support, the documentation, the developer experience or the dependency management to name a few. This will probably be the subject of another post…

In any case, all this is a part of the context in which we build Front-Commerce and where we try find the best solutions or trade-off. As usual when it comes to our product, we are always seeking feedback, so don’t hesitate to contact us if you have any remarks or comments. This can only make the product better.