Hi BackendLess Team!
I am using File Uploader Button for users to capture and then store image.
What I made by mistake is storing them under (Root)/web/images. That resulted in loosing images after each deploy, since (Root)/ui-builder/containers/(containerName)/images does not have any images stored and it overwrites the web folder on deployment.
What is the best approach from following two:
- storing images in (Root)/ui-builder/containers/(containerName)/images;
- storing images alongside (Root)/web, i.e.(Root)/images;
Any pros and cons between these two options?
Any better suggestion?
Any documentation on deployments, to better understand what to consider and what is affected when publishing new app version?
Also unrelated to main topic, but how would one track changes made in UI builder between live and development version? Currently it seems that it would be be beneficial to have multiple containers, where one is the live app container which is then duplicated to development container, which is then being developed and tested under some other subdomain, and when ready for live, it would need to be copied over to previous “live” container.
Best Regards,
Uldis
Both variants are applicable.
- saving files in a container dir will isolate content for each container;
- storing files outside the
web dir makes your ui-builder containers more lightweight, decrease the redeploy time, the content will survive redeploy and even full clean of container, gives you the shorter and simpler path for files. But if it is need to have several different versions of the same content, you will have to manage it by yourself, e.g. you may want to have a subset of the files for testing. And if to look from the other side – the several containers can share the same static info, which decrease the space usage and as a result allows the server to work more optimally with files.
Аs for the second question, I’ll consult with the team to gather more information about best practice and answer later.
Thank you for the insight, really useful thoughts!
About your second question:
- there is no need to create a separate container for development since all changes go to production only after publishing the container;
- however, if you have more complex structure with several steps (e.g. master/stage/dev/test/etc.) it may sense, although this is a rare case
@oleg-vyalyh Understood the idea.
I think, when pushing small increments to production this is no issue, as it would should be easily traceable what break the system. But when creating more complex changes that would benefit of separate stages, probably also a backup (that is already present) to roll back bad changes.
Additional question, is there any way to see or compare changes made in container (Ui, and logic) before pushing them to production? This would be beneficial in previously mentioned complex updates.
Also, what does Manage > Sync Changes do?
You can only save it locally and compare the changes with the diff tool. That’s the only way for now.
Sync the changes of the current application to another one.
Is there any documentation or video about that sync changes? What would be use case for it?
From what it sounds, looks like it could be also used to maintain production app and development app, only in this case it would be across multiple apps, not containers.
It is described quite straightforward
Select the target application. Select changes from the current application will be deployed to the target application. Once a target is selected, we will analyze the differences and you will be able to choose which should be deployed.
You must have another application for this procedure. Just try it once to understand how it works.
But keep in mind, that if to talk about business logic then only Codless logic can be migrated. For other logic (which is published from the coderunners js/java) you have to keep in by yourself somewhere.
1 Like
Thank you @oleg-vyalyh
Resolving topic.