Click Below to Get the Code

Browse, clone, and build from real-world templates powered by Harper.
Blog
GitHub Logo

Skip the Boilerplate: How a Schema Can Power Your Entire Stack

Most apps start simple then accrete APIs, auth, caching, and realtime—Harper flips that by making your schema the app: define tables and relationships and you instantly get generated APIs, integrated caching, and pub/sub. This schema-defined approach lets teams prototype in hours and scale without glue code, extending with computed fields and custom APIs as needs grow.
Blog

Skip the Boilerplate: How a Schema Can Power Your Entire Stack

Aleks Haugom
Senior Manager of GTM
at Harper
August 28, 2025
Aleks Haugom
Senior Manager of GTM
at Harper
August 28, 2025
Aleks Haugom
Senior Manager of GTM
at Harper
August 28, 2025
August 28, 2025
Most apps start simple then accrete APIs, auth, caching, and realtime—Harper flips that by making your schema the app: define tables and relationships and you instantly get generated APIs, integrated caching, and pub/sub. This schema-defined approach lets teams prototype in hours and scale without glue code, extending with computed fields and custom APIs as needs grow.
Aleks Haugom
Senior Manager of GTM

Every developer knows the rhythm of a new project: you start by modeling your data and writing just enough logic to prove the idea. With a couple of endpoints and a working schema, things feel simple.

But projects rarely stay simple for long. Pretty quickly, you need an API layer that can scale. Then comes authentication, validation, and query optimization. As the app grows, performance challenges prompt you to consider caching. And when users start expecting live updates, you’re wiring in real-time infrastructure.

None of these steps happens all at once, but they all happen eventually—and each new layer adds deployment, configuration, and maintenance overhead. What began as a straightforward schema definition gradually sprawls into a full stack of services you’re responsible for stitching together.

A Different Approach

Harper flips this process on its head. Because Harper fuses storage, APIs, caching, and real-time events into a single runtime, your schema doesn’t just describe your data, it defines your application.

The moment you declare tables and relationships, Harper automatically generates APIs, integrates caching, and enables publish/subscribe events. Instead of bolting on these layers later, they’re available from the start, working together by design.

This is what we call a schema-defined application: an approach where the schema becomes the foundation not just for your data model, but for your entire stack.

Why It Matters

Shifting to schema-defined apps doesn’t just save you setup time; it changes how you think about building software. You’re no longer piecing together infrastructure before you can even test your idea. Instead, you begin with a working application that evolves as your schema evolves.

For developers, it feels like skipping ahead, but without giving up control. You still decide what your schema looks like and how your APIs behave, but Harper removes the friction of wiring up the basics. For teams, it means faster delivery, cleaner architecture, and fewer moving parts to maintain.

Examples in Action

To make this more concrete, we’ve published a few schema-defined applications you can explore today:

  • How to Build a Social Graph Service
    Create a schema that models users, posts, and follower relationships, and you instantly get the APIs needed for actions like following or unfollowing someone, building a personalized feed, and even broadcasting updates in real time.

  • Building a Product Catalog and Shopping Cart
    Define products, categories, and shopping carts in your schema, and you’ll have a full e-commerce backend that supports product browsing, cart operations, and live inventory updates—without wiring together separate services.

  • Building a Calendar and Scheduling App
    Model users, events, and availability, and Harper provides the endpoints to create meetings, check for conflicts, and update schedules in real time, giving you a functional calendar service from a straightforward schema.

Each of these examples begins with nothing more than a schema and quickly evolves into a fully functional backend. No glue code, no extra infrastructure, just data models that turn directly into functionality.

Taking It Further

The schema is only the beginning. As your application matures, Harper enables you to refine it without compromising the simplicity of the schema-first approach.

Need to reduce client-side processing? Add computed properties that automatically derive new values right in your schema. Want to expose business-specific workflows or aggregations? Extend your app with custom functionality tailored to your needs.

You don’t lose the ease of schema-defined apps when you grow; you build on it. That means you can go from idea to prototype in hours, then scale into production without rewriting your foundation.

Next Steps

If you’re ready to see how schema-defined applications can accelerate your workflow, here’s where to start:

  1. Explore the examples linked above to see how schemas become apps in practice.
  2. Review the docs on calculated fields and custom APIs to understand how you can extend your app.
  3. Experiment with your own schema, define a few tables in Harper, and watch how quickly they transform into a working application.

Final Thoughts

Schema-defined applications don’t remove complexity from software development altogether—but they make sure you’re not carrying it before you have to. By placing the schema at the center of the stack, Harper eliminates the friction of setting up APIs, caching, and real-time functionality, allowing you to focus on building meaningful features.

If you’ve ever wished you could move from schema design straight to a working application, Harper makes that possible. Define your schema, and the rest of the stack comes alive.

Start building with Harper today →

