Documentation

Decisions to consider

Before setting up your commercetools Frontend projects, you need to take some decisions. For example, deciding on the number of projects or whether or not to use a store launchpad as a template for your website.

Following are the main points you should take into consideration.

Number of projects

Defining the number of commercetools Frontend projects is one of the main decisions to consider. The number of projects varies depending on your technical and organizational needs.

For example, if you only have one website for one locale the decision is easy as you only need one project. However, if you have one website for different locales, different websites for different locales, or different websites for different brands, you need to evaluate your project setup.

The decision depends on how you want your website to work and how your team will be organized to manage the website with the Studio.

With commercetools Frontend, two project setups are possible. Let's take the scenario of different locales as an example, in this case the setups are the following:

  • One project for different locales: all data is shared, this includes Studio users, pages, and navigation structure.
  • Multiple projects for different locales: projects can be either completely separate from each other or be synchronized to share some data sets.

Let's look at the setups in more detail.

One project

With one project serving multiple locales for your website, different locales will share the same data (for example, navigation structure, pages, and Frontend components). Also, Studio users will be allowed to manage the website for all locales.

To manage multiple locales with this project setup, you need to manage the locales and translations from the Studio.

Multiple projects

Another option to manage multiple locales is to have one project for each locale. This setup gives you more flexibility, however, you will have to manage and update each project individually, which could cause more work for your team.

To reduce work, you can synchronize projects to share data sets among them. Project synchronization can be continuous or one-time.

For example, let's say you have a world-wide website using the English locale and a Swiss site using the German, French, and Italian locales. In such a case, you could choose different setups.
One option could be to have one project for each locale, therefore, four projects. Another option could be to have one project for the website using the English locale and one project for the Swiss site using the German, French, and Italian locales.
For both options, for example, you could synchronize the navigation tree across the projects and have different pages within each project.

Data sharing between projects

If you have multiple commercetools Frontend projects, you can synchronize projects to share data among them and reduce the update and management time.

If you have three or more projects you can decide which ones to synchronize. For example, if you have projects A, B, and C, you can synchronize projects A and B and keep C as a separate project that is not synchronized.

You can opt for a continuous synchronization to keep shared data sets aligned among your projects, or a one-time synchronization to share specific data among projects and then manage projects separately.

Project synchronization is bidirectional, you cannot set one-way synchronization from one project to one or more projects. All synchronized projects have the same data for the shared data sets.

You can choose which of the following data sets to share among synchronized projects:

  • Studio users
  • Pages and navigation structure. This includes dynamic pages, page templates, and component groups. Page templates depend on page versions and navigation structure; if you share page versions and navigation structure, page templates are shared too and vice versa.
  • Frontend components

When sharing data, the entire data set is shared among synchronized projects. For example, when sharing users between projects all users will be shared, you cannot share only specific users.

To avoid issues, media assets and redirects are also shared among synchronized projects as they are related to the previous data sets.

You can also share the code between projects if you want to.

Which approach is better?

It is up to you to decide which approach best suits your needs as it also depends on your organizational structure.

For example, let's say you have two websites for two different locales. If each website is managed by different teams, you might consider having two projects that are not synchronized.
On the other hand, if the same team manages the websites and/or the structure of the sites is similar, it might make sense to have either one project with multiple locales or two synchronized projects. However, if the same team manages the websites but the structure of the sites is completely different, you might want to have two projects that are not synchronized.

If your circumstances change, you can switch to a different setup. For example, if you start with one project but then realize that it doesn't fit your needs, we can support you to switch to a multiple project setup.

On this page, we used the multiple locale scenario as an example. However, the reasoning applies to other similar cases, for example a multiple brands scenario.

Store launchpads

commercetools Frontend comes with out-of-the-box store launchpads to reduce development effort when building your digital commerce website.

The Store Launchpad for B2C Retail and the Store Launchpad for B2B Manufacturing are designed according to digital commerce UX and UI best practices. You can use them as a model when developing your B2C or B2B commerce website.

Extension library

commercetools Frontend comes with an out-of-the-box extension to integrate with Composable Commerce and with extensions to integrate with third-party services. You can also develop extensions to meet your needs.

Creating the navigation structure for your website is a complex decision that should be carefully considered. Our store launchpads come with an idea of how to model a website's navigation. You can use that structure as a starting point and adapt it to your needs.

Content management

Content management and delivery is another pivotal consideration before set up your commercetools Frontend projects. Depending on your needs, we recommend considering whether to use a headless CMS together with commercetools Frontend.

Supported browsers

To provide the best support for frontend delivery, commercetools Frontend only supports up to the latest versions of the following browsers:

  • Microsoft Edge
  • Google Chrome
  • Mozilla Firefox
  • Safari

Code languages

Our primary framework for commercetools Frontend is Next.js, which is React-based and allows for efficient server-side rendering and static site generation. Next.js allows us to use component-based architecture that facilitates a modular codebase.

We use TypeScript for frontend components and backend extensions. As TypeScript is statically typed, it improves code quality, reduces errors, and boosts developer productivity with great tool support.

commercetools Frontend provides a cohesive development experience while adhering to industry best practices and community standards. This approach ensures that our codebase remains accessible to developers familiar with modern web development patterns.

For more information, see our architecture and stack and our coding guide.

Moving to commercetools Frontend

If you're switching to commercetools Frontend from an existing solution, see Moving to commercetools Frontend for more information.

Want to know more?

You can sign up for a guided demo to discover more on commercetools Frontend.