We're proud to release v0.9.1 of the platter CLI, featuring expanded support for non-Node environments through a platter.json stand-alone configuration file and file-specific subcommands.
Also included in this release are more helpful error messages and CLI-specific sessions that can now be revoked from the dashboard.
We're proud to release v0.9.0 of the platter CLI, featuring improved support for direct connections and use outside of Node-based projects, global installations through curl, and expanded platform support.
Included in this release are improvements to the instance create command and the introduction of a client-specific set of subcommands.
This is the third of a five-part series on Branchstack, the approach behind Platter's latest Branching Postgres product. Read the series introduction here and read the previous post about Environmentless development here
As applications have moved away from self-hosted, on-premise machines to cloud vendors, software developers have responded by adapting their application architecture around a cloud-hosted execution model called "serverless" computing. Instead of managing the hardware requirements behind their code, developers can now build modular codebases that scale up and down with use automatically.
In this post, we'll learn about Serverless architecture as a pattern, then we'll explore how this architectural pattern is integral to Branchstack methodology.
This is the second of a five-part series on Branchstack, the approach behind Platter's latest Branching Postgres product. Read the series introduction here
Software is not just code. Assumptions are made about the runtime or system that executes the code itself. State is shared across databases, third-party APIs, and other cloud-hosted services. And in most development workflows, arrangements of all of these parts are packaged in the form of "environments". Working on a new feature happens in a local "development" environment. Acceptance testing might happen in a "staging" environment. Users interact with a "production" environment. These environments are hard to manage, with drift and misconfigurations between them frequently causing outages.
But it doesn't have to be this way. Instead of accepting the errors and complexity that come from trying to manage evironments, we can get rid of the idea of environments entirely.
This is the first of a five-part series on the Branchstack, the approach behind Platter's latest Branching Postgres product. Read part two here.
Platter was born during a breakfast of hot-sauce-drizzled chorizo and eggs 🤤. Idle banter turned to rapid-fire complaints and proposed solutions as we wondered aloud why getting software to users reliably was so difficult—much more so than writing that software in the first place. We soon realized that we were ideal partners to take on this problem together, and we've been dreaming up and working hard on solutions ever since. But our approach has changed drastically based on things we've learned along the way.
In this post, we'll talk about the problem of software delivery in general, how we built a Golden Path to solve that problem, and how Platter now instead supports any number of shortened development and deployment paths, with a set of software development principles and practices that we call the Branchstack. In following posts, we'll dive into the details with deeper analysis and real-world examples we and and our customers have encountered.
We're proud to announce that Postgres instances are now using 13 by default. This upgrade will apply to all new Postgres instances created with platter postgres create.
You may have noticed a release of v0.8.2 of the platter CLI. This release includes a pipe()-related bugfix in the generated Node client and an extension of Linux support to earlier versions of Ubuntu (or any other distro with earlier versions of glibc).
Testing applications and their databases is tricky but important.
When done correctly, tests that include real database queries help to reassure developers that their features are implemented correctly across the entire stack. When done poorly, database-dependent test suites can be slow, flaky, and even dangerous to run.
In this post, we'll explore strategies for keeping data-dependent tests realistic, consistent, isolated, and fast by running tests against short-lived, isolated databases. The concepts in this post will apply to any application that depends on a database, but we'll be using Node for our runtime and Jest as our test runner to explore different strategies.
Today we're releasing v0.8.1 of the platter CLI with support for Apple Silicon and a watch-related bugfix.
We're proud to release v0.8.0 of the platter CLI, featuring improved watch performance, new list output types, trunk configuration for new instances, and arbitrary branching of Postgres data!