DEV Community: John Lago

Why We Ditched Vercel for Our NodeJS App

John Lago — Fri, 12 Jul 2024 19:57:23 +0000

In the world of web development, the search for the ideal hosting solution is never-ending. Like many others, we initially fell in love with Vercel for its user-friendly interface and near-zero setup. Vercel is an excellent solution for static sites, perfect for our websites and documentation. CDN caching makes everything fast, efficient, and cost-effective.

Given our positive experience with Vercel for static sites, we decided to host our NodeJS servers there as well. We had several Remix servers we thought could be supported by edge functions. After all, isn't the future all about going serverless? We decided to host our authentication flow and dashboard app on Vercel using edge functions. Spoiler alert: it did not go well.

Why Vercel Doesn’t Cut It

Speed Issues: The Dream Dies

Our first red flag was performance. Serverless functions on Vercel were not up to par in terms of speed. And it wasn’t just us—many developers have voiced similar frustrations. For an application handling critical user interactions like authentication, speed is paramount. The delays were noticeable, often around 600ms to 1 second.

Debugging Nightmares: The Endless Cycles

Vercel detects the framework of your NodeJS server in an attempt to turn each route into an edge function. Server-side libraries may build successfully for edge functions yet encounter issues at runtime without notice. With most bugs not reproducible locally, and the remote environment is not something you can SSH into, endless trial and error becomes the norm. What’s worse, you may find out the package you need is not edge-function compatible at all.

Cost Explosions: The $96K Surprise

For customers, calculating usage is no longer as simple as total billable hours for a single EC2. To make it more concrete, a single JS server that contains ten routes will split into ten different edge functions. While Vercel gives you uptime and scalability guarantees, a shocking $96K bill may knock on your door if you get a spike in usage.

The bottom line

Going serverless for an app that clearly needs a backend server? In hindsight, that should make us pause for a second. Just because the server is written in JavaScript, does not mean we should treat it differently from a server written in Go, Rust, or Python. The bottom line — infrastructure should be language and framework-agnostic.

The ultimate dream: an edge-function-like platform for Backend

Without a good substitute for Vercel’s edge functions, we Jetifiers like to build our own.

Introducing Jetify Deploy, a platform that incorporates the best properties of edge-function while avoiding its drawbacks:

No Dockerfiles needed: don’t know how to write Dockerfiles or Kubernetes YAMLs? No problem, you don’t have to. However, you can provide a devbox.json or Dockerfile if you want more control.
No application code change: there are no special libraries you need to import or hidden route splitting that happens behind the scenes.
Zero DevOps: no Terraform, Ansible, or shell scripts needed. Import your application code from GitHub, and we will handle the rest.
Stateless: deployments are as disposable assets, not precious pets. Past deployments are kept as idle copies until needed.
Easy cost management: Your server spins up when it gets a request and spins down when idle. You won’t get a hundred edge functions just to handle a surge in requests.
Write once, run anywhere: wrap your project with Devbox to get an identical environment for local, preview, and production. Any issues encountered on production can be reproduced locally. Or anywhere.

Looking ahead

We have successfully migrated our authentication flow and dashboard app from Vercel edge functions to Jetify Cloud. The transition was smooth, and we have seen significant improvements in speed, debuggability, and cost.

We are excited to share our journey and encourage others facing similar challenges to explore new possibilities. You can try Jetify Cloud for your own solo projects with a 30-day free trial. Jetify Cloud accounts also come with access to the Jetify Cache, and Jetify Secrets:

Stay tuned as we continue to refine our setup and share more insights. If you are struggling with your current hosting solution, we hope our story inspires you to find your perfect fit. You can follow us on Twitter, or chat with our developers live on our Discord Server. We also welcome issues and pull requests on our Github Repo.

Don't Rebuild Yourself - an Intro to Nix Package Caches

John Lago — Fri, 12 Jul 2024 19:36:54 +0000

In previous blog posts, we’ve talked about how we speed up Devbox installs by fetching package closures directly from the official Nix Cache. This blog post will dig a bit more into how a Nix cache solution works, and how it can speed up your package installation time. In addition to covering the official Nix cache, we’ll talk about how you can integrate the Jetify Cache with Devbox to speed up your shells and share your custom packages across your team.

Building Reproducible Packages with Nixpkgs

The Nixpkgs repository provides over 100,000 packages, and supports multiple architectures and operating systems. Nix packages define all their requirements and dependencies within their build definition, making them reproducible and isolating them from the dependencies on your host machine. This means you can install multiple versions of the same Nix package on the same machine without conflicts.

