Daily top stories

Aptible is the No Infrastructure Platform that startup teams use to launch—and scale—big ideas. Engineering teams use our platform as a service (PaaS) to deploy web apps and APIs in seconds, scale infinitely, and never worry about setting up or managing infrastructure. Let’s make No Infrastructure the standard in software development:

https://www.aptible.com/culture-hub/careers

Hey HN! We're building Seam (https://www.seam.co), a universal API for controlling IoT devices such as smart locks, thermostats, sensors, and (soon) cameras. Our hope is to make device integration simple, with a Plaid-like UI flow for obtaining device authorization and standardized API/SDKs for device control.

We started Seam out of our frustration with the challenges of integrating IoT devices with software apps.

For example, my co-founder Dawn led Sonder's efforts to integrate smartlocks with their reservation systems in order to automate access for guests. She struggled with poorly documented and unreliable device APIs along the way. Our founding engineer Max authored the popular TuyAPI library and has spent countless hours trying to build sensible interfaces on top of unreliable devices.

For my part, I was an early engineer at Nest and saw firsthand how manufacturers often lack the resources and motivation to support third-party developers.

As a result, most devices lack public APIs, and getting access to the private ones (if they exist) requires lengthy negotiations with manufacturers. This task grows in complexity with each additional device brand a developer may need to integrate.

Seam serves as a single API that works across dozens of brands and hundreds of devices.

We start by testing each device in our hardware lab in San Francisco. We study their behaviors & quirks, and faithfully reproduce those in our development sandbox. We take time to craft custom client libraries that maximize developer ergonomics while accounting for the asynchronous nature of the devices. We offer pre-built UI components (React, Web-native…etc) to let developers rapidly assemble complex UIs that can manage large fleets of devices. And we even have a small hardware gateway to connect on-prem and legacy devices.

A few app developers like Guesty (YC S14) already use Seam to connect to their end users’ devices. We have a generous free tier and charge a small fee for additional devices. We work closely with manufacturers to improve device reliability, add OAuth support, and patch security holes. We also spend time educating them on the importance of supporting open source projects like Home Assistant, OpenHab...etc and we will be contributing some of our own integrations to those ecosystems.

Seam is still very much a work in progress with many aspects that need to be improved. But our hope is that it will help push IoT devices from being (mostly) point solutions, to becoming a set of API endpoints software engineers can tap to interact with the physical world.

Hello HN! I'm an engineer at Splitgraph and recently started learning Rust so I could make my first contribution to Seafowl [0], an early stage analytical database. Along the way I figured out a database hosting hack on GCP and wanted to share it with HN. It's a way to achieve "true" scale to zero database hosting that could be useful for certain side projects or spiky traffic situations.

A recurring problem I've faced with side projects is the need for Postgres, but no desire to deploy or maintain new instances. So when I learned GCP's "always free" tier includes serverless [1] I got curious to see if I could run a database.

While a lot of classic databases aren't usually a great fit for serverless, Seafowl separates compute, storage and catalog (catalog == a SQLite file of metadata). [2] Last month I was able to introduce GCS bucket compat to Seafowl, which enabled me to mount the catalog via gcsfuse (i.e. an adapter that allows attaching GCS buckets to local filesystems). Upshot: while FUSE does add HTTP requests to container startup, init time remains comparatively quick, even cold starts, because fetching is limited to the single catalog SQLite file only.

With this approach you get a URL you can query directly from your FE if you want, e.g. fetch() can send SELECT * ... queries straight from your users' browser. You could plot a graph from a static React frontend, or observablehq.com editor, with no persistent backend needed. So at times when nobody's using your app, 100% of your stack can scale to zero with obvious cloud spend advantages. And even if you exceed free tier limits, being PAYG offers a good chance you'll come out ahead on hosting costs anyway.

NB: Seafowl is an early stage project, so it's not really suitable if you need transactions or fast single-row writes. Otherwise, this could be a nice way to get free database hosting at a big 3 cloud provider, especially for e.g. read-only analytical reporting queries.

Feedback and suggestions are appreciated. Hope it helps you! More available if you want [3].

[0] https://seafowl.io/docs/getting-started/introduction

[1] https://cloud.google.com/run/pricing#cpu-requests

[2] Neon is another interesting project that separates compute and storage. https://neon.tech/blog/architecture-decisions-in-neon

One issue I observed was a noticeably longer startup time vs this FUSE approach, which I believe may be related to Postgres connection setup time/roundtrips. Looking forward to trying Neon again in future.

[3] https://www.splitgraph.com/blog/deploying-serverless-seafowl