Deploying to Platform.sh

Hey @giorgiocba ,

Are you on Windows OS? Hm, instead of dealing with the ucsto PATH config it might be so that you need to install the Platform.sh CLI in an official way first: https://docs.platform.sh/administration/cli.html . I bet if you get that installed properly first, then symfony cloud:project:create also should work well for you.

But I would recommend you using WSL with a native Linux installation, then such commands should work much stable. I've never executed those on Windows, so it's hard to tell what else you can do.

I hope that helps!

Cheers!

Thank you very much for your suggestion. I'm actually running Windows 10, but I have WSL installed. I'll try the deployment again now.

Yeah, on WSL it should do the installation of the Platform.sh CLI in the background without problems or needed changes.

Cheers!

Hey @Manuel-B!

Sorry for my slow reply!

Is there any way to cache the build, maybe by using a mount?

You should try Asset Mapper ;). But to actually answer your question, the last time I asked this, no, there wasn't a built-in "build cache". But, it would be worth asking them again via support or on their Slack channel.

I agree with you that the Webpack builds on deploy can be annoying (and funnily enough, I know that platform.sh doesn't like them either - it takes resources, so everyone would be better off if they were cached). I think, to accomplish this, you'd need to write something by hand :/. There is a concept of mounts, which are directories that are shared across deploys. So, in theory, you could create some sort of a checksum of the assets/ directory and the package-lock.json and use that as your own personal "cache" key - e.g. looking for /some/directory/cached_assets/{key} . And if it's present, copying that to public/assets/ and skipping Encore. Else, build Encore then copy into the cached dir.

Unfortunate that there is, I believe, nothing built-in. But it does seem possible :).

Cheers!

Hi Ryan!

Thank you for sharing your ideas with me, they have sent me on an interesting journey of how to build a JS build cache and dash. Yet another learning experience for me. :)

In the end, my trials unfortunately failed, because the mounts are not available during build time. I'll keep digging (and asking) and I'll share my solution here, if I find one.

That being said, switching to Asset Mapper is already on our todo, it's just a matter of time. :)

The answer is quite simple, now that I know about it. Thanks to Chad from Platform.sh for pointing me to the solution!
There is variable called "PLATFORM_CACHE_DIR" that is available during build time for all your environments (see list of available variables). And that just does the trick. :)

This is fantastic! I didn't know about PLATFORM_CACHE_DIR. I think we may use it also, just to speed up the build part of the deploy. Super cool!

Hey @pasquale_pellicani!

Sorry for the slow reply - holidays!

but this used the 'smart admin' theme which used dynamic loading via ajax of contents, with the window.location library and use of hashes. Do you think the hotwired system could be a valid substitute?

Hmm. I want to say yes - but I'm not familiar with this "smart admin" theme system. But, generally-speaking, that does sound a lot like what Turbo offers: changing the URL on click, ability to AJAX-load contents.... it's all there.

Anyway, that's a weak answer - so let me know if I can offer more details :).

Cheers and happy 2024!

Sure, I take this opportunity to ask another question, but is this topic of the turbo and the hotwire very new ? I have had to search around for information or even pre-made templates but without success. Thank you

Hey again!

but is this topic of the turbo and the hotwire very new

Fortunately, no. Both Turbo and Stimulus are about 10 (yes 10!) years old. Though the most recent version of both was released 2-3 years ago, and that's when the Symfony world starting using it. It also started to grow more popular and get more features around then.

I have had to search around for information or even pre-made templates but without success. Thank you

This is an interesting statement. There are many pre-made Stimulus controllers - e.g. - https://www.stimulus-components.com/ - but no central place to find them... and no place to really find pre-made HTML markup + Stimulus controllers. Only moments ago, I was chatting about this with someone else - https://symfonycasts.com/screencast/last-stack/tailwind#comment-31337 - I would be interested what you think about my idea at the end.

Cheers!

thank you very much for the answers, at this point the question comes naturally, why choose stimulus/turbo and not react or vue js? I would like to understand the pros and cons between the two choices. ^_^

Hey Pasquale,

Choosing between Stimulus/Turbo and frontend frameworks such as React or Vue.js depends on the type of application you're building, the complexity of the features, and your personal preferences among other factors. Here're some ideas that I believe will help you to understand the diff:

Nature of the application: If you plan on building a Single Page Application (SPA), React or Vue might be the go-to choice as they are specifically designed to create rich interactive user interfaces with complex state handling. They allow you to return JSON from your server and build HTML 100% in JavaScript. On the other hand, if you prefer apps that primarily returns HTML from the server, Stimulus and Turbo might be a better option.

Use of existing technologies and best practices: Another reason to choose Stimulus/Turbo is if you have a preference for certain backend technologies or wish to make use of existing tools and best practices. The context mentions liking PHP, Symfony, and Twig and points out the various tools Symfony provides, like form handling and CSRF protection. If you've been building traditional server-rendered apps, then there are a plethora of tools you're familiar with that can speed up your development process.

Avoiding Full Page Refreshes: Stimulus and Turbo give you the option to create a SPA-like experience by avoiding full page refreshes without having to create an actual SPA. Turbo allows your applications to load every link click and form submit via Ajax, giving fluidity to the user experience.

Complex Features: React and Vue.js still have a place even if your application primarily returns HTML from the server and use Stimulus. If you have a particularly complex feature or widget to build on your site, React or Vue might just be the best tools for the job. They do well when complex interactivity and state management comes into play, and those components can fit perfectly into Stimulus.

Ultimately, the choice depends on your project requirements, the kind of user experience you're intending to deliver, where you want to handle most of your app’s logic (client side or server side), and personal preference.

You should add the +100 thumb below, it was the answer I was looking for, thank you all so much for the precious info ^_^

Hey Pasquale,

I'm happy to hear that comment was useful to you. I highlighted that comment, hope it will be useful for other users too :)

Cheers!