Loading…
Heroku
Heroku is a cloud platform as a service where you can deploy projects and websites. It supports several programming languages, so it’s no surprise that Heroku’s really popular.
- 143 posts summarised
- latest
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
From their blog
Latest articles
Building a GraphQL API in JavaScript
GraphQL lets API clients specify the fields they need instead of accepting a server-defined response, reducing unnecessary payload and potentially combining data from multiple stores behind one endpoint. The tutorial builds a JavaScript/Node.js implementation by loading Schema Definition Language (SDL) with graphql-tools, defining Query, User, and Address types, and connecting fields to resolver functions. Resolvers receive field arguments and can use context for authorization, illustrated by restricting address access to the current user. It also recommends keeping business logic separate from resolvers and notes that GraphQL does not eliminate database performance, caching, logging, monitoring, or versioning concerns. The discussion presents GraphQL as useful for evolving, front-end-heavy applications, while warning that its single HTTP status code and schema versioning limitations can complicate error handling and breaking changes.
From Project to Productionized with Python
The post presents a hands-on tutorial for Python developers moving a local Django application into production on Heroku. It frames the work around 12-factor practices and covers repository hygiene, modular settings, continuous delivery stages, static-asset middleware, environment configuration, database provisioning, deployment, scaling, and troubleshooting. The configuration changes include excluding virtual environments, caches, SQLite data, and generated static files; moving settings.py to settings/base.py; updating DJANGO_SETTINGS_MODULE; adding Whitenoise; and supplying SECRET_KEY and a Heroku Postgres add-on. The deployment uses Git, the Heroku CLI, git push heroku main, and heroku ps:scale web=1, with heroku logs --tail and heroku run bash for diagnosis. The walkthrough concludes with the app deployed and accessible through heroku open.
Evolving Alongside your Tech Stack
Rapid advances in software have expanded both what applications can do and what developers must understand, from efficient code to integration, security, and user experience. As tools make polished interfaces easier to build, engineers are expected to understand users, design sensibilities, system behavior, and constraints such as memory management and CPU load. The post recommends maintaining broad awareness of changing technologies while prioritizing learning around problems actually encountered; Postgres performance issues may warrant understanding traffic and write effects without exhaustive tuning. It cautions against adopting every new framework or database on reputation alone, using MemSQL as an example, and concludes that developers should evaluate trade-offs carefully, build expertise in the tools they operate, and focus on shipping meaningful product work.
Building and Scaling a Global Chatbot using Heroku + Terraform
Live Agent, Salesforce’s embeddable chatbot, must handle customer interactions and requests at global scale while remaining highly available across regions. Its eight-person team chose Heroku to avoid managing bare metal, cloud virtual machines, databases, and other third-party services, while relying on managed Java support and regional infrastructure. The platform runs ten apps with Heroku Postgres, Redis, and Apache Kafka dependencies, and deploys them inside Heroku Private Spaces to isolate network boundaries and data. Terraform defines and replicates apps, add-ons, custom domains, logging, and profiling configuration across regions, allowing changes to propagate through a pull request. The result described is a simpler operational model in which Heroku handles maintenance and the team can scale the same architecture into new geographic locations.
Building with Web Components and Their Advantages Over Third-party Libraries
Web development moved from HTML, CSS, and JavaScript toward proprietary libraries such as React, Angular, and Vue, creating interoperability concerns that Web Components aim to address through browser standards. The post traces this shift from early W3C work and Google’s Polymer Project to a toolkit of custom elements, HTML templates, and Shadow DOM, with examples showing how custom tags and reusable markup are defined. Custom elements encapsulate JavaScript behavior, templates defer markup rendering until requested, and Shadow DOM isolates internal styles and elements from surrounding page content. The resulting components can be packaged as dependencies and consumed across most browsers without loading a front-end framework, while libraries including Polymer, Stencil, and Lightning Web Components can abstract the underlying APIs.
Chrome’s Changes Could Break Your App: Prepare for SameSite Cookie Updates
Chrome's SameSite changes alter when third-party cookies are sent in cross-site requests, affecting sites that rely on embedded services, analytics, advertising, or other cross-domain functionality. Starting February 4, 2020, Chrome was to reject such cookies unless they were secured and assigned an appropriate SameSite value, as part of a secure-by-default model intended to reduce CSRF attacks, other vulnerabilities, and privacy leaks. The post explains first- versus third-party cookies, contrasts Strict, Lax, and None, and gives scenarios for selecting each setting; SameSite=None must be paired with Secure and HTTPS. It also recommends enabling Chrome 80 flags to test for errors, then updating application cookies or coordinating with third-party providers. Server-side support is noted for PHP, NodeJS, Python, Flask, and Ruby on Rails, with direct JavaScript cookie handling also mentioned.
Terrier: Open-Source Tool to Identify and Analyze Container and Image Components
Terrier is an open-source tool for identifying and verifying files and other components in OCI images and running containers, introduced alongside a Blackhat Europe talk on exploiting builds in the cloud. It targets supply-chain and forensic use cases, such as checking whether an image contains a known file or malicious package. YAML configuration selects image or container mode, supplies SHA256 hashes and, for container checks, paths; Terrier scans image layers or a container’s merged folder while keeping processing in memory for performance. Examples locate /usr/local/go/bin/go, report that the Jeilyfish package is absent, and verify curl and Go files in a running container; CircleCI and GitHub Actions examples show how checks can gate image-build pipelines.
Slow Database Queries? Are Database Types to Blame?
Slow database queries can stem from schema choices as well as inefficient SQL. The example uses PostgreSQL with a json column holding large payloads, then selects a single url value for an app_uuid and orders the results. EXPLAIN ANALYZE with BUFFERS showed 7,106 shared buffer hits, representing about 60MB of JSON data loaded and discarded, while execution reached 1,141.296 milliseconds in the reported run. The solution split the JSON into separate text fields for data and url, bringing query time down from about 1,200 milliseconds to 10 milliseconds. The broader conclusion is that schemas should be revisited as application usage becomes better understood, but changes are not necessary when the design isn't causing a problem.
The Curious Case of the Table-Locking UPDATE Query
The post recounts a PostgreSQL performance incident in which metadata processing stopped as jobs accumulated and an UPDATE targeting a single UUID remained active for days. Diagnostics showed the query consuming more than 80% of database time, while manual execution did not reproduce the delay. A pg_stat_activity and pg_locks query exposed many waiting statements and an AccessExclusiveLock entry whose locktype was tuple, leading the investigation toward PostgreSQL row locking and contention. The eventual cause was threaded code that issued concurrent updates to the same row for each job; removing that concurrency, aborting old backends with pg_cancel_backend, and deploying the change restored processing and began churning through the backlog. A correction notes that the reported lock was on a tuple rather than the table, and that PostgreSQL does not have lock promotion as suggested in the debugging discussion.
Let It Crash: Best Practices for Handling Node.js Errors on Shutdown
Node.js applications can lose visibility into failures and experience downtime when processes crash or shut down without useful logging and recovery practices. The post presents lessons from consulting and a talk on the Node.js process lifecycle, focusing on graceful shutdown, error visibility, and fast restart after catastrophic errors. It recommends keeping startup lean by prebuilding data or compiling assets, then contrasts process.exit(), which accepts an exit code, with process.abort(), which terminates immediately and may generate a core dump for llnode-based postmortem debugging. It also explains beforeExit and exit, including their differing asynchronous-work behavior, and introduces SIGTERM and SIGINT as operating-system signals that applications can handle. The intended result is a restartable process strategy that reduces downtime, while preserving evidence needed to investigate crashes.
Static Typing in Ruby with a Side of Sorbet
An experiment introduced Sorbet into a greenfield Ruby codebase with four developers to test whether static typing could catch bugs earlier, ease refactoring, and improve code design. Sorbet combines static linting with runtime checks that verify method parameters and return values against signatures, while RBI files describe methods from gems and Rails models. Setup required sorbet init, running sorbet tc, and adding that command to CI; however, Rails metaprogramming required model signatures, and sorbet-rails could miss or mistype fields. Sorbet immediately exposed issues including repeated method calls, unintended nullable database columns, and unnecessary explicit returns or guard clauses. The team reports a very positive short-term experience, while noting that the project’s young age caused most of the bugs encountered and that long-term value remains uncertain.
Automated Continuous Deployment at Heroku
Heroku’s Runtime team replaced a manual, coordination-heavy deployment process after team growth and Common Runtime sharding expanded work from one infrequently changed application in two environments to multiple services across 12 environments. Existing Heroku Pipelines deploy merged, CI-passing changes to staging, while the Go-based cedar-service-deployer reconciles differences between pipeline stages and promotes them when a series of safety checks pass. Those checks include a 30-minute age gate, deployment and incident controls, master-branch verification, Librato alerts, and HTTP 200 checks for configured URLs, including platform integration tests. The stateless system can handle concurrent rollouts, and the team added practices such as isolated early stages, feature flags, and separated database-migration changes. After about two years, it managed 23 services, allowing engineers to merge and rely on healthy systems for global release.
Up to 75% Faster Maintenances with Heroku Postgres and Redis Premium Plans
Heroku describes how it minimizes downtime during routine security and patching maintenances for high-availability Heroku Postgres and Heroku Redis plans. These plans run a writable primary alongside a hidden read-only standby, and maintenance requires moving application writes safely to the standby before promoting it. Previously, Heroku changed DATABASE_URL and restarted app dynos, then waited for the old primary to shut down and replicate remaining writes, which could extend downtime during long-running transactions. The new method redirects new connections to the new primary, kills existing connections to the old primary, and relies on reconnections plus a rolling restart to prevent further writes there. Heroku reports HA maintenances now complete in 15–40 seconds instead of 60 seconds or more, and says the behavior is default for Premium, Private, and Shield plans.
Designing for Accessibility: Contrast Ratio
Heroku’s accessibility initiative targeted WCAG 2.0 Level AA luminance contrast for its user interfaces, addressing reduced contrast sensitivity and color-vision deficiencies. The team audited its palette with Contrast Grid, proposed darker and revised colors, then chose a narrower proposal that preserved existing names and colors while meeting accessibility concerns within an affordable implementation effort. Because the palette affected GUIs built with Purple 3 and Malibu, pull requests generated Review Apps so teams could audit production-ready CSS and SVG assets across Dashboard components before release. Audits using axe-core 3.2.2 covered common and unusual elements, reducing color-contrast violations by an order of magnitude before rollout. The updated palette now spans the Heroku Dashboard, with planned accessibility testing through Ember tooling and further audits across other interfaces.
Dataclips Power Insights at Heroku
Heroku Dataclips let employees create SQL queries through a web GUI against Heroku Postgres databases, then share results through unique URLs or HTTP endpoints returning CSV or JSON. At Heroku, Dataclips reduce dependence on engineers or DBAs by letting departments retrieve fresh production metrics, build dashboards, track product usage, identify deprecated-feature users, and investigate suspicious signup patterns. To make querying safer, the organization runs dataclips against a read-only Postgres follower rather than the leader; writes propagate from leader to followers in close to real-time. Business Operations also teaches SQL and the internal schema through Office Hours, aiming to replace recurring one-off requests with self-service query skills.
Puma 4: Hammering Out H13s—A Debugging Story
Heroku investigated mysterious H13s—“Connection closed” without response—affecting Ruby applications during dyno deployments or scaling, especially at high traffic levels. The failure involved a race between SIGTERM shutting down Puma and the router’s separate system continuing to deliver a few requests, but comparison with other webservers indicated Puma needed to handle the condition. A reproduction used Rack applications that sent SIGTERM to Puma and themselves, plus parallel curl requests, reproducing curl exit code 52 and Heroku H13s. Debugging showed Puma relied on process termination to close accepted sockets; Puma 4 instead closes binder listeners before shutdown, allowing the router to retry connections while preserving responses for in-flight requests.
How Heroku Operates its Multi-Tenant Apache Kafka Services
Heroku’s Apache Kafka service supports thousands of developers and millions of transactions, including customers sharing multi-tenant clusters. The post explains how those clusters provide security, predictable performance, availability, and production-like topology at lower cost than single-tenant plans. Multi-tenant and single-tenant offerings use the same numbers of brokers and ZooKeeper nodes, while Kafka ACLs, per-tenant resource namespaces, and producer/consumer byte quotas isolate customers and limit resource contention. Heroku provisions purchased resources, expands storage at 80% of quota, and uses higher defaults for partitions, replicas, and in-sync replicas; exceeding capacity can eventually throttle throughput without stopping the cluster. Automated tests model 50 users with varied traffic, exercise throughput and partition configurations, and simulate broker failures and restarts to identify operational limits and adjust the infrastructure before customer impact.
Six Strategies for Deploying to Heroku
Heroku offers six deployment strategies: Git push, GitHub integration, Review Apps, Docker, Terraform, and the “Deploy to Heroku” button. Each has different requirements and trade-offs, and strategies can be combined in a workflow. Git push is simple but requires a developer with access to both repository and app, while GitHub integration can automate deployments and block them until CI tests pass. Review Apps provide disposable instances for pull requests; Docker supplies self-contained environments but requires maintaining a stack and does not support pipeline promotions. Terraform uses declarative HCL to manage Heroku and external infrastructure despite lacking official Heroku support, and buttons offer one-click deployments from GitHub repositories but do not auto-update or connect deployed apps back to their repositories.
CLI Flags in Practice + How to Make Your Own CLI Command with oclif
CLI commands commonly accept arguments, long flags, short flags, and flag arguments; environment variables and standard input are alternative data channels not covered in detail. GNU-style conventions use double dashes for long flags and single dashes for short flags; short flags can be stacked, and flag options may be separated by a space or equals sign, while short flags also allow no separator. The tutorial uses oclif to build greet-me, which prints a greeting based on a name supplied through -n or --name while registering version, help, name, and force flags. It scaffolds the project with npx oclif single greet-me, places handling code in src/index.ts, defaults the name to world, and runs the CLI through ./bin/run or an npm link.
Getting to Know Python 3.7: Data Classes, async/await and More!
Python 3.7 is presented as an upgrade for developers seeking new language features, library improvements, and performance gains over earlier Python 3 releases. The article focuses on data classes, where the @dataclass decorator inspects typed attributes and generates an init method, reducing boilerplate for data-oriented classes. It also covers asyncio.run for simpler asynchronous execution, breakpoint() for entering pdb, module-level getattr for lazy loading, and context variables that keep values separate across execution contexts. Dictionary insertion order becomes part of the language specification in 3.7, while OrderedDict remains available for advanced behavior; reported improvements include 10–30% faster startup, 45–70% faster common sorting cases, 5.5-times-faster dict.copy(), and 4–6-times-faster namedtuple creation.
Topics they write about
All topics →Weekly digest
The best engineering reads, once a week.