This isolation comes with a trade-off. Due to the unique way Nix defines packages, it can't simply download upstream binaries. Instead, it needs to ensure the package links its dependencies in the Nix store correctly. The only way to guarantee a package does this is to build the package and it’s dependencies from source, and link it’s dependencies within the Nix store.

All that building can add up. Building a package like MongoDB can take up to 30 minutes, and that's just for MongoDB. Building a full closure from source can take hours, and updating a dependency in the graph means you have to rebuild the whole universe. All that building leads to the obligatory XKCD comic:

Speeding up Installations with Nix Package Caches

Fortunately, Nix's reproducibility and isolation also makes it easy to share and reuse the build outputs of packages. Each Nix package has a unique store path determined by the hash of its inputs. This unique store path means Nix can identify and reuse build outputs easily.

This reuse happens in two layers:

Nix can reuse existing packages and outputs in your Nix Store. When Nix starts building your package's dependencies, it first checks if a package with the correct store path exists in your local store, and then reuses that store path. The Nix Store enables sharing packages on a single machine, but you'll need a different layer if you want to share across machines.
To share across machines, you need a Nix Cache. If someone is building and pushing the packages you need to a cache, you can skip building and download precisely what you need. Developers can configure multiple Nix caches as "substituters," which tell the Nix Daemon where to look for “substitute” store paths that aren't in their current Nix store.

The largest cache is the Public Cache maintained by the NixOS Foundation. The Foundation knows that users want to avoid constantly rebuilding, so they build most of Nixpkgs packages in Hydra (Nix’s CI build system) and push them to the public cache. For the most popular binaries and platforms, the Nix Public Cache has you covered.

The public cache does have some gaps, however, that your project can fall into

Packages outside the Nixpkgs like custom packages on our machine or flakes hosted in public repositories.
Packages such as MongoDB, Terraform, and Vault aren't hosted in the Nix cache because they lack an open-source license.
Older packages, or packages on less popular platforms, can be garbage collected or excluded from the public cache.

For this reason, many developers set up their own Nix caches to use as substituters for their custom packages. Technically, any machine running Nix can serve as a cache or substituter for another machine. If you're trying to support a team, however, managing issues like trust, access control, and populating the cache with the latest packages can take a lot of extra effort and development.

Jetify Cache: A Package Cache designed for Devbox and Nix

For teams that want a cache without the extra overhead, we built the Jetify Cache. Jetify Cache is an enterprise grade Nix Cache that integrates nicely with Devbox, so you can speed up your shells with little extra effort.

Our Jetify Cache offers two solutions that can help your team develop faster:

For packages in Nixpkgs that are not available in the Nix Cache, we offer the Jetify Prebuilt Cache. This provides prebuilt versions of packages not in the official Nix Cache. If you have a Jetify Cloud account, Devbox will automatically configure the Prebuilt cache as a substituter. When Devbox prepares to install a package, it will use the Prebuilt cache if there are any gaps in your local Nix Store or the official Nix cache.
For your custom packages and flakes, we offer the Jetify Private Cache. Jetify Private Cache lets you share binaries across all your devices and developers. After you build your Devbox project (either locally, or in CI), you can run devbox cache upload to push the entire closure of your project to the cache. Developers who share your Jetify Cloud Project can then easily download their packages from the cache without building from source.

Devbox: Optimized for Nix Package Caching

Devbox can automatically configure the Jetify Cache caches for you when you authenticate with Jetify Cloud With the Jetify Cache enabled, you now have 4 layers where Devbox and Nix can check for binaries before building from source:

The Nix Store (/nix/store)
Your Jetify Private Cache
The Official Nix Cache (cache.nixos.org)
The Jetify Prebuilt Cache.

As mentioned above, Devbox can install packages by copying them directly from the cache, without needing to re-run evaluation steps. We do this by retrieving the store paths directly from Nixhub (our Nix Package Search engine) at install time, and then save the store paths in our devbox.lock file. With this optimized cache experience, you can start reducing your installation times in seconds.

Keep Up To Date on Jetify and Devbox

If you want to speed up your package installs, the Jetify Prebuilt Cache is available to any developer who signs up for a free Jetify Cloud account. If you have custom packages or binaries you want to cache, you can check out our pricing plans for Jetify Cloud.

We’d love to hear your feedback on Devbox and Jetify Cache. You can follow us on Twitter, or chat with our developers live on our Discord Server. We also welcome issues and pull requests on our Github Repo.

TypeID-JS: Type Safe, K-Sortable Unique IDs for Javascript

