Feedback from a non JS person

Feedback
#1

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.

#2

Iā€™m going to guess Strapi Team reads this feedback but to help with containersation. Even for a NON JS person.

I wrote a CLI tool for strapi to be used.

npx @strapi-community/dockerize

Answer a few questions and voila itā€™s containerized

So should be simple enough to help with that :slight_smile:

#3

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.

#4

@Shaun_Brown :point_up_2: Flagging for visibility.

@Roger
So I see what you mean hence why I flagged it for the strapi team. :slight_smile:

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.

#5

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.

#6

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.

Anyways Iā€™ll let strapi read the feedback

#7

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.

#8

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.

  1. Creating a project is done with ā€œcreate-strapi-appā€
    The syntax actually differs between npm and yarn, which are 2 different JavaScript packages manager :sweat_smile:.
    On top of that, you can add different flags to adapt the installation behavior.

  2. 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! :blush:

Your feedback was also passed on to the engineering team.

1 Like
#9

Hi,

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.

Thanks for your time

Roger

#10

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 :slight_smile: