We intend to use Strapi as an API generator for our data model, and intend to iterate on this data model.
I’d like to know how iterations on the data model configuration, are best version controlled, and how a content-type-configured Strapi is easiest shared with coworkers.
Ideally, a central configuration file would exist, in which the content types (and their relationships) are configured, rather than the entire API endpoint JS code tree being the canonical place where this is represented. The best example of such a single file would be the GraphQL export schema.graphql that appears to be generated by the graphql plugin. If such a central definition file already exists, I’d love to know about it. This would allow us to develop our data model through code, document changes to it in Git, instead of managing changes through the admin panel.
Now I’ve seen the templates feature, but it appears to require that we, a private company, publish our template on a public GitHub repo.
I’ll admit I was slightly confused by the beginning part of this question, if you could clarify your purpose a bit that would be great.
Depending on your OS and how it interacts with Git (for authentication) it should also work for private repos but yes the intent was to publish public templates and build out a large ecosystem of open-source templates.
All I’m trying to do actually is to be able to version and collaborate on the content type configuration. Turns out that is easily possible simply because ./api/[content-type]/models/[content-type].settings.json is written by Strapi, which can be shared and version controlled.
As for collaborating on, distributing, and versioning some default content, turns out config/functions/bootstrap.js can be used to write a script that fills the database with seed data: Generate fake data - YouTube
Ah yup exactly, that’s why I was slightly confused because we try to allow for as much source-control as possible.
For the content-type manager plugin’s “views” we also have the following commands to dump the core_store table to a json file (and allow various “recovery” methods)