Decisions to consider
Before setting up your projects, there are some decisions you'll need to make.
There are 3 main decisions you'll need to make before creating your projects:
- How many projects will you have, and which languages will they include
- Will you be using the extension library and the Frontend component library or starting from scratch
- How will your navigation be structured
Let's go through each now.
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.
If you start with 1 project and find it's not working the way you want it to, you can always create another.
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:
- 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.
Data is synchronized bi-directionally. So you can't have certain Frontend components synced from 1 project and then add unique Frontend components to that project, as they'll be synced back to the other project. Or if your users are synced, you can't have certain users for 1 project, they'll have access to all your projects.
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.
Frontend component library
The Frontend component library covers the most common commerce cases, so you might want to start building your commerce site based on them. See using the Frontend component library for more information.
The extension library is available to connect your Frontend components to your backend. You can copy our commercetools extension from the library into your project, and then adapt it to your needs. See the using the commercetools extension article for more information.
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:
All other browsers aren't supported.
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.
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.