While a small company we have got to the point of re-evaluating some of the original product choices made at the start of our project and the current CMS has come rather high on the list as the current system does not really provide any SLA or backup strategy. Strapi very quickly became the solution to look at as the replacement as being able to deploy as part of our current product stack gives it the same SLA rating as everything else we are doing and its use of a general relational database resolves the backup strategy issues.
Now the feedback. - Iām not a JS developer and have no real understanding of the JS, JT ecosystem, But that should not be an issue as I am interested in Strapi because of its ability to provide a CMS solution not how it is built. Just in the same way that I do not worry about say MariaDBās or Redisās development/build environments.What, I am is someone who deploys CI pipelines and system stacks. For the mentioned MariaDB and Redis solutions, this is easy as they support containerisation as standard. Strapi on the other hand seems to have decided for V4.x that containerisation is an end-user problem.
I can say for certain that it truly is an end-user problem as this end-user has already noted does not know (or care much) about the JS/JT ecosystem. Such a situation seems to restrict Strapi to just JS based teams as most other people doing a quick eval are likely to move on when they find the message āStrapi does not build any official container images.ā within the docs.
As it is the EOY I have the time to fight with all this environmental setup and I personally believe that Strapi is worth the work to look at, but Iām not sure as a business you could have made it less friendly to environments that operate around the container deployment model.
Roger
P.S. If I do create anything that is sharable Iāll do so as it could help the next person who falls down this rabbit hole, but so far Iāve nothing of value - beyond at least having an understanding about how much I do not know.
Yes, Iāve already started to build my plans around that so thanks.
In part, your contribution is the reason for my post - you have extended the ecosystem to try and cover a missing part of the offering, but to use your work Iām having to first still understand the ecosystem.
I can give a simple example, by just following the docs from the Installation page under Setup & Deployment section.
The page gives me 2 options of CLI or Docker, but the Docker option is noted as creating a customer Docker container from a local project and as I do not yet have a local project it is not a valid option. So CLI is my only choice even if 2 were provided.
After some basic notes I reach a section titled āCreating a Strapi projectā which talks about cli switches, but I need to go to another page to find out about the actual cli command. Normally documentation starts with the command and then details the switches.
The new page seems designed to test to see if I read everything on a page as you have to read the provided note to find out that the examples provided need to be prefixed with the correct npm/yarn command (thatās nice, now remember I know nothing about the JS ecosystem so that info does not really help).
Well I managed to create a valid ecosystem, shame that the ubuntu/debian universe seems to have spent at least 5 years arguing with the yarn team, so all I need to do now is just run ānpm run strapi new projectā to get a basic setup as that is what the page indicatesā¦ Even I can tell that thatās not going to work as strapi is unlikely to be part of the core js ecosystem I have managed to deploy and guess what it does not.
So back to the install page and onto the next section. Well, I have no idea what npx is but the whole line has the look of a package installer. So lets run it with some general values and yes it does an install. Now, letās run it with some different options as getting dropped into a different shell of some type, while a browser is opened up is not that helpful.
I now have a directory, which I can now execute ānpm run strapi new projectā in and I would guess your project.
It was at this point I decided to write my post as it was clear that JS/JT experts have basically created and documented a whole project that is aimed at JS/JT experts and that by accident (or design) excluding everyone else is not the best of ideas. Tomorrow I will continue this game of discovery.
@Roger
So I see what you mean hence why I flagged it for the strapi team.
I think that the reason I extended is is that you canāt have a docker image to cover all the basis of Strapi, because every time you create an API or collection, you still have files that is written to the system.
So if you are going in container mode, where do you store the files, next time you reboot itās all gone, unless you of course bind the folders etc.
While I know little about JS, I am aware of one complication it brings to the docker world, that of environment variable values being placed into the code as the application is built. The result is a lot more content than must be connected to the docker container, rather than held in the container. I would guess that the strapi team are trying to avoid this complication.
The thing is that this is not hard to deal with once you have the underlying toolset - you just have the CI system create dedicated containers for each target environment. I already do this for another JS based container, with the end result being a dedicated container for each of my DEV, TEST, DEMO, STAGING, and PRODUCTION targets.
Once I have even a basic understanding of what I am doing I should be able to take the output from your tool and the examples in the docs and get a CI driven build running, but others in my position may instead just switch to their next CMS choice.
At the moment Iām expecting to end up with very few volumes connected to the container as .env will be handled by a secret manager and /src, package.json and yarn.lock will be within the container so that they do not change. There is little point in having a CI process if someone can add modules or do updates at different stages of the pipeline.
Iām aware how it works.
Actually you want the customizablity over hard coded containers.
Again each time you create a new api in a container you will get a new folder with about 5 files. So you would need to bind it to somewhere.
For now, the plan will be to have a master system that is then used as the working image for all the targets. So all deployments of Strapi apart from the single master system are just R/O images.
Our use of a CMS system is for the underlying framework of our business platform, rather than the dynamic content, which is provided by our business application.
Thank you for the feedback, @Roger. Itās really precious.
Iām Pierre, Lead Technical Writer at Strapi.
We would rethink this installation page, and most notably move the āCLI installation optionsā further down as it creates confusion.
You actually donāt have to go to the CLI reference page to install Strapi, or to run a project.
Creating a project is done with ācreate-strapi-appā
The syntax actually differs between npm and yarn, which are 2 different JavaScript packages manager .
On top of that, you can add different flags to adapt the installation behavior.
Running a project is done with ādevelopā.
But the exact syntax, again, depends on the package manager (npm or yarn), or if you decided to install the strapi package globally or locally.
The JS ecosystem can be pretty harsh indeed, and weāll do our best to make devs life easier, so if you have other useful feedback, please keep it coming. Thank you!
Your feedback was also passed on to the engineering team.
As you may have guessed my post was written to get a response and to get a few people to read what has been published and consider it from the point of view of a newbie trying to use your product. So that now seems to be a work in progress and I could not really ask for more.
Iām aware of the flags/switches for ācreate-strapi-appā, but only because Iām happy to install an unknown product and have stuck āāhelpā on the end of the install command to see what would happen. Having seen the list of options (late last night), I think I understand the issue
The āCLI installation optionsā section on the āPreparing the installationā page may have started out describing some of the available switches for ācreate-strapi-appā, but then got linked to the āstrapiā CLI tool as they do share the same options. The result is that ācreate-strapi-appā is now undocumented within the docs. Knowing about these flags and switches is rather key if you want to automate a deployment within a CI system.
An added complication for anyone following this thread is that it seems that currently, the command line switches for the latest release of ācreate-strapi-appā are broken.
https://github.com/strapi/strapi/issues/15101
This does show firstly the advantage of very clear and concise docs, Iāve just spent time trying to understand why things were not working ask expected as I try and understand what the docs are trying to explain, in the end, I went and visited the code repo to see if I could find the problem with my script. Secondly - never let anyone set a deadline for R&D work
Flagging for visibility.
.