Product banners are one of the main ways to attract customers to your product. However, keeping banners up-to-date is often time-consuming and unrewarding. We saw this and wanted to create a way for entrepreneurs to add decent-looking banners to their own online stores without the hassle of having to manually re-generate banner images to reflect their item stock.

What it does

QuickBanner lets store owners add dynamically generated product banners to their Square Online homepage. Users can configure the style of banner they desire and the app will automatically choose items from the user's catalog and generate product banners on a daily basis.

How we built it

The project is a Flask application with a Postgres database and AWS S3 attached to it. Postgres stores persistent data, such as user accounts, while S3 acts as a static store for the banner images generated by the application. The app relies heavily on the Square API which was used to provide lists of sites and catalog items as well as the ability to inject banners into users' Square Online stores.

Challenges we ran into

One of the biggest challenges was finding a way to run banner update jobs alongside our web server. We initially tried to integrate the APScheduler module directly into Flask but ran into issues with circular dependencies and missing app contexts. Eventually, we discovered that a Flask integration for APScheduler had already been created, Flask-APScheduler, which allowed us to cleanly use the scheduler within the project. Later, we also discovered that Heroku free-tier would sleep our application, causing APScheduler jobs to fail to run. To address this, we added an alternative option to trigger jobs via command line which allowed us to run the update job via Heroku Scheduler.

Another challenge was finding a way to work the Snippets API into our application's flow. Resource management with snippets was particularly challenging. For instance, if a user deleted their account before deleting all snippets registered on their Square Online sites, they would be left with orphaned banners that they would be unable to remove. Our initial solution was to simply delete all snippets from a user when they deleted their account. However, this ended up lumping too many API calls within one request, slowing down the user's interaction with the application. Trying to delete snippets during account deletion also posed a separate issue where errors pertaining to snippet deletion would show up in account deletion error messages. This seemed out of context and confusing for the user. To combat both problems, we opted to only allow account deletion if the user had no registered sites with banners. This approach allowed for snappier feedback from the application to the user and sectioned off error messages to relevant requests as well.

There were also a few less technical issues as well, such as figuring our how to create generic banners that worked for a broad range of users and items and accounting for different types of currency. Working with text in the banners was particularly difficult because we needed to ensure that a variety of text did not overflow off the banner, becoming unreadable.

Accomplishments that we're proud of

We were most proud of having the chance to both experiment with the Square API and build a web application from start to finish.

What we learned

We learned a lot about working with OAuth in general as well as the Square API. Interacting with the API and Developer site gave us a chance to see how a backend application is designed to for other consumers and what might go into making effective development environments.

What's next for QuickBanner

QuickBanner has many areas of improvement. In the future, we may want to add more flexible and customizable banner creation, possibly in the form of an editor rather than a set of pre-made templates. Another possible improvement is to add more customization to where and on what pages banners get placed.

Share this project: