Unleashing Imprint App’s asset management system to scale with new brand partners

At Imprint, we have developed an advanced design pattern to manage, fetch and cache brand partner-specific assets, colors, and logos in our mobile app. This system efficiently addresses the growing number of brand partners we support and ensures a seamless experience for our users. This blog post outlines the key features and benefits of our asset management system.

Problem statement

As our app supports an increasing number of brand partners and users sign up for a subset of these brand partners, we face the challenge of providing brand partner-specific images, themes, and logos to our mobile and web applications in an efficient manner. Our goals for this system are as follows:

1. Avoid increasing the mobile app binary file size when onboarding new brand partner assets.
2. Onboard new brand partner assets without requiring a new mobile app release or a code change/deployment of our web app.
3. Eliminate the need for a new mobile app release when existing brand partners update their assets.
4. Implement a caching system on the mobile side to minimize network bandwidth consumption and preserve battery life.
5. Streamline the asset management process to minimize the involvement of multiple engineering teams.

Initial solution

In our initial solution, we utilized an AWS S3 bucket to store the assets and colors, while the URLs linking to these assets were managed on our backend. The backend would then provide these URLs to the app through existing APIs. Although this design had its advantages, we encountered several drawbacks:

Pros:

• Onboarding new brand partner assets did not require a new app release.
• Updating existing brand partner assets did not require a new app release.

Cons:

• The backend was responsible for managing assets for each brand partner, resulting in increased complexity on the backend system.
• The backend still needed to do a code change/deployment for every new brand partner onboarding.
• Asset URLs were tightly coupled to existing backend APIs, causing issues when screens required the same asset but were not utilizing the API.
• Supporting new assets required updates to both the backend and frontend schemas.
• Lack of a naming convention made asset management disorganized.
• No defined caching convention resulted in suboptimal use of resources and image load latency.

Improved solution:

To address these limitations and enhance our asset management system, we have implemented the following improvements:

1. Decoupled assets from the backend system: While keeping the assets in the S3 buckets, we removed direct backend involvement in managing brand partner assets. This reduces API response payloads and allows any screen to fetch the required assets.
2. Unified naming convention: We updated the service to follow a unified naming convention, making asset management more organized and scalable. Frontend can now fetch assets by using the brand partner’s ID in the URL path, with domain URL path hard-coded in the app. As long as the frontend has the brand partner’s ID, it can fetch assets for any screen without depending on backend APIs.
3. Simplified asset updates: With the backend no longer managing assets, when a new asset is introduced, only the frontend requires an update. This reduces the complexity and dependencies between the backend and frontend teams.
4. Frontend caching: This improved image load latency and reduced network bandwidth usage and extended battery life.

Let’s dive into this system, in more detail, below.

Caching:

We have implemented a robust caching mechanism on the frontend to optimize performance and reduce network requests. Here are the key details:

• When fetching the brand partner’s colors (colors.json) file, the response header will contain a Cache-Control: max-age=<seconds> property. The frontend uses this value to cache the colors and assets associated with that brand partner’s ID for the specified period before refetching.

• If needed, assets and colors can also be force-updated via Firebase remote config, ensuring timely updates when necessary.

Future:

As we look to further reduce manual involvement of our engineering teams and make our system more scalable, our goal is to develop a user-friendly self-service dashboard exclusively designed for brand partners. This GUI platform will empower them to effortlessly upload and manage their own assets, ensuring full control over their digital resources. Additionally, we are committed to promoting collaboration and innovation within the development community. To achieve this, we will create an open source mobile SDK that enables developers to efficiently handle assets and colors. The SDK will allow users to configure asset URLs and cache settings according to their specific requirements. Through these initiatives, we aim to enhance the overall experience for both brand partners and developers alike.

Conclusion:

In summary, these improvements provide several benefits:

1. Efficient onboarding of new brand partner assets without the need for app releases.
2. Seamless updates to existing brand partner assets without app releases.
3. Reduced complexity by eliminating direct backend involvement in asset management for each brand partner.
4. Improved performance through caching, resulting in reduced network bandwidth usage and extended battery life.
5. Streamlined asset management process, reducing the dependency on multiple engineering teams.

By continuously enhancing our asset management system, we ensure a scalable and reliable platform for Imprint, enabling us to efficiently support a growing number of brand partners and deliver an exceptional user experience.

If you are interested in building with us, you can find us at talent@imprint.co or imprint.co/careers.