FAQs

In this article, you'll find answers to some frequently asked questions.

How does scaling in your GCP work?

In general, we use Google's autoscaling group feature to scale our customer's projects.

Currently, we use CPU usage as a scaling factor as we made the best experience with that context in mind. Still, we're aware that this might differ in the future, so our rolling-update script allows parameterizing those settings per customer.

As a threshold, so that enough instances are available in load scenarios, we identified a value between 70-80%.

At the moment, we use high CPU, normal RAM instances (4 vCPUs, 3,6 GB - n1-highcpu-4) because, in the current scenarios, Frontastic needs more computing power than memory. So, we also allow this to be customized per customer.

Does Frontastic have any sort of A/B testing functionality or helpers we could use?

At the moment, we can only help with ideas, but you can use standard JS tools like Dynamic Yield, Kameleoon, Optimizely, and so on.

Is it possible to see what the Server Side Rendering looks like so I can debug issues?

Yes! You can see the results of Server Side Rendering by adding ?_frontastic_disable_hydration to your URL, and then it won't hydrate (run React in the browser and make the Server Side Rendered result interactive).

For example, https://demo-show.frontastic.io/?_frontastic_disable_hydration. Then you can see how your <<glossary:Frontastic components> will render on the server as it disables the Client Side Rendering. This way, you can see the results of the SSR, and it makes it easier to debug any issues in your Server Side Rendering.

If you want to, you can also manually hydrate your application by calling _frontastic_hydrate() in your browser's developer console.

How long does the build and roll out take in general?

After committing to master, a build should usually take less than 20 minutes.

After a successful build (that can be verified by an automatically created commit in master), the auto-deploy is triggered, which typically takes less than 10 minutes. You can check the build and the info by opening the Frontastic studio, clicking Developer, then clicking Continuous Integration.

See the deployment article for more information.

How can we check that a user is currently logged in on our site?

The best method is to use context.isLoggedIn as it also checks if there's a session available and is more resilient.

To give you an idea of how to use it, here's a quick example:

context.isLoggedIn = function () {
     return this.session && this.session.loggedIn
}

Does Frontastic include Polyfills?

Yes, find and findIndex functions for JavaScript array Polyfills are included in Frontastic, and they're shipped with babel presets. All features up to ES10 standard (Array.flat, Object.fromEntries, and so on) are also supported.

They're found in your repository in your project config folder (.../catwalk/config/polyfills.js)

You can also add your own Polyfills if you want to. See the extending the webpack configuration article for how to do this.

Can you activate automatic deployment in PhpStorm?

Yes, you'll need to set the configuration like below and use the password vagrant:

When should I extend the Frontastic domain models?

It depends on what you want to do and what properties or features you're missing. It's possible to extend the domain objects like variant, product, and so on in Frontastic\Common\ProductApiBundle\Domain\Variant.

You'll need to use our LifecycleDecorators to set the values. You can assign the values from the dangerousInner* to the necessary properties in these. See our API decorators article for more information.

The dangerousInner* properties will contain all the information returned by your commerce backend. These then get stripped, so they're not sent to the frontend, which is why you need a LifecycleDecorator to enrich your own variant. This is done for performance and security reasons (and also because certain objects aren't possible to encode as JSON).

Below is an example of how you could set a certain property inside a LifecycleDecorator which extends our product:

class ExtendedProduct extends Product
{
     /**
     * @var string
     */
     public $fancyProperty;
     public fancyVariantProperty;
}

use ProductApi\LifecycleEventDecorator\BaseImplementation;
class ProductWithFancyProperty extends BaseImplementation
{
     public function beforeProduct(
    ProductApi $productApi,
    $query,
    string $mode = ProductApi::QUERY_SYNC
     ): ?array {
        $query->loadDangerousInnerData = true;
    return null;
     }

     public function beforeQuery(
    $productApi,
    ProductQuery $query,
    string $mode = ProductApi::QUERY_SYNC
     ): ?array {
    $query->loadDangerousInnerData = true;
    return null;
     }

     public function afterGetProduct(
    ProductApi $productApi,
    ?Product $product
     ): ?Product {
        return $this->extendProduct($product);
     }

    public function afterQuery(
    $productApi,
    ?Result $result
    ): ?Result {
        if ($result === null) {
            return null;
        }

        $result->items = array_map(
            function (Product $product) {
                return $this->extendProduct($product);
            },
            $result->items
        );

        return $result;
    }

    public function extendProduct(?Product $product)
    {
        if ($product === null) {
            return null;
        }

        $myExtendedProduct = new ExtendedProduct(get_object_vars($product));
        $myExtendedProduct->fancyProperty = $product->dangerousInnerProduct-->fancyProperty;
        $myExtendedProduct->fancyVariantProperty = $product->variants[0]        
        ->dangerousInnerVariant['attributes']['fancyProperty'];

        return $myExtendedProduct;
    }
}

Some methods use Query as a parameter that contains the loadDangerousInner property. Those queries are ProductQuery, CategoryQuery, SingleProductQuery, and ProductTypeQuery. Based on the value of loadDangerousInner, the dangerousInner* will be set as part of the response object.

So, if you need to access the dangerousInner*, you might want to set the value of loadDangerousInner as true as we've done in the above example.

How do I set up PhpStorm (or another IDE) with Frontastic?

In most cases, all IDEs will work out of the box. If you want to fully integrate your IDE with Frontastic, you can set up several extra things.

For example, in PhpStorm, you can integrate our Unit-Testing-Framework so you can execute tests within your code in PhpStorm using the run test button. To do this, you'll need to set up an interpreter for the test framework by going to Edit Configurations then selecting the more icon next to Interpreter:

Input the hostname from the Frontastic sandbox you're using and click OK:

Click the setting icon next to Use alternative configuration file:

Edit the Path to script and Default configuration file to match your project and click OK. They'll both start with /var/www/frontastic. Below is an example of what they could look like: