This course is still being released! Check back later for more chapters.

Get Notified About this Course!

We will send you messages regarding this course only
and nothing else, we promise.
You can unsubscribe anytime by emailing us at:
Login to bookmark this video
Buy Access to Course

Bundle Config: Configuring the Cache Service


Share this awesome video!


Keep on Learning!

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

So far, we've learned how to use the HTTP Client and cache services, and we've injected that into the homepage(). But, we're not responsible for creating their objects. We already know that bundles give us services, and when we autowire a service, our bundle provides all of the details we need to instantiate it. But if something else is responsible for instantiating those objects, how can we control it? The answer is bundle configuration.

Open the /config/packages directory. All of these .yaml config files are automatically loaded into our Symfony application, and their job is to configure services that each bundle gives us. In our homepage() method, right in the beginning, let's dd($cache) so we can see the class name of the object we're getting.

41 lines | src/Controller/MainController.php
// ... lines 1 - 13
class MainController extends AbstractController
// ... line 16
public function homepage(
// ... lines 18 - 20
): Response {
// ... lines 23 - 38

For example, for the cache service, FrameworkBundle tells the service container:

Hey! When I ask for the CacheInterface, I want you to instantiate this TraceableAdapter object with a specific set of arguments it needed.

So it looks like our cache service is just this TraceableAdapter, but if we look closer, we can see that it's actually a wrapper around a FilesystemAdapter, and the cache is stored inside the file system. That's cool, but what if we want to store the cache in memory instead? Or somewhere else in the file system? This is where bundle configuration shines. Open framework.yaml and find this framework root key. This means we're passing configuration to the FrameworkBundle, and it'll use that config to change how it instantiates its services. By the way, the file name here isn't important. We could call this pizza.yaml and it would work just the same.

24 lines | config/packages/framework.yaml
// ... line 1
secret: '%env(APP_SECRET)%'
// ... lines 4 - 24

Okay, head over to your terminal and run:

Debugging Configuration

bin/console debug:config framework

This shows us the current config. To see the full config, run:

bin/console config:dump framework

That is a lot of information. Let's narrow that down. If we want to see the configuration that's responsible for the cache service only, run:

bin/console config:dump framework cache

Cache Array Adapter

Much better. Over in cache.yaml, we can see that this is still part of the framework config - just separated in different files for organization. Below this example, let's set app to cache.adapter.array.

22 lines | config/packages/cache.yaml
// ... lines 3 - 16
app: cache.adapter.array
// ... lines 18 - 22

Okay, back at the browser, refresh. Awesome! This changed to ArrayAdapter. Head over and remove dd($cache) so we can see the cache.array.adapter in action. Refresh the page again, and... ah! Every time we refresh the page, we're executing the HTTP request, so the cache is only live during the request. When we start a new request, the cache invalidates and we see that HTTP request again.

Next: Let's take a closer look at autowiring.