Why is there a 100 KB limit on Theme App Extension files?

[JAS_Technology]

Hi all. I am working on a Theme App Extension and really am enjoying the power of all of this. The flexibility I am providing to the merchant without touching their theme code at all is super cool. BUT.....  I now realize there is a 100 KB limit on my Liquid files! I'm hovering right around it and am getting nervous that I will constantly have to deal with this and potentially sacrifice valuable features/settings. 

Why such a low limit??? To provide highly customizable blocks it requires a lot of schema. A lot of schema takes up a lot of space. And of course the markup to support that schema will take up space and we get closer and closer to this ceiling. I agree that we can't go crazy and have no limit cause...... we will 😉   

I suggest we raise this limit to 500KB or something like that. The full extension limit is 10MB so is the assumption here that these extensions will have heavy media assets and light liquid? 

Give us the power!! 🚀

Please like if you agree.

[blogusama]

My potential solution to the issue of the 100 KB limit on Liquid files in the Theme App Extension is to suggest increasing the limit to 500 KB or a similar value. The reasoning behind this suggestion is that providing highly customizable blocks requires a significant amount of schema, which in turn takes up a lot of space, as well as the markup to support it. Given that the full extension limit is 10 MB, it would seem reasonable to increase the Liquid file limit.

Additionally, we also face this situation while developing a led panel app but our developer could explore alternative methods of storing and accessing data, such as using APIs or external databases, to reduce the load on the Liquid files.

It may also be worth considering the trade-offs between having a high limit and sacrificing features or performance and having a lower limit but a more streamlined and optimized codebase. 

[jam_chan]

I don't understand why there is a limit on the size. It just gives me pain when I'm trying to migrate from section files to the theme app extension.

[DaveMartin]

Totally agree @JAS_Technology - we have been wresteling with this limitation for over a year. We are currently at the point where we are forced to spend a lot of our time just trying to find more ways to reduce our liquid so we can add more features and/or improve existing ones. I have been talking to every person I can who may be invovled in this at Shopify and also voiced to to Shopify at the last Unite, but nothing seems to be done. It is very dissapointing that Shopify hasnt figured out a way to increase this for us - especially now they are taking away access to the Asset API and forcing all apps to use TAE. And btw - I love TAE - but this one thing is a massive cross against them when it comes to creating create merchant solutions. Hopefully @Shopify listing and do something soon. 

[Arif_Shopidevs]

We are facing many issues. I am also not sure why this happens. When developers are forced to move from script tag to app extension. they need to put their js , CSS image, etc. App size limits their creativity. Even when publishing files. it shows js size is big. It is difficult for developers to build something.

[Mishal_marufa]

Did you guys find out any work around through this file size limits.  Since we are facing the same problem on our app. we had to split the app to two.

[jam_chan]

I can only offload the liquid code to js for client side rendering. But there is still a size limit for the liquid files

[DaveMartin]

Our issue was we designed our app prior to this issue being known, so some things we cant change, however for new additions etc, we tended to create <script> tags, and then loop through the liquid data within it, applying it to javascript objects that we can then pass to our JS class to render the elements on page. It sucks we had to do that, but it works and that is our approach until this limit is raised.

[Mishal_marufa]

Could you please help us and show some of the examples .

[Mishal_marufa]

We have multilingual store. How does js elements will work through translations?

[Aleksandr_Andr]

Hi there.

Did anyone find solutions for the limits?

[JAS_Technology]

I think it's clear now that the 100KB is really meant for very minimal HTML/Liquid markup plus the SCHEMA needed for each block. The assets area has more space allotted (and of course externally hosted assets is unlimited). If the extension is coded using more of a "headless"/JS/React mindset, the amount of functionality/UX that can be delivered with these extensions becomes quite large. 

[jeffquach]

To clarify, when you say a "headless"/JS/React mindset are you referring to fetching HTML and related markup from things such as metafields, metaobjects or HTML located externally and retrieved through an API call?  If so, what's your opinion on offering the merchant the flexibility to customize settings for elements on the page?  I think there would be some limitations since you can only fit in so many options within Shopify's 25 setting hard limit.

[JAS_Technology]

I'm suggesting that the data, beyond the blocks' schema settings, could be retrieved using the storefront API or other API calls. And the UI/markup is delivered using something like NextJS or Remix, etc... The 25 schema setting limit on blocks is a limitation no matter what direction is taken. That is another very tough limit and hinders super robust options for the merchant.

[SommCoder]

This was a very helpful thread. Thank you for starting it.

I'm under the assumption that Shopify wants to restrict TAEs because TAE-only apps can be hosted by Shopify themselves.

So I'm guessing they've built them with that kind of governance/limiting in mind.

Obviously, I'd like less restrictions too so perhaps there could be a larger file size limits if a TAE is self-hosted.

[PaulNewton]

Isn't theme extensions defacto limit actually 45kb,  ~45~49% of that.

If you need to be able to validate changes or a-b test  you have to put ALL code in ONE deploy ,as a new pushed version, that doesn't immediately force everyone to every new change.

With the other 1% as space for feature flag conditions or margin of error.

That's not even accounting for trying to have merchant specific versions deployed.

With they way deploys work doesn't that mean even an increase to a hypothetical 500kb, devs should still aim for less for 50% of that in projects with version-branches.

Another route may be devs requesting that metaobjects/metafields* be able to store and render liquid directly or as snippets; ala custom-liquid in theme settings. Or able to have schemas separate of liquid files; see this github discussion for the reference theme implementation. 

Or from the file system.

With a large caveat being that idea has to keep in mind private or public resources for apps that don't want their underlying code visible to merchants or competitors.

if able to store schemas then it's not as big a deal about code-privacy as they schemas contain little info not already exposed in the theme editor for anyone/any-tool to rehash.

*metafields and metaobjects are already one way to reduce the size of a blocks codebase in some cases; especially with JSON type parsing in liquid?