# Challenges

## SEO

Search Engine Optimization (SEO) is important to us, as it drives organic search discoverability and sales. It involves making sure that search engines can crawl the application to index its content.

Traditionally, crawlers are not built to handle Client-Side Rendered (CSR) applications. CSR happens entirely in JavaScript, and most crawlers don't run JavaScript at all - therefore, they will be unable to see the application's content unless we take this into consideration.

While some crawlers may now be able to run JavaScript, we still need to ensure that all search engines can index our app. This can be achieved with several different approaches, all of which involve rendering part of the app on the server, and responding with that result.

[Dynamic rendering](https://developers.google.com/search/docs/guides/dynamic-rendering): the web server needs to detect crawlers. For crawlers, it serves a pre-rendered version of the app, but for other clients, it serves the regular JavaScript app.

{% hint style="info" %}
Pre-rendering: the frontend App is run on the server, in a headless browser. The resulting HTML is served instead of the app.
{% endhint %}

## &#x20;API Complexity

The traditional style of building APIs is [REST](https://restfulapi.net/). It involves creating multiple endpoints that the client can use to fetch and manipulate resources. However, for a large application such as Magento, the REST approach starts encountering problems:

* Increasing numbers of endpoints are hard to keep track of and remember
* Additional data returned by each endpoint (sometimes unnecessarily) grows the size of the response

To address these problems, Magento also supports a [GraphQL](https://graphql.org/) API. ScandiPWA builds on the GraphQL API and uses it in the frontend app, due to its advantages:

* GraphQL only offers 1 endpoint with well-documented queries
* The client can now request only the data it needs, saving bandwidth
* Endpoints and their datatypes are documented when defining the schema, which is checked by GraphQL

### GraphQL Caching

Using GraphQL creates an additional challenge - we need to find a way to cache API requests, which could easily be done with REST. By default, Magento sends the full query as a stringified JSON parameter, to take advantage of `GET` request caching. Despite this method's simplicity, it creates a limitation in query size, as the maximum URL length cannot be exceeded. In addition, this strategy requires the full query to be sent every time, increasing bandwidth usage.&#x20;

ScandiPWA uses an alternative approach - the persisted query method. Initially introduced by [Apollo](https://www.apollographql.com/), this approach involves transforming each query into a short identifier, which solves the caching problem and saves bandwidth, at the cost of some additional requests made.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.scandipwa.com/introduction/challenges.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
