How a fictional ski resort helped me understand Snowflake Native Apps
As someone who’s been in the world of modern app development for over a decade now, I’ve had a healthy exposure to all sorts of stacks used to build web and mobile apps. But when Snowflake Native Apps were announced, I have to say, I was initially a little confused. There were a few questions I had:
- What exactly are they?
- How do they work?
- How are they built?
- How are they managed?
Poring over technical docs, presentations, and examples helped, but only slightly moved the needle for me when it came to building a working mental model of Snowflake Native Apps. So I set out to get a better grasp of them by dabbling in an app’s source code and writing a Snowflake Quickstart on the topic. Now that I’m further along in my journey with this amazing new Snowflake feature, I thought I’d share some of the things I’ve learned that I feel can help accelerate your building of Snowflake Native Apps.
What is a Snowflake Native App?
In my own words, a Snowflake Native App is a data application that runs in Snowflake, right next to your data.
Apps are built by app creators, or providers, and are listed on the Snowflake Marketplace for distribution and monetization. Apps are discovered and installed by consumers, and run in a consumer’s Snowflake account.
Apps can do all sorts of neat things by using the logic built by the provider and running it against data in the consumer’s account, providing some sort of value to the consumer (i.e., analytics, etc.).
How exactly is a Snowflake Native App built?
Snowflake Native Apps are built using other Snowflake features. Each feature makes up a different part of the application. Let’s dive into the details by comparing a common pattern for building modern applications to the architecture used by Snowflake Native Apps.
A common architectural pattern for building a modern web application includes a front-end, API, and a back-end:
- Front-end — The user interface, or UI, typically built with front-end frameworks (i.e., React, Vue, Angular, etc.).
- API — The custom interface between the front-end and back-end that facilitates logic against data, based on actions that occur in the UI.
- Back-end — “Back-end” can refer to several different components of an app, but for the purposes of this comparison, let’s focus on just the data store, or, the database(s) being used to store all sorts of data related to the application.
Structure of a Snowflake Native App:
- Front-end — The UI of the app is built with Streamlit, an open-source Python library for creating powerful data apps. The front-end runs directly within Snowflake.
- API — There’s no API that needs to be built or stood up! More details below.
- Back-end — The database(s) are all within Snowflake, and necessary application logic can be built using SQL and/or Snowpark (which supports Python, Java, Scala).
This comparison was one of two important things that helped me build a working mental model of how Snowflake Native Apps are built. I’ll share the second important thing in the next section.
More details on the “API” for Snowflake Native Apps: There’s no need to manually write a custom API (i.e., routes, logic, etc.) for Snowflake Native Apps. Because you’re building with Snowflake features, and because the app runs entirely within Snowflake right next to the data, application logic can easily be built using SQL and/or Snowpark. I love how Snowflake Native Apps make this part of app building so much easier!
Providers and Consumers
You’ll run across the terms “provider” and “consumer” often when reading literature related to Snowflake Native Apps. The former refers to the app creator, and the latter refers to the app user. I found that understanding the dynamic between these two personas was critical in understanding Snowflake Native Apps. It’s the second important thing that helped me build a working mental model.
The gist of this dynamic is that providers provide the application logic and UI, while consumers bring the data and the compute. Let’s dig into more detail.
Providers define the following for an application:
- Roles — The role(s) for the application. For instance, an app may have different types of users: an app could define an “admin” role and a “viewer” role, where the admin would have more privileges within the app than the viewer.
- Permissions — What roles are able to do (or not do) within the application.
- Reference usage on proprietary data — The provider may have proprietary data that the app requires so that it can function as intended. Because the data is proprietary, however, it is not provided directly to the consumer. In fact, this is a common misconception. Instead, providers grant the app reference usage to this proprietary data so that it can be shared within the app.
- Application logic — All logic necessary for the app to meet its intended purpose can be implemented with SQL and/or Snowpark.
- Views — The UI of the application, where application logic may be invoked based on actions that occur in the UI.
Consumers provide the following when using an application:
- Data — Any data within a consumer’s Snowflake account used by an application. For example, perhaps you’re ingesting product data into your Snowflake account via a connector. A relevant Snowflake Native App installed in that account can then provide analytics on that data. Although data is used by the application to meet its use case, the data is not shared directly with the app provider.
- Compute — Consumers use their own compute (i.e., warehouses) to power operations performed by the application.
A practical example: Build a Snowflake Native App to Analyze Chairlift Sensor Data
That’s a run down of the concepts that have helped me grok Snowflake Native Apps, and I hope they help accelerate your journey with this new feature. But enough theory, let’s dive into a practical example where many of these concepts are illustrated.
I recently published a Quickstart called Build a Snowflake Native App to Analyze Chairlift Sensor Data — I encourage you to try it out and provide feedback. Here are a few things you should pay special attention within the Quickstart that illustrate the concepts I’ve described so far:
- The scenario — I mentioned earlier that understanding the dynamic between the providers and consumers is paramount to understanding how a Snowflake Native App may function. In the Quickstart, you take on the role of a chairlift manufacturer that sells chairlifts to ski resorts. Customers install the chairlifts at their resorts and use the sensors on the chairlifts to ingest data on the condition of the chairlifts into their Snowflake account. As the manufacturer, you’ve created a Snowflake Native App that customers can install and run in their Snowflake accounts to generate analytics on the raw sensor data. These analytics help customers uncover insights about the condition of the chairlifts — something the owner of these expensive chairlifts would be very interested in!
- Logic (from the provider) — Take a look at setup.sql in the source code for the app (the repo is linked in the Quickstart). You’ll note roles, schemas, Streamlit views, tables, stored procedures, and other things that are created so that the app can function as intended.
- The UI (from the provider) — Take a look at the files within the ui/ directory of the source code. Files that start with “v_” represent the three different views (tabs) within the UI of the app, namely v_configuration.py, v_dashboard.py, and v_sensor_data.py. Admins have access to all three views, while viewers have access only to the latter two views. There are also other Python files within this directory that are used for application references, first time app setup, and more.
- Data (from the consumer) — For demonstration purposes, we mock raw sensor data in the Quickstart. This data is intended to represent consumer data. Take a look at prepare/consumer-data.sql for context (note that there’s more detail in the Quickstart).
- Compute (from the consumer) — You’ll designate a warehouse to be used to power the application during first time installation and setup of the app.
Conclusion and Next Steps
What I shared in this post are a few things that helped make things “click” for me when it came to understanding Snowflake Native Apps. I hope you’ll find them useful in accelerating your learning journey as you build your own apps.
Keep an eye out for improvements to Snowflake Native Apps — we’re always working on ways to streamline the developer workflow, and of course, expanding the capabilities of what Snowflake Native Apps can do. Finally, here are some resources I’d recommend as you explore this feature:
- Quickstart: Build a Snowflake Native App to Analyze Chairlift Sensor Data
- Quickstart: Getting Started with Snowflake Native Apps
- Video: Deep Dive: Snowflake Native App Framework
- Playlist: Snowflake Native Apps
- A recent live stream I participated in with Felipe Hoffa and Sohail Zafar (PM for Snowflake Native Apps at Snowflake):
Thanks for reading and have fun building!