John Lago — Tue, 09 Jul 2024 16:29:27 +0000

Since we first announced TypeID last year, we've seen significant adoption and interest from the community, with 23 different language clients contributed by the community and 90,000 weekly NPM downloads of our Typescript Implementation.

Last week, we released version 1.0 of our Typescript implementation, TypeID-JS. To celebrate this release, we wanted to share more about why we wrote TypeID, and how we use it to ensure type safety at Jetify.

Type Safety and Unique Identifiers

We developed the idea for TypeID while building Jetify Cloud, our solution for deploying and managing Devbox or Docker based projects across your team. Jetify Cloud's architecture has many different entities we need to manage: Orgs, Users, Deployments, Secrets, and Projects, all of which require unique identifiers to distinguish them.

Originally, we started by following best practices and assigning a UUID to each instance of an entity. Still, we quickly ran into a problem: UUIDv7 lacks type safety! Take the code below as an example:

export const getMember = async (
  memberId: UUID,
  orgId: UUID,
) => {
  const { member, organization } =
    await authClient.organizations.members.get({
      organization_id: orgId,
      member_id: memberId,
    });

  return { member, organization };
};

This function uses two UUIDs to look up a member and organization. However, the function cannot ensure that memberID and orgID represent the correct entity! If a developer accidentally uses a memberID where we were expecting an orgID, we would only discover the issue at runtime.

As we were looking for solutions to this problem, we encountered Stripe's Object ID, which encodes type information into IDs using a prefix. This seemed like a great solution, but unfortunately, we couldn't find a well-defined standard for consistently implementing typed IDs across multiple languages.

TypeID: K-sortable, type-safe, globally unique identifiers

TypeID is our attempt to create such a consistent standard. TypeID is a type-safe, K-sortable, globally unique identifier inspired by Stripe's prefixed types. TypeID also provides a consistent standard for other languages to implement their clients and libraries.

TypeIDs encode unique identifiers as a lowercase string with three parts:

A prefix that represents the ID’s type (63 chars, lowercase ASCII letters)
An underscore (_) separator
A 128-bit UUIDv7 encoded as a 26-character string using a modified base32 encoding.

  user_2x4y6z8a0b1c2d3e4f5g6h7j8k
  └──┘ └────────────────────────┘
  type    uuid suffix (base32)

With this format, a TypeID-compatible client can encode and decode type information into your IDs and then run checks at a build or compile time to ensure you are using the right ID. For example, if we wanted to create a random TypeID for a user entity, we could do something like this:

With TypeID, we can also add type checks to our functions and catch errors at runtime. Rewriting the example above, we can now be sure that developers will use the proper IDs in the right place:

import { TypeID } from 'typeid-js';

export const getMember = async (
  memberId: TypeID<'member'>,
  orgId: TypeID<'org'>,
) => {
    ...
}

In addition to type safety, this format has a few properties that make it friendly for developers to use:

UUIDv7 compatible: You can easily convert a TypeID into a UUID by removing the prefix and decoding the suffix.
K-sortable: You can use a TypeID as a sortable primary key in your database with good locality.
URL safe: We use TypeIDs in our URLs to make them easy to copy, paste, and share. Including TypeIDs in the URL makes simplifies generating page state.
Easily selectable: You can copy and paste it by double-clicking (Try it!)

New Features in TypeID-JS v1.0

Today, we're announcing version 1.0 of our TypeID-JS library. This update adds several new features to improve usability and type safety, including:

Unboxed, function-based, streamable TypeIDs: This makes it possible to serialize TypeIDs without casting them to strings and lets you use TypeIDs as keys in Maps and Sets.
Stricter Type and Runtime checking: TypeID now throws an error if you attempt to parse an empty string or a typeid with the wrong prefix.
Compatibility with TypeID spec v3: JS TypeIDs can now use underscores in the prefix. For example: pro_subscription_2x4y6z8a0b1c2d3e4f5g6h7j8k is a valid TypeID with prefix pro_subscription.

How to Use TypeID with your project

You can add TypeID to your JS project using your NodeJS package manager of choice. Not using JS? TypeID has 26 different implementations, ranging from Go to OCaml to SQL. If you’re interested in writing your own implementation of TypeID, you can check our our formal specification.

Looking to Power-Up your Development Team?

Our team at Jetify builds powerful developer tools. Simplify your deployments and projects with Jetify Cloud, or automate onboarding + dev environments with Devbox. You can follow us on Twitter, or chat with our developers live on our Discord Server. We also welcome issues and pull requests on our Github Repo.