Every developer knows the rhythm of a new project: you start by modeling your data and writing just enough logic to prove the idea. With a couple of endpoints and a working schema, things feel simple.

But projects rarely stay simple for long. Pretty quickly, you need an API layer that can scale. Then comes authentication, validation, and query optimization. As the app grows, performance challenges prompt you to consider caching. And when users start expecting live updates, you’re wiring in real-time infrastructure.

None of these steps happens all at once, but they all happen eventually—and each new layer adds deployment, configuration, and maintenance overhead. What began as a straightforward schema definition gradually sprawls into a full stack of services you’re responsible for stitching together.

A Different Approach

Harper flips this process on its head. Because Harper fuses storage, APIs, caching, and real-time events into a single runtime, your schema doesn’t just describe your data, it defines your application.

The moment you declare tables and relationships, Harper automatically generates APIs, integrates caching, and enables publish/subscribe events. Instead of bolting on these layers later, they’re available from the start, working together by design.

This is what we call a schema-defined application: an approach where the schema becomes the foundation not just for your data model, but for your entire stack.

Why It Matters

Shifting to schema-defined apps doesn’t just save you setup time; it changes how you think about building software. You’re no longer piecing together infrastructure before you can even test your idea. Instead, you begin with a working application that evolves as your schema evolves.

For developers, it feels like skipping ahead, but without giving up control. You still decide what your schema looks like and how your APIs behave, but Harper removes the friction of wiring up the basics. For teams, it means faster delivery, cleaner architecture, and fewer moving parts to maintain.

Examples in Action

To make this more concrete, we’ve published a few schema-defined applications you can explore today:

  • How to Build a Social Graph Service
    Create a schema that models users, posts, and follower relationships, and you instantly get the APIs needed for actions like following or unfollowing someone, building a personalized feed, and even broadcasting updates in real time.

  • Building a Product Catalog and Shopping Cart
    Define products, categories, and shopping carts in your schema, and you’ll have a full e-commerce backend that supports product browsing, cart operations, and live inventory updates—without wiring together separate services.

  • Building a Calendar and Scheduling App
    Model users, events, and availability, and Harper provides the endpoints to create meetings, check for conflicts, and update schedules in real time, giving you a functional calendar service from a straightforward schema.

Each of these examples begins with nothing more than a schema and quickly evolves into a fully functional backend. No glue code, no extra infrastructure, just data models that turn directly into functionality.

Taking It Further

The schema is only the beginning. As your application matures, Harper enables you to refine it without compromising the simplicity of the schema-first approach.

Need to reduce client-side processing? Add computed properties that automatically derive new values right in your schema. Want to expose business-specific workflows or aggregations? Extend your app with custom functionality tailored to your needs.

You don’t lose the ease of schema-defined apps when you grow; you build on it. That means you can go from idea to prototype in hours, then scale into production without rewriting your foundation.

Next Steps

If you’re ready to see how schema-defined applications can accelerate your workflow, here’s where to start:

  1. Explore the examples linked above to see how schemas become apps in practice.
  2. Review the docs on calculated fields and custom APIs to understand how you can extend your app.
  3. Experiment with your own schema, define a few tables in Harper, and watch how quickly they transform into a working application.

Final Thoughts

Schema-defined applications don’t remove complexity from software development altogether—but they make sure you’re not carrying it before you have to. By placing the schema at the center of the stack, Harper eliminates the friction of setting up APIs, caching, and real-time functionality, allowing you to focus on building meaningful features.

If you’ve ever wished you could move from schema design straight to a working application, Harper makes that possible. Define your schema, and the rest of the stack comes alive.

Start building with Harper today →

Most apps start simple then accrete APIs, auth, caching, and realtime—Harper flips that by making your schema the app: define tables and relationships and you instantly get generated APIs, integrated caching, and pub/sub. This schema-defined approach lets teams prototype in hours and scale without glue code, extending with computed fields and custom APIs as needs grow.

Download

White arrow pointing right
Most apps start simple then accrete APIs, auth, caching, and realtime—Harper flips that by making your schema the app: define tables and relationships and you instantly get generated APIs, integrated caching, and pub/sub. This schema-defined approach lets teams prototype in hours and scale without glue code, extending with computed fields and custom APIs as needs grow.

Download

White arrow pointing right
Most apps start simple then accrete APIs, auth, caching, and realtime—Harper flips that by making your schema the app: define tables and relationships and you instantly get generated APIs, integrated caching, and pub/sub. This schema-defined approach lets teams prototype in hours and scale without glue code, extending with computed fields and custom APIs as needs grow.

Download

White arrow pointing right

Explore Recent Resources

Comparison
GitHub Logo

Kafka-Centered Stacks vs. a Single Harper Cluster: Where Real-Time Latency Actually Comes From

