Introducing bunny-bundle (for Symfony developers)

[tacman]

I have a (rough) bundle for Symfony developers. One of the main things it does is simplifies the password, so that (1) they are defined in environment variables and (2) you don't need to pass them explicitly when calling the edgeApi.

Here's a simple proof-of-concept that you can cut and paste as long as you have a bunny api key (and of course the symfony CLI):

symfony new bunny-demo --webapp && cd bunny-demo
composer require survos/bunny-bundle
bin/console bunny:config APIKEY >> .env.local
bin/console bunny:list

The above populates the .env.local file with the necessary API keys, in a real application you'd probably want to be selective about which ones to export.

You can browse interactively with the basic admin controller.

composer require survos/simple-datatables-bundle
symfony server:start -d
symfony open:local --path=/bunny/zones

There's also commands for uploading and downloading files from the bunny edge storage.

bin/console bunny:upload larco.zip "/data/" museado -vv
bin/console bunny:download larco.zip "/data/" museado -vv

where larco.zip is in the museado zone, /data/ path.

Feedback welcome!

[ToshY]

Hey @tacman 👋

Nice for you to share it!

If I'm not mistaken, the survos/bunny-bundle you mention is from this the repo https://github.com/survos/SurvosBunnyBundle right? The current implementation of the bundle seems very much tailored to using edge storage zones. Will this be the main focus of this bundle?

I'm asking this as I'm considering to add a link to the repo to my own README, but I'm a bit "worried" that the bundle already tries to do too much (even though it's in early stages) for a bundle of a third-party package.

Normally when I see/use a (Symfony) bundle for a package (like this one) it just contains some config to wire services and that's it. No additional commands, controllers, services or (unnecessary) dependencies. It keeps it simple and easy to maintain.

I have already expressed my thoughts on creating a bundle and that you can achieve the same with a couple of lines in the services.yaml, but I can understand that it might still prove usefull for other people. Personally, I would rather go for a bundle that is minimal and without all these "extras".

If your focus will be kept on the storage zones then I will respect your decision, it might however be a bit clearer if you could clarify this is your documentation, as stating "A Symfony bundle to interact with BunnyCDN via the Bunny-PHP library." could lead to incorrect assumptions (like I did) regarding the functionality of the bundle.

[tacman]

Yeah, interesting question. The original intention was to wrap your library calls in a bundle, in particular to make managing the credentials easier. Indeed, the edgeApi works that way, you don't have to explicitly pass the api key.

But my main goal was to make it easy for my application to exchange files. Previously I was using AWS s3, but setting up the security was a pain, and I didn't want to expose my aws secrets to every application or server that needed to get a file. So the bundle could be called survos/cdn-bundle, with adapters for bunny and aws and whatever. But really the goal of the bundle was to be a wrapper around your library, plus add some optional UI (like browsing zones and files) and some CLI commands.

Configuring the security took me longer than expected, so I didn't even get around to implementing upload, let alone the apis besides the edgeApi. And I realize that this could also have been done with Flysystem (via https://github.com/PlatformCommunity/flysystem-bunnycdn).

Once I add the ability to upload/sync files and directories, this will be enormously useful to me, as syncing large data files between production and development, and between developers, has been a sore point. So thanks you for making this library available and your me encouraging to try it.

I can rename the bundle the data-exchange-bundle or something if you'd prefer, even if I only support bunnyCdn via your library for now.

Of course, I'd love it if the bundle supported everything, you've already done the hard work of the API calls, so it's mostly security and the wrapper that's left.

If you wanted to maintain the bundle but don't want the console / UI commands, I could move that out to a bunny-extra-bundle, which would be a wrapper around bunny-bundle.

What I particularly like about my bundle right now is that you can cut and paste a few commands and immediately start exchanging data, and you can set up a readonly password for a specific zone with very little work.

Thoughts?

[ToshY]

But really the goal of the bundle was to be a wrapper around your library, plus add some optional UI (like browsing zones and files) and some CLI commands.

Okay I understand, and I see that additional commands/browsing functionality can definitely have added value to some users.

I can rename the bundle the data-exchange-bundle or something if you'd prefer, even if I only support bunnyCdn via your library for now.

That's completely up to you. 🙂 I was just expressing possible confusion it might have if it for the most part only supported the edge storage. But you can disregard that comment if the goal is still to be be a complete wrapper eventually.

Of course, I'd love it if the bundle supported everything, you've already done the hard work of the API calls, so it's mostly security and the wrapper that's left.

If you wanted to maintain the bundle but don't want the console / UI commands, I could move that out to a bunny-extra-bundle, which would be a wrapper around bunny-bundle.

I like the idea of having one bundle being basic wrapper of the library, and one having the additional commands/controllers/etc. to facilitate some aspects (like the browsing/syncing/etc. you mentioned before). It gives the users a choice to pick which library they want to use, with or without the extra functionality. Again, this decision is also up to you (as I'm not going to maintain it myself).