Decisions to consider

Number of projects

Before starting any kind of development, your business will need to decide how you want your project to work.

If you only have 1 site in 1 language, then you only need 1 project. But if you have 1 site in many languages, different sites for different locales, or multiple brands, you'll need to decide how you want to set this up and if you want to share any data across your projects.

So how do you make that decision? It basically depends on how you want your site to work and how your team will be working with the Studio.

There are 2 options:

• One project with multiple languages — All data is shared. This includes users, pages, navigation tree. Only translatable fields will be changed depending on the locale.
• Multiple projects — Can be completely separate when no data is shared or can have some data sets synced so can give you more flexibility to have differences between your projects.

Let's look at the options in more detail.

One project You can have 1 project that serves all your languages. Everything will be shared, such as navigation, pages, Frontend components, as well as access to the Studio. You'll only need to edit the translations per territory or per language depending on which you prefer, these translations can be managed using the Studio.

Multiple projects Another option is to have a single project for each language, for example, 1 project for English, 1 project for French, 1 project for German, and so on. But this means that each project will need to be updated individually, which could cause extra work for your team. Some data can be shared across the projects using our synchronization mechanism and we can specify which data sets are synchronized. For example, you can synchronize all Frontend components, page versions, and page folders. Or you could opt for a 1-off synchronization to copy all the data from 1 project to the other, and then remove the sync so page versions and page folders can be edited separately in each project.

You can also create a combination of the 2. You could have a single project for English, then another project for a Swiss site that then has multiple languages, like German, French, and Italian. Then the navigation tree could be synchronized across the 2 projects but they have different pages within each project.

If you had multiple brands rather than multiple languages that you want to create sites for, it would be a similar decision. If they had a similar site structure, but with different content, you could create a project for each brand and then sync the page folder structure, and edit the pages separately. But if they're completely different, it would make sense to have different projects with no syncing.

But if you're not sharing much between the projects, there will be a higher manual effort than managing 1 project with multiple locales.

Data sync The below data can be synced between different projects:

• Users
• Pages and page structure (navigation tree) as well as dynamic pages, page templates, and component groups
• Frontend components

Media, facets, and redirects are also synced as they're linked to the above list so if we didn't sync them, this would create issues. This is also the case with page templates, if you choose not to sync pages and page structure, page templates will also not be synced.

You can decide on which properties you want to share between the projects, but we currently only support synchronizing entire sets of entities. For example, all page folders (the navigation tree) and users can be synchronized, you can't select some. We can always copy the data initially for a new project that's based on an existing project so you don't have to start from scratch.

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

If you have 3 or more projects, you could even have 2 projects that are synced and 1 that's completely separate and not synced at all.

Which approach is better? It's actually up to you to which approach better fits your needs. It also depends on your internal structure, for example, if you want to have different teams working on different projects it might make sense to have 2 separate projects but if you have 1 team working within the Studio and the structure of your site is the same, it might make more sense to have 1 project with multiple locales or use the syncing option across your projects.

If you want your locales to have entirely different structures, pages, or content, then you should go with a separate project approach with no syncing.

But if the structure is mostly the same, it might make sense to use the approach to add a new locale to the existing project as the management overhead will be quite small.

The main thing to know though is that you can change your mind. If you start with 1 project but find that it doesn't fit your needs, we can work with you to switch to a multiple project setup. Or if you want to launch a new locale, territory, or brand, you can set these up at any time, contact our Support team and they'll be happy to help.

Store launchpad

The Store Launchpad for B2C is designed according to digital commerce UX and UI best practices. You can use it as a model when developing your B2C commerce website.

Extension library

The extension library is available to connect your Frontend components to your backend. You can copy our Composable Commerce extension from the library into your project, and then adapt it to your needs

Navigation structure

Creating navigation can be very complicated, and decisions around its structure shouldn't be taken lightly.

commercetools Frontend doesn't provide you with a mandatory way to structure your site navigation. Instead, you're free to implement it in a Frontend component specifically to your needs.

Supported browsers

As there are many browsers and many versions of those browsers, it's difficult to support them all in terms of frontend delivery. So we've decided to limit the browsers that we support to the latest versions of the list below:

• Edge
• Chrome
• Firefox
• Safari

All other browsers aren't supported.

Code languages

Most of our code is built using ReactJS for the smoothest user experience and easy component development. If you're new to ReactJS, let us know, and we'll be happy to help.

We currently use TypeScript for all extensions.

commercetools Frontend provides a unified development experience across all code areas while sticking to community standards as much as possible.

See the coding guide and the architecture and stack article for more information.

Moving to commercetools Frontend?

If you're skeptical about moving to commercetools Frontend from an existing solution, our moving to commercetools Frontend article will answer most of your questions.