Click Below to Get the Code

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

Harper at Node.js Interactive 2017

Fred discusses Harper's experience at Node.js Interactive 2017 in Vancouver, BC.
Blog

Harper at Node.js Interactive 2017

Fred Yoon
EVP of Corporate Strategy & Co-Founder
at Harper
October 9, 2017
Fred Yoon
EVP of Corporate Strategy & Co-Founder
at Harper
October 9, 2017
Fred Yoon
EVP of Corporate Strategy & Co-Founder
at Harper
October 9, 2017
October 9, 2017
Fred discusses Harper's experience at Node.js Interactive 2017 in Vancouver, BC.
Fred Yoon
EVP of Corporate Strategy & Co-Founder

Harper had its coming out party to the Node.js community last week as we were a sponsor at Node.js Interactive in Vancouver, British Columbia.  The event is one of many hosted by the Linux Foundation and the venue provided for an incredible backdrop to a very exciting event.

There were approximately 750 attendees this year and the enthusiasm around Node was palpable. Over the course of two days, more than 200 Node.js developers visited our booth to learn more about Harper and more than 50 downloaded our Community Edition.

It was very exciting to interact with the Node.js community and hear their feedback, and discuss the Harper roadmap.  We chatted with individual developers and learned about their journeys through Node.js and how Harper could be a step along that adventure.  People had some incredible ideas around what could be done with Harper, and it was amazingly fun to watch folks building on top of it right there on-site. There were also great suggestions on some really incredible solutions and libraries that we are excited to begin working to incorporate within Harper.

We enjoyed talking to the awesome folks at NPM like Laurie Voss (@seldo) and learning about different features and options at NPM for Harper.  It was also exciting to hear about different contributions companies like Microsoft, Google, Amazon, and Intel are making to the Node.js community. 

We feel very lucky to be part of such an open, enthusiastic, and cutting edge community.  Thank you to the Linux Foundation for hosting such a great event and one that the founders of Harper will never forget.  We look forward to returning next year. 

Harper had its coming out party to the Node.js community last week as we were a sponsor at Node.js Interactive in Vancouver, British Columbia.  The event is one of many hosted by the Linux Foundation and the venue provided for an incredible backdrop to a very exciting event.

There were approximately 750 attendees this year and the enthusiasm around Node was palpable. Over the course of two days, more than 200 Node.js developers visited our booth to learn more about Harper and more than 50 downloaded our Community Edition.

It was very exciting to interact with the Node.js community and hear their feedback, and discuss the Harper roadmap.  We chatted with individual developers and learned about their journeys through Node.js and how Harper could be a step along that adventure.  People had some incredible ideas around what could be done with Harper, and it was amazingly fun to watch folks building on top of it right there on-site. There were also great suggestions on some really incredible solutions and libraries that we are excited to begin working to incorporate within Harper.

We enjoyed talking to the awesome folks at NPM like Laurie Voss (@seldo) and learning about different features and options at NPM for Harper.  It was also exciting to hear about different contributions companies like Microsoft, Google, Amazon, and Intel are making to the Node.js community. 

We feel very lucky to be part of such an open, enthusiastic, and cutting edge community.  Thank you to the Linux Foundation for hosting such a great event and one that the founders of Harper will never forget.  We look forward to returning next year. 

Fred discusses Harper's experience at Node.js Interactive 2017 in Vancouver, BC.

Download

White arrow pointing right
Fred discusses Harper's experience at Node.js Interactive 2017 in Vancouver, BC.

Download

White arrow pointing right
Fred discusses Harper's experience at Node.js Interactive 2017 in Vancouver, BC.

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