Volto on local network

21

And another reply, in the interest of having a more complete explanation.

The problem with RAZZLE_API_PATH and RAZZLE_INTERNAL_API_PATH is that they are supposed to be used by the Volto application, which is a static bundle produced by a compiler. Which means you're supposed to build your bundle (yarn build) with those variables in the environment. The Dockerfile for old Volto solves this by producing bundles with a hardcoded API_PATH (set to VOLTO_API_PATH) and then dynamically sed replacing those variables in the docker entrypoint.

With the seamless setup, this sort of thing is no longer needed, except for the development, if you use a non-standard setup.

1 Like
22

Keep in mind that Mosaic frontend is gone in Plone6

23

Are you sure, I updated my theme 'some time ago' to Plone 6, and that worked at that time (and it is based on Mosiac). Currently, my plan was to update it to volto (I have about 100 different blocks, but I started porting them to wordpress instead).

24

When even developers who are using Plone and love Plone since years feel kind of frustrated when confronted with Volto ...
... I am afraid that in the short/mid run Volto will have some difficulties to attract new users.

If Volto wants to compete in a market where other vendors are offering ready to use features like one page sites, blocks, page builders etc. Volto must be better and easier to configure than the competitors.

I do believe in Plone (and in Volto). But the question is how to attract new adepts?

25

Developing with Volto is a whole other paradigm, there will be pain and frustration because some things that worked with Plone Classic no longer are valid for Volto. I totally understand that.

For the Plone companies that do a lot of "bigger" projects, Volto is a winning proposition. It's a lot easier to train frontend React developers to pick up Volto, because React. And the frontend developers, when coming from that camp, are used to these sort of problems: CORS headers, configuring a way to access the backend, etc. So, if you want your company to "scale" in terms of developers while doing Plone, you do Volto.

26

scale up from 1 person, you mean :slight_smile:

2 Likes
27

Problems that was already mostly solved with one line on Apache or Nginx. But we are moving in a different world, where frontends are ephemeral and backend last for long time. So I agree we must know this technologies to catch up but a lot of problem can be easily solved with a batteries included CMS.

I think some docs are just missing but maybe some people can't wait if they have to solve problems day by day.

28

I meant it in general. I'm actually a big supporter of "standalone Plone developer", I think that should be a viable model for Plone.

29

Being able to solve the CORS problems with an NGINX line is easy, if you understand the problem.

The CORS problem is everywhere there is a frontend / backend separation. For example, I've been working on implementing something with Medusa and look, cors issue

And Volto has details on CORS, there's this bit of documentation in the Volto docs.

30

This gets us back to a very fundamental question: How "big" must a Volto project be to be attractive in terms of project profitability?

31

It depends on the website and how experienced you are developing with Volto. The first website will take more to build. If we take the Volto addons into consideration, then the math skews in Volto's favour, because stuff that you needed to code, you can just build it through the web, as content. You have:

  • accordions
  • tabs
  • columns
  • sliders
  • carousels
  • cards

and so on. On top of that, it will be easier to integrate other React libraries. Not every React library makes sense to integrate, for example you wouldn't do Material Design on top of Volto's Semantic-UI, etc.

32

@tiberiuichim: Thanks for your comments.

Actually Volto/React do not worry me. I am more concerned with the complexity and the costs of the architecture behind.

With Plone Classic UI we can easily put 20-30 Sites (of small magnitude and traffic) in a single Plone instance. Configure apache/nginix and a backup strategy and you are done. The costs for administrator and service provider are quite manageable.

With Volto we need at least 20-30 backend instances and 20-30 frontend instances. Or (possibly) 20-30 frontend configured to a single backend instance. This increases the costs for administration and service provider a lot.

This is the reason why we still stay with Plone Classic (with static React bundles if necessary).

33

With Volto we need at least 20-30 backend instances

One backend is fine.

The frontend will be a problem, indeed.

34

having to install apache on nginx just to test some add-ons seems 'a bit much', setting up a 5.2 site takes 'minutes'.

My plan (as in the initial question) was to set up a local (ubuntu) server at home and use that to update / port my themes to Plone 6 and/or Volto.
I was supposed to have an operation today (but the hospital called a few hours before and postponed it 'indefinitely' ) for some injury I got playing football (soccer), so I thought that would be 'something I could work on since I would be stuck anyway'.

35

For Mosaic, I have about 100 different. Even without much knowledge about Wordpress, it is not too much effort making those into 'blocks', but doing the same with volto requiers me to learn 'a bunch of new stuff'.

36

Then don't do Volto. As far as I know, Plone Classic is supposed to stay a viable way of developing with Plone.

37

If you are working with containers the overhead is not that large. Initially it is some work, but once setup and automated: it is some edits and clicks to setup a new site - and it does not matter if there are 2, 20 or hundreds of sites. I.e. I am currently experimenting with a setup with Kubernetes (small Rancher K3S based cluster with Traefik Ingress), custom Helm charts and Gitlab CI to automate the process.

I do not know if it helds in future, but at the moment I would say this way feels very OK.

38

@espenmn: If I understand your use case right you don't need all Plone sites running at the same time.

I'd suggest to try the following:

  • Install as many backends and frontends as docker containers as you need every with a different port (e.g. backend 808x and frontend 300x). No apache/nginx needed.
  • start only the backend and frontend you currently need and stop it when you're done.

With the following command you could install up to 10 instances in 5 Min.
The first backend and frontend containers will take longer because it must download the images.
The next containers will be created on the fly!

MY_IP=10.0.0.123
for i in {0..9}; do \
    sudo docker run \
        --name mybackend${i} \
        -e SITE=Plone${i} \
        -e CORS_ALLOW_ORIGIN='*' \
        -d \
        -p 808${i}:8080 \
        plone/plone-backend:6.0;
    sudo docker run \
        --name myfrontend${i} \
        --link mybackend${i}:backend \
        -e RAZZLE_DEV_PROXY_API_PATH=http://${MY_IP}:808${i}/Plone${i} \
        -d \
        -p 300${i}:3000 \
        plone/plone-frontend:latest;
    #sudo docker stop myfrontend${i};
    #sudo docker stop mybackend${i};
done;
sudo docker ps -a;

Here some usefull commands:

sudo docker start myfrontend1
sudo docker stop myfrontend1
sudo docker rm myfrontend1
sudo docker ps -a
sudo docker exec -it myfrontend1 bash

This could be optimized with docker compose. But I wanted to keep if simple for the start.

Update: I fully agree with @jensens :

39

@jensens Thanks for your comments. I do know that this way feels OK. But I'm not sure I'm production ready with Volto. I feel more confortable offering Classic UI to our customers. I'm very confident that this will change. But I'm not yet there.

1 Like