Skip to main content

Having done multiple implementations on the commercetools (CoFE+CoCo) platform and also using the old setup vs the new and improved Multitenant option -- we always have this question as to where do we keep this config - project.yml (old setup), studio config (project level or tastic or datasource config), custom object in commercetools or any other option. 

There is always this confusion around whether we should use one area vs other? Will it be good to manage if everything is in one place ? Studio is a business user tool, should we have only what they have to edit there as against any other service configurations - search (algolia) config / cms (amplience/contentful/contentstack) config / internal payment systems config / etc., How do we manage UI labels / success or error messages etc., 

If we add the config to frontastic studio config -- its sent in the call to controller via the actionContext in every call - invariably of whether the config is needed for the call or not -- which means its present in the data transfer making it loaded -- also even if you grab the data and cache it in a redis or nodecache (local to the apihub pod) -- there is no way to tell CT to not send it in every controller request but do it only if its changed. If the configs are present in custom object you can make a single call to CT get the data cache it and use it how many ever times you want without having to load studio config (context). 

What are your thoughts? How are you solving the config problem in your project? Ideas/suggestions ?

 

-Naga

Very good insights and I found myself with similar doubts.

For me it depends on the context of the configuration I need:

Type of config Mgmt/Storage
API Keys and other values used by connectors
(e.g. payment provider, mail service, search engine, etc..)		 Project schema, under the connector name, and credentials are stored using encrypted field type.
This seems standard with the way existing connectors are build and make it easy to manage in Studio per environment.
Global project settings A new entry in the project schema where store everything that is global and may need to be changed, this can include things like a placeholder image, a fallback SEO image, etc..
Microcopy (e.g. for success messages, labels, etc. and including translations)

I would like to use Studio for this but it’s not possible, so typically rely on a 3rd party service or on json files in the frontend.

I think this could be a nice improvement in Studio, the ability to have a singleton composed by an array of translatable key/value entries.
Page specific settings
(e.g. extra seo fields or other metadata)		 Defined in the page folder schema, so it can be managed directly on each page.

 

I’m not against using custom objects to store such values, I understand the performance aspect (although it seems marginal to me), but from a separation of concerns perspective I don’t feel it’s the right place. 

Reply


Terms & ConditionsCookie settings