End-to-end latency in real-time pipelines comes from coordination across systems, not from any single component. Four common workloads, tested two ways, show where multi-hop architectures compound delays and where collapsing storage, messaging, and compute into one runtime changes the math.
Cache
Comparison
End-to-end latency in real-time pipelines comes from coordination across systems, not from any single component. Four common workloads, tested two ways, show where multi-hop architectures compound delays and where collapsing storage, messaging, and compute into one runtime changes the math.
Person with short dark hair and moustache, wearing a colorful plaid shirt, smiling outdoors in a forested mountain landscape.
Aleks Haugom
Senior Manager of GTM
Comparison

Kafka-Centered Stacks vs. a Single Harper Cluster: Where Real-Time Latency Actually Comes From

End-to-end latency in real-time pipelines comes from coordination across systems, not from any single component. Four common workloads, tested two ways, show where multi-hop architectures compound delays and where collapsing storage, messaging, and compute into one runtime changes the math.
Aleks Haugom
Jun 2026
Comparison

Kafka-Centered Stacks vs. a Single Harper Cluster: Where Real-Time Latency Actually Comes From

End-to-end latency in real-time pipelines comes from coordination across systems, not from any single component. Four common workloads, tested two ways, show where multi-hop architectures compound delays and where collapsing storage, messaging, and compute into one runtime changes the math.
Aleks Haugom
Comparison

Kafka-Centered Stacks vs. a Single Harper Cluster: Where Real-Time Latency Actually Comes From

End-to-end latency in real-time pipelines comes from coordination across systems, not from any single component. Four common workloads, tested two ways, show where multi-hop architectures compound delays and where collapsing storage, messaging, and compute into one runtime changes the math.
Aleks Haugom
Tutorial
GitHub Logo

Your API cache is secretly a database

Most teams treat a cache as a black box: URL-keyed blobs with a TTL, useful for speed and nothing else. In Harper, cached data lands in a real table inside the same query engine. That means filtering, joining, real-time subscriptions, and vector search all work against it.
Cache
Tutorial
Most teams treat a cache as a black box: URL-keyed blobs with a TTL, useful for speed and nothing else. In Harper, cached data lands in a real table inside the same query engine. That means filtering, joining, real-time subscriptions, and vector search all work against it.
Person with very short blonde hair wearing a light gray button‑up shirt, standing with arms crossed and smiling outdoors with foliage behind.
Kris Zyp
SVP of Engineering
Tutorial

Your API cache is secretly a database

Most teams treat a cache as a black box: URL-keyed blobs with a TTL, useful for speed and nothing else. In Harper, cached data lands in a real table inside the same query engine. That means filtering, joining, real-time subscriptions, and vector search all work against it.
Kris Zyp
Jun 2026
Tutorial

Your API cache is secretly a database

Most teams treat a cache as a black box: URL-keyed blobs with a TTL, useful for speed and nothing else. In Harper, cached data lands in a real table inside the same query engine. That means filtering, joining, real-time subscriptions, and vector search all work against it.
Kris Zyp
Tutorial

Your API cache is secretly a database

Most teams treat a cache as a black box: URL-keyed blobs with a TTL, useful for speed and nothing else. In Harper, cached data lands in a real table inside the same query engine. That means filtering, joining, real-time subscriptions, and vector search all work against it.
Kris Zyp
Tutorial
GitHub Logo

Introducing Structon: Random-Access Binary Encoding for JavaScript

Deserializing entire records to read one field is a bottleneck at scale. Structon stores objects in a binary format where any field is reachable by byte offset, with lazy getters that never allocate until you access a property. It's the encoding Harper has used internally for years, now a standalone package.
JavaScript
Tutorial
Deserializing entire records to read one field is a bottleneck at scale. Structon stores objects in a binary format where any field is reachable by byte offset, with lazy getters that never allocate until you access a property. It's the encoding Harper has used internally for years, now a standalone package.
Person with very short blonde hair wearing a light gray button‑up shirt, standing with arms crossed and smiling outdoors with foliage behind.
Kris Zyp
SVP of Engineering
Tutorial

Introducing Structon: Random-Access Binary Encoding for JavaScript

Deserializing entire records to read one field is a bottleneck at scale. Structon stores objects in a binary format where any field is reachable by byte offset, with lazy getters that never allocate until you access a property. It's the encoding Harper has used internally for years, now a standalone package.
Kris Zyp
Jun 2026
Tutorial

Introducing Structon: Random-Access Binary Encoding for JavaScript

Deserializing entire records to read one field is a bottleneck at scale. Structon stores objects in a binary format where any field is reachable by byte offset, with lazy getters that never allocate until you access a property. It's the encoding Harper has used internally for years, now a standalone package.
Kris Zyp
Tutorial

Introducing Structon: Random-Access Binary Encoding for JavaScript

Deserializing entire records to read one field is a bottleneck at scale. Structon stores objects in a binary format where any field is reachable by byte offset, with lazy getters that never allocate until you access a property. It's the encoding Harper has used internally for years, now a standalone package.
Kris Zyp