DEV Community: Joshua Nussbaum

Gating entrances with Stripe and NFC passes

Joshua Nussbaum — Thu, 21 Aug 2025 10:24:05 +0000

ℹ️	Re-posted from stripe.dev

While working remotely and traveling from place to place, I noticed a recurring pattern.

Every time you arrive in a new city, you rent an Airbnb or check-in to a hotel. Then you sign up for a gym and a co-working space.

Payments for these services are all done electronically. But when it comes to access, you need a plastic card, a fob, or a physical key.

This creates friction for everyone involved. You have to go pick it up, carry it around, hope you don’t lose it, and return it before leaving.

From the business side, they need to pay someone to work the front desk to issue, track, and collect these access devices.

This made me wonder, what if access was fully digital?

Digital wallet passes

Luckily, there is a better way that is gaining popularity.

Instead of cards and keys, we can issue digital passes with Google Wallet and Apple Wallet and use an NFC reader to gate the entrance.

These digital passes are like certificates that are scannable with NFC. They can be issued and revoked electronically without human intervention (no front desk needed).

Since everyone already has a smart phone or watch with Apple Wallet & Google Wallet, there’s nothing extra to install or carry.

Integration

Both Apple and Google have public Wallet APIs for issuing passes, but for smaller companies it's easier to use an intermediary like PassNinja.

PassNinja acts as an abstraction layer on top of Apple & Google, so you only have to integrate one API.

Then you can place an Apple/Google compatible NFC reader near the doorway. We'll use the DotOrigin VTAP100.

Building it

As an example, we'll build a simple gym membership system.
Full Source Code

Members can purchase a Stripe Subscription and a digital pass will be issued to them. The member can then use their phone (or watch) to access the doorway.

There will be two codebases:

Website: A public facing website that accepts payments via Stripe Checkout and issues the digital passes.
Gate: A private access control system that runs on Linux near the entrance. It will verify the status of the membership by contacting the Stripe Subscription API, and unlock the door for active members.

Architecture

Hardware

Here's what you'll need to build the solution:

Requirements

Computer: A Raspberry PI Zero 2W or equivalent. For communicating between NFC Reader and Stripe API over WiFi.
NFC Reader: VTAP100, an Apple / Google Wallet compatible NFC reader.
Electronic Door Strike/Bolt: To unlock and lock the door.
Relay: A 3.3V Relay or equivalent. To control locking and unlocking the door strike from the Raspberry PI.
PassNinja Account: To handle issuing of Google & Apple Wallet Passes.

Wiring diagram

The wiring will look like this:

PassNinja setup

To set up PassNinja:

Create an account.
1. Visit https://www.passninja.com
2. Click "Get Started"
Create a pass template
1. Log in to PassNinja: https://www.passninja.com/login
2. Click on "Dashboard" in the upper right corner
3. Click on "New Pass Template" button and create a template for Google & Apple
Setup the NFC Reader:
Follow these instructions https://www.passninja.com/tutorials/hardware/how-to-configure-a-dot-origin-vtap100-nfc-reader

Purchase flow

The purchase part is on a public website that handles the checkout and issuing of passes.

We’ll have an endpoint /subscribe to create the Stripe Checkout session and redirect the user to pay:

// in web/src/index.ts

// create a Stripe API client
const stripe = new Stripe('<your stripe key>')

// when user visits /subscribe, a Stripe checkout session is created and they're redirected to pay
app.post('/subscribe', async (c) => {
  // this is where the user is redirected after payment`  
  const success_url = new URL('/success?session_id={CHECKOUT_SESSION_ID}', '<your domain>').toString()

  // create a checkout session`  
  const session = await stripe.checkout.sessions.create({
    mode: 'subscription',
    success_url, 
    line_items: [
      { price: '<your price id>', quantity: 1 }
    ]
  })

  // redirect the user to pay
  return c.redirect(session.url)
})

When the user finishes paying, Stripe Checkout will redirect them to /success, and the digital pass can then be issued:

// in web/src/index.ts

// create the Pass Ninja API client
const passNinja = new PassNinjaClient('<account id>', '<api key>')

// when user visits /success (after checkout completes), issue the digital pass 
app.get('/success', async (c) => {
  // get checkout session_id`  
  const session_id = c.req.query('session_id')

  // get the Stripe checkout session
  const session = await stripe.checkout.sessions.retrieve(session_id)

  // get the Stripe subscription
  const subscription = await stripe.subscriptions.retrieve(session.subscription)

  // ensure the subscription status is active`  
  if (subscription?.status !== 'active') throw new Error('Subscription was not successful')

  // we've confirmed it's paid, so issue a new pass`  
  const pass = await passNinja.pass.create(
    PASSNINJA_PASS_TYPE,
    {
      name: session.customer_details.name,
      email: session.customer_details.email,

       // *important*: save the subscription_id inside the pass
      // this is the value the NFC reader sends during a scan
      "nfc-message": session.subscription
    }  
  )

  // redirect the user to add the pass to their wallet
  return c.redirect(pass.url)
})

Door access control

The door access logic can run on any computer, but we'll use a Raspberry PI Zero 2W which is an inexpensive option (~$15 USD) and has the ability to control a relay.

The sequence looks like this:

The NFC reader acts as a virtual serial port, and each time a user’s phone or watch is placed near it, a new line is sent over the serial port.

Linux typically maps virtual serial ports to /dev/ttyACM0. To access it from Node.js, we'll use the npm package serialport.

// in gate/src/index.ts`  
import { SerialPort } from ‘serialport’`

// create a serial port client`  
const port = new SerialPort({ path: '/dev/ttyACM0', baudRate: 9600 })
// use ReadlineParser, so that we receive a full lines
const reader = port.pipe(new ReadlineParser({ delimiter: '\r\n' }))

// a new line is sent whenever a pass is near the NFC reader
reader.on('data', async (data) => {  
  // verify pass here
})

The data sent comes from the nfc-message field of the pass, which in our case is the Stripe Subscription ID (starts with sub_).

We can use that ID to verify that the subscription status is active:

// in gate/src/index.ts

reader.on('data', async (subscription_id) => {
  // retrieve the subscription record`  
  const subscription = await stripe.subscriptions.retrieve(subscription_id)

  // check if subscription is active`  
  if (subscription?.status === 'active') { 
    // flash LEDs green, play sound, and trigger relay to unlock the door
    success(port)
    console.log(`Access allowed. id=${subscription_id}`)
  } else {
    // flash LEDs red and play sound  
    error(port)
    console.error(`Access denied. id=${subscription_id}, status=${subscription?.status}`)
  } 
})

The success logic will then open the door bolt by triggering the relay:

// in gate/src/index.ts

// setup a connection to the relay on GPIO #8
const relay = new Gpio(8)

// open the door bolt for 5 seconds`  
function success(port) {
  // turn relay on to unlock the door bolt
  relay.high()

  // in 5 seconds, turn relay off. 
  // this causes the door bolt to lock. 
  setTimeout(() => relay.low(), 5_000)
}

Conclusion

Using digital passes makes physical gating much simpler.

It allows merchants to sell and grant access completely digitally, and users don't have to deal with picking up, carrying, replacing, sharing and returning cards and keys.

It’s as easy as issuing a pass after payment, and adding an NFC reader to the entrance to verify the status of payment.

Special thanks to Bill Scott at DotOrigin for sharing his knowledge on this topic.

Rust on a $2 dev board

Joshua Nussbaum — Fri, 13 Dec 2024 03:00:21 +0000

Rust is a great option for embedded computing, especially for small devices like ESP32.

There is a very inexpensive dev board, called ESP32-C3 Super Mini which sells for ~$2 on AliExpress.

The chip is RISC-based, supports Wifi & Bluetooth, and includes a built-in LED - which we'll use in this project.

Installing Rust

First you'll need Rust on your machine.

The toolchain can be installed via Rustup, or (my preferred way) using asdf.

TIP: asdf is a great way to manage multiple versions of programming language tools.

To install with asdf:

# add rust plugin
asdf plugin-add rust https://github.com/asdf-community/asdf-rust.git

# install rust
asdf install rust 1.81.0

# set default version
asdf global rust 1.81.0

Create the project

Let's create the project folder structure.

We can start with the template:

$> cargo generate esp-rs/esp-idf-template cargo

⚠️   Favorite `esp-rs/esp-idf-template` not found in config, using it as a git repository: https://github.com/esp-rs/esp-idf-template.git
🤷   Project Name: blink
🔧   Destination: some/path/blink ...
🔧   project-name: blink ...
🔧   Generating template ...
✔ 🤷   Which MCU to target? · esp32c3
✔ 🤷   Configure advanced template options? · false
🔧   Moving generated files into: `some/path/blink`...
🔧   Initializing a fresh Git repository
✨   Done! New project created some/path/blink

We'll need access to the HAL (hardware abstraction layer), so install the esp-idf-hal crate too:

cd blink
cargo add esp-idf-hal

The Code

Now add this to src/main.rs to blink the LED:

use esp_idf_hal::delay::FreeRtos;
use esp_idf_hal::gpio::*;
use esp_idf_hal::peripherals::Peripherals;
use log::info;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    // enable logging
    esp_idf_svc::log::EspLogger::initialize_default();

    // get peripherals
    let peripherals = Peripherals::take()?;

    // built-in LED is GPIO8
    let mut led = PinDriver::output(peripherals.pins.gpio8)?;

    // alternate between high and low, with delay of 1s
    loop {
        info!("high");
        led.set_high()?;
        FreeRtos::delay_ms(1000);

        info!("low");
        led.set_low()?;
        FreeRtos::delay_ms(1000);
    }
}

Running the code

Connect the dev board to USB, and then flash it with:

cargo run

The LED should now be blinking, and the message "HIGH"/"LOW" will be displayed in the terminal.

Happy hacking ✌️

P.S. Here's the source code:
https://github.com/joshnuss/esp-blink-rs

Math concepts explained with JavaScript

Joshua Nussbaum — Wed, 18 Sep 2024 07:20:43 +0000

Learning mathematical notation can feel intimidating.

So I created list of JS code examples for common math symbols:

https://math4devs.com

PRs welcome!
https://github.com/joshnuss/math4devs.com

Is rewriting software bad?

Joshua Nussbaum — Tue, 20 Aug 2024 16:01:01 +0000

"The universe likes nothing more than to transform that which was, into that which will be." - Marcus Aurelius

How did our code get so complicated?

Over time, many small well-intentioned changes pile up, they compound, and eventually bring on accidental complexity. Stuff that was once easy to do, becomes harder. The complexity tax kicks in and everything starts feeling like a heavy lift.

So, what can we do?

We've all heard that rewriting software is dangerous, that it wastes valuable time. "If it ain't broke don't fix it", right?

I'm here to tell you, I've rewritten software, and it made everything much better and easier to work with.

When done properly, a rewrite can free up a lot of energy that was lost to dealing with the complexity. It removes the complexity tax and makes the business's goals cheaper.

Sure, it's no silver bullet - nothing is - but over the course of building a system, we learn new things. These lessons need to be factored back in to the code, not just in incremental steps, but also by making their way back into the design.

To change? or to stay the same?

Basecamp was re-written 3 times. Yankee Stadium was rebuilt in 2008.
But many banks still run COBOL systems written in the 1960's.

So, who is right?

There is no hard and fast rule. Every situation is different. Everyone should analyze their specific situation and decide for themselves. Refactoring is enough in most cases.

And re-writing isn't a binary thing either. It's totally valid to re-write one part and refactor another. It's just another tool to have in the tool belt.

Re-write indicators

Here are some indicators that a rewrite is worth considering:

Have easy things become difficult?
There could be incorrect or missing abstractions. The abstractions may have once been correct, but wore down and no longer fit.
Are upcoming changes costly?
If new features are on the horizon and they are expected to be difficult, it could be that a re-write will make that easier.
When making changes, do they cause unexpected impact in unrelated places?
Dependencies between parts may not be clearly specified.
Is production tracing relied on heavily to verify how things works?
The complexity may have gotten so out of hand, devs are having a hard time understanding it. So they rely on logs to understand how the system works. Re-writing can bring back clarity to the design.
Can some changes only be accomplished by specific people?
There could be tribal knowledge or optimizations that are non-obvious. Re-writing can re-organize the abstractions and make them clearer, removing the need for tribal knowledge.
Is more time spent on feature development or maintenance?
Constant maintenance can be thought of a design defect. It's a good idea to build features into the system to reduce maintenance.
Do upgrades break things that used to work?
The system might need better verifiability. It could be missing automated tests, monitoring, or a paced rollout.

Refactor vs. Re-write

When should you use one over the other?

Both are methods of improving code. They are just on different sides of the "improvement scale".

Think of refactoring like renovating a house. Rewriting is like rebuilding the house.

Always prefer small renovations where possible, they're cheaper and less risky. But many renovation jobs might be more expensive than a rebuild.

For example, renovating a 2-bedroom home into an 8-unit residential building wouldn't make sense, because it needs a different type of foundation.

Ironically, it's usually the more important and successful stuff that is worth rebuilding, like the New York Yankees rebuilding Yankee Stadium in 2008. It's not that the old Yankee Stadium wasn't selling out - it was quite successful - that's what made it worth rebuilding.

Common arguments against re-writes

If it ain't broke, don't fix it.
Don't forget to consider the time spent on it. That may indicate that it is breaking from a cost perspective.

Won't re-writing waste valuable time?
Consider how much time is currently spent by not improving it?
Or, how much time could be saved if it was improved?

Why spend time on something that doesn't improve the business?
The goal of re-writing is to improve the business. By re-writing we are protecting a valuable asset, reducing labor, and freeing devs to work on other impactful things for customers.

After this re-write, what stops you from wanting another?
If a system warrants change then please re-write it again. As many times as it is valuable. Rewrite is just a synonym for improvement.

Customers don't care about code quality, they just want features.
The state of the code is the ability to ship new features. Customers may not know about code quality directly, but indirectly it impacts them a lot.

Our customers want a stable system.
Re-writing can be done while maintaining stability.

This system took years to build, won't it take years to rewrite?
It shouldn't, when done correctly. Rewriting is about compacting existing code and decisions into something simpler. It doesn't mean re-visiting past decisions.

The people that wrote this aren't here anymore, won't their knowledge be lost?
If their knowledge isn't codified in the system, in its documentation, or in its tests, then technically it's already been lost.

When to avoid the rewrite

When refactoring will do the job.
When the system is humming along without any problems.
When the people doing the rewrite aren't experienced yet. It's best to avoid rewriting a system before deeply understanding how it works. See: Chesterton's Fence
When it's just to use a different stack.
When the system isn't important. It's probably not worth investing the energy. Better to find something else that is important and improve that.
When there isn't a culture that values continuous improvement. If so, cultivate that first.

Summary

Ironically, when we try to stabilize a code-base by avoiding change, we increase the cost of changes, fear of change sets in, and it can end up hurting the resiliency of the system.

Incremental change is great, but it's not enough. The lessons we've learned over time need to make their way back into the design.

Re-writing is a great way for systems to remain relevant and keep costs down.

Don't believe the negative press it gets, it can save companies a lot of money.

Using experiments to ship faster

Joshua Nussbaum — Tue, 02 Jul 2024 16:47:00 +0000

Has this ever happened to you?

You're eager to start coding, so you open your editor and start smashing the keyboard. After a few weeks something unexpected happens, you encounter a major blocker.

Now you have to rework the codebase to get around the problem and a lot of high quality work gets scrapped.

This is very expensive and wasteful and happens all too frequently. But there is a way to reduce the chance this happens.

Avoiding "Fake progress"

When a project starts, there can be pressure to show fast progress.

But unfortunately, not all progress is equal.

Quick progress might make your stakeholders happy early on.

But at what expense?

If it's at the expense of completing the project, or just delaying the harder parts for later, then it can be considered "fake progress".

If we start out by building the obvious parts we already know how to do - are we really making meaningful progress? or just delaying the uncertainty?

What if we could change that?

Finding the Real work

Meaningful progress comes from solving difficult issues as early as possible. This is real work. It can reduce the cost of projects by orders of magnitude.

Because the faster we can locate real problems, and deal with them, the more meaningful headway we'll make.

What we need is a way to locate the biggest unknowns, frictions, and blockers as early as possible.

Improving work with experiments

One solution is to make a list of the hard parts (aka "unknowns") and experiment with those before you start writing high quality code.

These experiments are great, because with just a small amount of work they can remove large uncertainties from the project. They allow us to encounter uncertainties as early as possible, and eliminate them before they become costly blockers.

Instead of starting a project by writing code in a complex code base and wasting energy on integration and quality. Experimenting allows us to test problems in isolation, without the cost of integration. This keeps re-work low, because we're not undoing complex production code written at a high quality bar.

Once most of the unknowns are resolved, coding becomes a lot easier. It's just a matter of connecting the discovered solutions together, just like snapping together a bunch of LEGOs.

How to experiment

Next time you're starting a project, do this:

Collect a list of unknowns. These are things you think will be hard, or haven't done before.
Prioritize the list to tackle the most critical issues first.
Estimate how much each experiment will take. For example, 1-2 hours each. We don't want to spend forever on it.

Then for each experiment:

Build a minimal solution, being mindful of the timebox.
Capture the result. Either in a GitHub repo or a code snippet on your machine.
Document the solution or any caveats encountered.

Once you've worked through your list, and assuming you haven't encountered any major blockers, you're ready to start building! yay

Finding success

To ensure your experiments are successful, here's some things to be mindful of:

Be careful of time management

Don't overdo it. For a 6 week project, a good number of experiments is 10-15. These should take 1-3 days to finish. It's important to timebox these.

Long experiments are bad experiments

Keep your experiments small. Break them into smaller chunks if needed. If they're taking too long, it could be a tell that your project is too big and that the scope should be reduced.

Don't experiment with obvious things

If you know how to do it, it's not unknown anymore. For example, if you've built a login form before, no need to spend an experiment on that. Focus on stuff you don't know.

Be careful when re-using an experiment

Sometimes it can helpful to build a series of experiments, where each one depends on the code of the last, but sometimes it's not. Remember to always consider what the integration cost is. A key point of experimenting is avoiding the cost of connecting parts together.

Keep the quality low

Don't write clean code. Don't write DRY or SOLID code. Don't write tests. The only thing we want is a working solution. It can be super ugly. Worry about quality later, when you start building.

Conclusion

Reducing the uncertainty in a project, is more valuable than any TODO you can check off.

And you'll end up shipping projects much faster too!

Happy coding ✌️

WebAssembly: byte-code of the future

Joshua Nussbaum — Mon, 14 Aug 2023 14:41:03 +0000

Ever since Netscape launched JavaScript, there were some developers that liked it and others that didn't.

Regardless of which side you're on, I think we can all agree that it would be good if browsers supported more programming languages.

This is the promise of WebAssembly: Providing a generic runtime that any programming language can compile to.

Past Attempts

In the earlier days of the web, extensions were attempted with Java Applets and Microsoft ActiveX. But both were plagued by security issues and eventually dropped. The problem was they executed without access controls, which became a massive attack surface.

Later, Macromedia Flash and Silverlight had some success, but eventually met the same tragic fate. They both lacked an open standard, which made it hard for browser and OS vendors to support.

What is WebAssembly?

WebAssembly (aka WASM) is an open standard byte code format that works in all browsers. It's a low-level binary format and execution engine, conceptually similar to Oracle's JVM or Microsoft's CLR.

It's designed from the ground up to be hosted and safe. It cannot access the machine's memory or hard drive. Only the host can decide what APIs to expose.

WASM is a portable format, so it can support many programming languages. Think Rust, Ruby, Python and even JavaScript can be compiled to WASM byte code.

Though it was originally designed to target the browser, it works well outside the browser too.

It can run on the server, in the cloud, in hardware devices, or used a plugin system.

Writing WASM

There are several ways to create a .wasm file:

Write it by hand. (not recommended)
Write it with Wasm Text Format.
Use a higher level language like AssemblyScript, Rust, Ruby, etc.. and then compile it.

I'll show you a few examples:

Wat is WAT?

The WASM specification provides a text-based format for defining WASM modules that is called WAT (WAsm Text format). It uses S-expresions, similar to Lisp or Clojure.

Here's what a basic module looks like:

; define a module
(module
  ; define a function called "add"
  ; it takes 2 params:
  ; - $a is a 32-bit integer
  ; - $b is a 32-bit integer
  ; it returns an 32-bit integer
  (fun add (param $a i32) (param $b i32) (result $i32)
    ; load param $a onto the stack
    local.get $a

    ; load param $b onto the stack
    local.get $b

    ; perform 32-bit integer "add" operation
    i32.add

    ; the last value on the stack is returned
    ; which is the result of the `i32.add`
  )
)

The .wat file can be compiled to a .wasm using wat2wasm which is part of the WebAssembly Toolkit CLI tools:

# outputs example.wasm
> wat2wasm example.wat

Now the .wasm can be executed from any host. It can even be executed from the command line using wasmtime:

# invoke "add" function, and pass args 1,2
> wasmtime example.wasm --invoke add 1 2
3

AssemblyScript

There is also a higher-level language called AssemblyScript. It's like TypeScript for WebAssembly.

If we re-write the add() function from the previous section with AssemblyScript, it would look like this:

// in add.ts
export function add(a: u32, b: u32): u32 {
  return a + b;
}

As you can see, it's much more readable now.

To compile it, use AssemblyScript's compiler asc:

pnpm install -D assemblyscript
pnpm run asc add.ts --outFile=math.wasm

Comparing formats

To compare AssemblyScript to WAT, I built a little tool:

https://assemblyscript-play.vercel.app

You can also use the CLI wasm2wat to compare formats:

# outputs .wat format
wasm2wat math.wasm

Runtime execution

Just like there are many ways to compile wasm, there are many ways to execute it too.

Using WebAssembly in the browser

To use the WebAssembly API in the browser, first load the assembly:

// fetch .wasm file
const response = fetch('/path/to/some.wasm')

// instantiate module with streaming
const module = WebAssembly.instantiateStreaming(response)

Then, call one of the exported functions:

const result = module.instance.exports.add(1, 2)

An optional API can be passed into the module too:

// fetch .wasm file
const response = fetch('/path/to/some.wasm')

// instantiate module and pass an api
const module = WebAssembly.instantiateStreaming(response, {
  imports: {
    // share console.log
    log: console.log
  }
})

Using WebAssembly on the server

WebAssemblies can be executed on the server too. The API is virtually identical to the browser.

The only difference is that instead of fetching the .wasm from a server using a URL, it can be read from the disk using fs.readFile():

import fs from 'fs'

// read .wasm file
const bytes = await fs.promises.readFile('/path/to/some.wasm')

// instantiate the module
const module = WebAssembly.instantiate(bytes)

Then, call one of the exported functions, just like we did in the browser:

const result = module.instance.exports.add(1, 2)

It's also possible to do this from many other languages. For example rust, ruby, python or from the CLI.

Using WebAssembly in the Cloud

Another big use-case for WASM is the cloud.

It has some advantages over JavaScript cloud functions:

No cold starts: The host only has to load a .wasm file instead of full app. Typical JS apps have many files to load, which takes a long time.
Faster deploys: All that gets uploaded is a simple binary.
Polyglot hosting: All languages that compile to WASM can be deployed to the cloud without requiring any special runtime.
Snapshots: Execution can be snapshotted. For example, an app that does expensive work during initialization can be snapshotted. Then future requests can start with the snapshot, eliminating the expensive startup time.

A great example of WASM in the cloud is Fermyon. It's like AWS Lambda but for WebAssembly.

To use Fermyon, install their CLI spin.

Then create a new project:

# create a new spin project
# template is "http-js"
# project name is "spin-example"
spin new http-js spin-example
cd spin-example

# install dependencies
npm install

Then define a handler in src/index.js:

const encoder = new TextEncoder()

export async function handleRequest(request) {
  return {
    status: 200,
    headers: { "content-type": "text/plain" },
    body: encoder.encode("Hello World").buffer
  }
}

To run in dev mode:

spin watch

To deploy to The Cloud™, run spin deploy:

spin deploy

Notice how that deploy was instant?

Gotchas

There are still a couple rough edges of of WASM:

WebAssembly is still kind of new and in active development. Though it is improving rapidly.
Full support is not yet available for some programming languages.
WASM doesn't have basic data types like strings or a standard library. This is by design. Languages are expected to be provide their own standard library.
Because a "standard library" needs to live inside your .wasm, it can make file size large.

Most of these will be resolved with time.

The future

Over the past few years WebAssembly has made a lot of progress.

Eventually all languages will have compilation targets and runtimes for hosting it (if they don't already). This will enable all languages to run in the browser, server, or even in hardware.

It might also bring on new types of programming languages that are designed for a WebAssembly-first world.

Recurring payments with SvelteKit + Stripe

Joshua Nussbaum — Mon, 10 Jul 2023 11:44:06 +0000

When I built my last SaaS, I made one mistake: I launched without integrated payments.

At the time, it didn't seem like the biggest unknown compared to building features. I figured it could always be added later.

But it meant manually sending invoices and e-mail reminders and making phone calls about overdue payments. It wasn't that fun.

In hindsight, I learned that payment is the validation that the SaaS is working. Pushing it off just delays that important signal.

The good news is: it's easy to avoid the mistake I made. Stripe subscriptions can be added to your SvelteKit site in an afternoon.

Note: An alternative method is Stripe Checkout. Need help choosing?

Payment flow

For a customer to successfully pay for a subscription, the following steps are needed:

Create a customer record in Stripe.
Create a subscription record in Stripe. It will have a status of incomplete until payment is completed.
Display a payment form using Stripe's <PaymentElement/> component.
Handle the payment form submission and use Stripe's API to complete payment.
Handle webhooks to provision the subscription.

Project configuration

First, add these dependencies to your SvelteKit app:

# `stripe` is the official node.js package.
# `svelte-stripe` is a community maintained wrapper.
pnpm install -D stripe svelte-stripe

Then define environment variables in .env:

# Stripe secret key. Can be found at: https://dashboard.stripe.com/apikeys
SECRET_STRIPE_KEY=sk_...

# Stripe public key
# The PUBLIC_ prefix allows Svelte to include it in client bundle
PUBLIC_STRIPE_KEY=pk_...

# domain to use for redirections
DOMAIN=http://localhost:5173

You'll probably need to call the Stripe API from multiple places within your app, so it's a good idea to centralize the Stripe client:

// in src/lib/server/stripe.js
import Stripe from 'stripe'
import { env } from '$env/dynamic/private'

// export the stripe instance
export const stripe = Stripe(env.SECRET_STRIPE_KEY, {
  // pin the api version
  apiVersion: '2022-11-15'
})

Then, any time you want to access Stripe, import $lib/server/stripe:

// import singelton
import { stripe } from '$lib/server/stripe'

// Do stuff with Stripe client:
//
// stripe.resource.list(....)
// stripe.resource.create(....)
// stripe.resource.update(....)
// stripe.resource.retrieve(....)
// stripe.resource.del(....)

Creating the customer

If your app has authentication, then you already have the customer's name and e-mail address.

If not, you can display a form to capture it:

<!-- in src/routes/checkout/+page.svelte -->
<h1>Checkout</h1>

<!-- posts to default form action -->
<form method="post">
  <input name="name" required placeholder="Name" />
  <input name="email" type="email" required placeholder="E-mail" />

  <button>Continue</button>
</form>

Then on the server-side, create the Stripe customer and store the customer id in your database. In our case, since there's no database, we'll place it in a cookie instead:

// in src/routes/checkout/+page.server.js
import { stripe } from '$lib/stripe'
import { redirect } from '@sveltejs/kit'

export const actions = {
  // default form action
  default: async ({ request, cookies }) => {
    // get the form
    const form = await request.formData()

    // create the customer
    const customer = await stripe.customers.create({
      email: form.get('email'),
      name: form.get('name')
    })

    // set a cookie
    cookies.set('customerId', customer.id)

    // redirect to collect payment
    throw redirect(303, '/checkout/payment')
  }
}

Creating the subscription

Now that we have a customer, the subscription can be created on their behalf.

Subscriptions are keyed to a specific product and price. The product would be something like "Basic Plan" or "Enterprise Plan". Products can have multiple prices, for example the monthly price of the Basic Plan might be $20, but the yearly price is $100. Each are separate price IDs.

It's best to store pricing in the database or in a config file, but for demo purposes, we'll pass it as a param in the URL:

// in src/routes/checkout/payment/+page.server.js
import { stripe } from '$lib/stripe'
import { env } from '$env/dynamic/private'

export async function load({ url, cookies }) {
  // pull customerId from cookie
  const customerId = cookies.get('customerId')
  // pull priceId from URL
  const priceId = url.searchParams.get('priceId')

  // create the subscription
  // status is `incomplete` until payment succeeds
  const subscription = await stripe.subscriptions.create({
    customer: customerId,
    items: [
      {
        price: priceId
      }
    ],
    payment_behavior: 'default_incomplete',
    payment_settings: { save_default_payment_method: 'on_subscription' },
    expand: ['latest_invoice.payment_intent']
  })

  return {
    clientSecret: subscription.latest_invoice.payment_intent.client_secret,
    returnUrl: new URL('/checkout/complete', env.DOMAIN).toString()
  }
}

The endpoint returns two things:

clientSecret: A token that represents the payment intent. It's needed by Stripe Elements.
returnURL: The URL of our thank-you page. The user will be redirected here once payment is successful.

Payment form

In the payment form, the <PaymentElement> component will handle displaying all the payment options. This allows the customer to pay with a credit card or any of the supported payment methods in their region.

<!-- in src/routes/checkout/payment/+page.svelte -->
<script>
  import { PUBLIC_STRIPE_KEY } from '$env/static/public'
  import { onMount } from 'svelte'
  import { loadStripe } from '@stripe/stripe-js'
  import { Elements, PaymentElement } from 'svelte-stripe'

  // data from server
  export let data

  // destructure server data
  $: ({ clientSecret, returnUrl } = data)

  // Stripe instance
  let stripe

  // Stripe Elements instance
  let elements

  // when component mounts
  onMount(async () => {
    // load the Stripe client
    stripe = await loadStripe(PUBLIC_STRIPE_KEY)
  })

  // handle form submission
  async function submit() {
    // ask Stripe to confirm the payment
    const { error } = await stripe.confirmPayment({
      // pass instance that was used to create the Payment Element
      elements,

      // specify where to send the user when payment succeeeds
      confirmParams: {
        return_url: returnUrl
      }
    })

    if (error) {
      // handle error
      console.error(error)
    }
  }
</script>

<h1>Payment</h1>

{#if stripe}
  <form on:submit|preventDefault={submit}>
    <!-- container for Stripe components -->
    <Elements {stripe} {clientSecret} bind:elements>

      <!-- display payment related fields -->
      <PaymentElement />
    </Elements>

    <button>Pay</button>
  </form>
{:else}
  Loading Stripe...
{/if}

Completing the payment

Stripe will send the user to our "thank you" page and the payment intent ID is passed along as a query string.

The URL will look like this: http://localhost:5173/payment/complete?payment_intent=pi_xyz123

Using the payment intend ID, we can check on the payment's status and provision the account if it was successful.

// in src/routes/checkout/complete/+page.server.js
import { stripe } from '$lib/stripe'
import { redirect } from '@sveltejs/kit'

export async function load({ url }) {
  // pull payment intent id from the URL query string
  const id = url.searchParams.get('payment_intent')

  // ask Stripe for latest info about this paymentIntent
  const paymentIntent = await stripe.paymentIntents.retrieve(id)

  /* Inspect the PaymentIntent `status` to indicate the status of the payment
   * to your customer.
   *
   * Some payment methods will [immediately succeed or fail][0] upon
   * confirmation, while others will first enter a `processing` state.
   *
   * [0] https://stripe.com/docs/payments/payment-methods#payment-notification
   */
  let message

  switch (paymentIntent.status) {
    case 'succeeded':
      message = 'Success! Payment received.'

      // TODO: provision account here

      break

    case 'processing':
      message = "Payment processing. We'll update you when payment is received."
      break

    case 'requires_payment_method':
      // Redirect user back to payment page to re-attempt payment
      throw redirect(303, '/checkout/payment')

    default:
      message = 'Something went wrong.'
      break
  }

  return { message }
}

And a simple "thank you" page UI might look like:

<-- in src/routes/checkout/complete/+page.svelte -->
<script>
  export let data
</script>

<h1>Checkout complete</h1>

<p>{data.message}</p>

Handling webhooks

There's no guarantee the user makes it to the "thank you" page.

It's possible they closed their browser or their internet cuts out because someone on their network is downloading too many torrents. That's why it's important to handle Stripe's webhooks too.

In our SvelteKit app, we can add an endpoint to handle webhooks:

// in src/routes/stripe/webhooks/+server.js
import { stripe } from '$lib/stripe'
import { error, json } from '@sveltejs/kit'
import { env } from '$env/dynamic/private'

// endpoint to handle incoming webhooks
export async function POST({ request }) {
  // extract body
  const body = await request.text()

  // get the signature from the header
  const signature = request.headers.get('stripe-signature')

  // var to hold event data
  let event

  // verify the signature matches the body
  try {
    event = stripe.webhooks.constructEvent(body, signature, env.SECRET_STRIPE_WEBHOOK_KEY)
  } catch (err) {
    // warn when signature is invalid
    console.warn('⚠️  Webhook signature verification failed.', err.message)

    // return, because signature is invalid
    throw error(400, 'Invalid request')
  }

  /* Signature has been verified, so we can process events
   * 
   * Review important events for Billing webhooks:
   * https://stripe.com/docs/billing/webhooks
   */
  switch (event.type) {
    case 'customer.subscription.created':
      // Subscription was created
      // Note: status will be `incomplete`
      break
    case 'customer.subscription.updated':
      // Subscription has been changed
      break
    case 'invoice.paid':
      // Used to provision services after the trial has ended.
      // The status of the invoice will show up as paid. Store the status in your
      // database to reference when a user accesses your service to avoid hitting rate limits.
      break
    case 'invoice.payment_failed':
      // If the payment fails or the customer does not have a valid payment method,
      //  an invoice.payment_failed event is sent, the subscription becomes past_due.
      // Use this webhook to notify your user that their payment has
      // failed and to retrieve new card details.
      break
    case 'customer.subscription.deleted':
      if (event.request != null) {
        // handle a subscription canceled by your request
        // from above.
      } else {
        // handle subscription canceled automatically based
        // upon your subscription settings.
      }
      break
    default:
      // Unexpected event type
  }

  // return a 200 with an empty JSON response
  return json()
}

To test the webhook in development mode, a proxy is needed to tunnel events to our local machine. Since we're using localhost and not on the public internet.

Fortunately, Stripe's CLI can do just that:

# login to your account
stripe login

# forward webhook events to your localhost
stripe listen --forward-to localhost:5173/stripe/webhooks

stripe listen will print out a "Webhook Secret" (it starts with whsec_...). Make sure to add that to the .env and restart the dev server.

# in .env
SECRET_STRIPE_WEBHOOK_KEY=whsec_...

That's it folks. You now have subscriptions in your SvelteKit app!

For the complete source code, see:
https://github.com/joshnuss/sveltekit-stripe-subscriptions

Conclusion

Subscriptions are the ultimate validation for your SaaS app. It's the proof there's demand for your idea.

Without it, you'd have to resort to a more manual process and hoping people pay on time. It's better to get that validation as early as possible.

Even if people don't buy, it's better to know that early, rather than hope it may happen later. At least then you can start pivoting.

Happy hacking!

Using Prisma with SvelteKit

Joshua Nussbaum — Tue, 27 Jun 2023 18:26:31 +0000

Data is a critical part of every web app. Whether you're building a SvelteKit app to capture form inputs, visualize some data, or provide a dashboard to your users.

But dealing with databases can be challenging. Each database has it's own slightly different APIs. You need to write a lot of database access code and keep database schemas up to date. That work adds up.

That's why I like Prisma, it's a developer friendly solution that simplifies many of the pain points of working with databases.

What is Prisma?

Prisma is an ORM (object-relational mapper). It helps apps talk to databases. Kind of like a middleman between your JavaScript code and the underlying database.

It can read rows from the database and turns them into JavaScript objects (hydration). And vice-versa, it can take JavaScript objects and update the database or create new records. And it supports many types of databases.

Code generator

In Prisma, models (aka tables) are defined in a file called schema.prisma. Then you run prisma generate to generate a custom client for your app.

So you can think of Prisma as a kind of code generator.

Schema syncing

Prisma keeps the database schema up-to-date by syncing changes.

It supports two styles:

push: In this style, the schema.prisma is the source-of-truth. Additive changes, like adding a new table or a new column can be handled easily. It's the recommended approach during the prototype phase. But it's not ideal for more complex changes, like changing a data type.
migrate: In this approach, the migration scripts are considered the source-of-truth. It provides a fine-grained control over schema changes. This is recommended for production apps.

Setup

To install the Prisma in a SvelteKit app, run:



pnpm install -D prisma @prisma/client

Then initialize the project:



pnpm prisma init

This does 2 things

It creates a prisma/schema.prisma where models can be defined.
It adds an environment variable DATABASE_URL to .env.

The DATABASE_URL is the connection information Prisma needs to connect to the database.

For example, for Postgres, it would look like postgresql://USER:PASSWORD@HOST:PORT/DATABASE

For a full list of examples, see Supported Connection URLs.

Starting points

For new apps, the Prisma schema is written from scratch, but Prisma also supports importing an existing legacy database's schema too.

To start with an existing database, run prisma db pull to pull the existing schema into schema/prisma.schema.

To start with a new database, define models in prisma/schema.prisma and Prisma will sync the database schema for you.

Modeling

Here are some examples of models and indexes.

To define a basic model:



// in prisma/schema.prisma
model Product {
}

And fields can be added in the format name DataType:



model Product {
  // auto-incrementing primary key
  id Int @id @default(autoincrement())
  barcode String
  name String
}

To add an index:



model Product {
  // ...

  // define a unique index
  @@unique([barcode])

  // define a non-unique index
  @@index([name])
}

For more examples, see the docs on modelling or my course on Svelte + Prisma.

Syncing the database

To update the database schema, run:



pnpm prisma db push

Note: In some cases, a conflict can occur. For example, if a field's data type is changed from String to Int, there is no automatic way to reconcile that conversion. Prisma will notify you that there is a conflict and give you the option to reset the table (causing data loss), or you can use migrations for more control.

Browsing your database

Prisma comes with a handy database viewer that runs in the browser. It's a useful tool for inspecting database tables during development.

Here's a screenshot:

To view it, run:



pnpm prisma studio

Then visit https://localhost:5555

Accessing the database

It's likely that many places in your app will need to access the database. So, it's a good idea to centralize the db client.

To do that, create a file called src/lib/db.server.js and instantiate the client:



import { PrismaClient } from '@prisma/client'

// expose a singleton
export const db = new PrismaClient()

Now, anytime a connection is needed, import lib/db.server.js:



// import the centralized connection
import { db } from '$lib/db.server'

// then do stuff with the db connection
db.model.create(...)
db.model.update(...)
db.model.findMany(...)
// etc...

Note: Manual disconnection is rarely needed because Prisma automatically closes connections when the process ends.

Seeding data

It's much easier to set up developer machines when the app ships with a seed dataset. It also makes it easier to reset the environment when if it ever gets hosed.

In Prisma, seed data is defined in prisma/seed.js.

Here's an example:



// in prisma/seed.js

// import db client from previous step
import { db } from '$lib/db.server'

// create one record
await db.product.create({
  data: { barcode: '1234', name: 'Shirt' }
})

// or create records in bulk
await db.product.createMany({
  data: [
    { barcode: '5678', name: 'Pants' },
    { barcode: '91011', name: 'Socks' }
  ]
})

Then add a prisma section to package.json:



"prisma": {
  "seed": "vite-node ./prisma/seed.js"
}

Note: vite-node is used instead of node because our seed.js imports a vite alias $lib. So make sure to install vite-node too:



pnpm install -D vite-node

Then to load the seed data:



pnpm prisma db seed

Conclusion

Prisma is a great option for connecting SvelteKit projects with a database.

Prisma handles all the tricky stuff, like syncing your database schema and generating SQL queries, so you don't have to do that by hand.

It frees up developer time to focus on building features.

P.S. For a SvelteKit/Prisma repo with more examples, see joshnuss/markdown-mail.

React to Svelte Cheatsheet

Joshua Nussbaum — Tue, 08 Mar 2022 16:20:08 +0000

Are you coming to Svelte from a React background?

Here is a cheat sheet that lists the similarities and differences:

Full size image

PDF Version

Want more?

If you'd like to learn more about Svelte, check out my short video courses ✨

How is Svelte different than React?

Joshua Nussbaum — Fri, 05 Mar 2021 02:41:00 +0000

To get a better understanding of what Svelte brings us, it helps to step back and look at how we got here:

Back in the 90s, in the original version of the web, there was only HTML. Browsers displayed static documents without any interactivity. The only way to get updated information, was by reloading the page, or navigating to a new page.

Netscape and Internet Explorer

In 1995, Netscape released JavaScript, making it possible to execute code on the end-user's machine.

Now we could do things like:

Read a value from the DOM document.getElementById(...).innerText
Write a value to the DOM: document.getElemetById(...).innerText = ...
Get notified when something happens: <button onclick="alert(1995)">.

As developers began experimenting with this newfangled JavaScript thing, they found one aspect really tough: dealing with the differences between browsers. Both Netscape Navigator and Internet Explorer did things in their own way, making developers' responsible for handling those inconsistencies.

The result was code like:

var isNetscape, isIE

// figure out which browser this is
if (parseInt(navigator.appVersion) >= 4) {
  isNetscape = (navigator.appName == "Netscape");
  isIE = (navigator.appName.indexOf("Microsoft") != -1);
}

// branch based on browser type
if (isIE) {
  // The Internet Explorer Way™
} else if (isNetscape)
  // The Netscape Way™
}

This kind of browser detection code littered codebases everywhere. The extra branching was a nuisance, like a cognitive tax, making code harder to read and maintain. Translation: not fun.

jQuery

In 2006, John Resig released a compatibility layer called jQuery. It was a way to interact with the DOM without being an expert on browser feature matrices. It completely solved the inconsistency issue. No more if (isNetscape) or if (isIE) conditions!

Instead, we could interact with the page using CSS selectors, and jQuery dealt with the browser on our behalf.

It looked like this:

// read state
$('form input#email').val()

// write state
$('h1').text('Hello World!')

// get notified when something changes
$('button').on('click', function() {
  alert(2006)
})

But there were some challenges here too:

Selectors: If the structure of the markup changed - which happens a lot - it can break the CSS selector. For example, if you had a selector $('h1').., then you change the markup from <h1> to an <h2>, your selector just silently stops working, and you won't know until a user complains.
Syncing state: State changes happen in 2 directions, DOM-to-model and model-to-DOM. jQuery didn't provide any tooling here, leaving developers responsible for managing the synchronization logic on their own.

AngularJS

In 2010, Google launched AngularJS 1.x, a framework that helps with state management.

Instead of writing jQuery code, like:

<script>
  $('h1').text(someExpression)
</script>
<h1>

Expressions (called bindings) could be embedded directly inside the HTML:

<h1>{{someExpression}}<h1>

and Angular would sync those bindings for us.

Later, if we change our HTML, say by switching an <h1> to an <h2>, nothing breaks with the Angular version. There's no CSS selectors to update.

AngularJS components looked like this:

<!-- specify where our controller/component mounts to -->
<div ng-app="myApp" ng-controller="myCtrl">
  <!-- binding to a variable -->
  <h1>{{year}}</h1>
</div>

<script>
// declare a module
var app = angular.module('myApp', []);

// declare a controller
app.controller('myCtrl', function($scope) {
  // update a variable and trigger syncing
  $scope.year = 2010;
});
</script>

The magic was that anytime you changed something on the $scope variable, Angular would go thru a "digestion cycle", that recursively updated all the bindings.

But there were some problems here too:

It only worked in the browser: If a search engine crawled the page, it would see <h1>{{someExpression}}</h1> . Unless you're trying to rank high for {{someExpression}} , that's not great.

The digestion loop was inefficient: It takes time to walk the DOM tree and apply changes. Sometimes it could take multiple passes for all the values to settle.

React

In 2013, Facebook launched React, a library for syncing state with UI.

It solved some issues that AngularJS 1.x had. It's isomorphic, it can render HTML both on the server and in the browser, fixing the SEO problem. It also implemented a more efficient syncing algorithm called Virtual DOM.

Refresher: Virtual DOM keeps a copy of the DOM in memory. It uses the copy to figure out what changes (the delta), while limiting potentially slow interactions with the browser DOM. (Though it's been pointed out that this may be overhead.)

It's still conceptually similar to AngularJS, from a state management perspective. React's setState({value}) or in more recently, the useState() hook, is roughly equivalent to Angular's $scope.value = value.

Hook example:

// React state with hooks
const [year, setYear] = useState(null)

// setting state
// functionally equivalent to AngularJS's
// `$scope.year = 2017`
setYear(2017)

The problem

React relies on developers to signal when things change. That means writing lots of Hook code. But Hooks aren't trivial to write, they come with a bunch of rules, and those rules introduce a extra cognitive load into our codebases.

Svelte

In 2019, Rich Harris released Svelte3. The idea behind Svelte is:

What if a compiler could determine when state changes?
That could save developers a lot of time.

It turns out to be a really good idea. Being a compiler, Svelte can find all the places where our code changes state, and update the UI for us.

Example

Say we assign a variable inside a Svelte component:

<!-- a .svelte component -->
<script>
// assign a value
let year = 2019
</script>

<!-- this <h1> depends on `year` state -->
<h1>Hello {year}!</h1>

Svelte detects the let statement and starts tracking the variable. If we change it later, say year = 2021, Svelte sees the assignment = as a state change and updates all the places in the UI that depend on that binding.

Svelte is writing all the Hooks code for us!

Conclusion

If you think about it, a big part of a developer's job is organizing state, moving state back and forth between the UI and the model. It takes effort, and it's tricky to get right. By offloading some of that work to compile-time tools, we can save a lot of time and energy.

Another side effect is, we end up with less code. That makes our programs smaller, clearer to read, easier to maintain, cheaper to build, and most importantly: more fun to work with.

Want more?

If you'd like to learn more about Svelte, check out my short video courses ✨

Declarative controllers with Phoenix

Joshua Nussbaum — Tue, 24 Nov 2020 04:09:33 +0000

The other day I found myself needing to write a bunch of controllers. Maybe I was feeling lazy, but I really wanted to finish the work quickly. I thought about how I could wrap it up in one afternoon.

Maybe I could write a code generator? or some kind of library?

I decided to go the library route.

In the end, it allowed me to write about 10 controllers in a couple of hours, so I'm sharing it.

Anatomy of a controller

A controller action does 3 things:

Input: Passing params and data from conn to a context function.
Algorithm: the context function.
Output: Rendering a response based on the context function's result.

Let's use this create action as an example:

def create(conn, params) do
  # call context function
  case Catalog.create_product(conn.assigns.current_account, params) do
    # pattern match result
    {:ok, product} ->
      # rendering success
      conn
      |> put_status(:created)
      |> render("show.json", product)

    {:error, changeset} ->
      # rendering error
      conn
      |> put_status(:unprocessable_entity)
      |> render("error.json", changeset)
  end
end

In my case, all my controller actions would follow this structure.

Reusable logic

Each controller action is calling a context function and then pattern matching against the result. The result is always a tagged tuple like {:ok, data} or {:error, changeset}. So it seems the response handling could be shared between controllers.

We can extract the shared logic to a module:

defmodule Responder do
  # handle success
  def respond({:ok, record}, conn) do
    conn
    |> put_status(:created)
    |> render("show.json", record: record)
  end

  # handle error
  def respond({:error, changeset}, conn) do
    conn
    |> put_status(:unprocessable_entity)
    |> render("error.json", changeset: changeset)
  end 
end

Then our controller code can be simplified:

# import shared response logic
import Responder

def create(conn, params) do
  # call context
  Catalog.create_product(conn.assigns.current_account, params)
  |> respond(conn) # re-use response logic
end

def show(conn, params) do
  # call context
  Catalog.get_product(conn.assigns.current_account, params["id"])
  |> respond(conn) # re-use response logic
end

Way less repetition, it's starting to shape up.

A pattern emerges

All the actions now have a similar look:

def <action-name>(conn, params) do
  respond(conn, <context-function>.())
end

So why not distill it further with a macro:

defmacro defaction(name, fun) do
  quote do
    def unquote(name)(conn, params) do
      data = %{conn: conn, params: params, assigns: conn.assigns}
      respond(conn, unquote(fun).(data))
    end
  end
end

Then, replace def action_name(...) with defaction :action_name, ...:

defaction :index,  &Catalog.list_products(&1.params)
defaction :show,   &Catalog.get_product(&1.params)
defaction :create, &Catalog.create_product(&1.params["product"])
defaction :update, &Catalog.update_product(&1.params["id"], &1.params["product"])
defaction :delete, &Catalog.delete_product(&1.params["id"])

Now our controllers are completely declarative. Easier to read and less typing :)

Hex package

Since it worked out well for me, I open sourced it:

Repo: https://github.com/joshnuss/transponder
Hex package: https://hex.pm/packages/transponder

To set it up, install the hex package:

# in mix.exs, add to `deps`:
{:transponder, "~> 0.2"}

Then in any controller, import Transponder, passing the required format (JSON or HTML).

defmodule MyAppWeb.Admin.ProductsController do
  use MyAppWeb, :controller
  use Transponder, format: Transponder.JSON

  defaction :name, &Context.function(...)
end

Conclusion

The idea isn't a new one, it exists in Rails with make_resourceful and resource_controller.

The approach works well for controllers that follow the same pattern. It keeps controller code declarative, increases readability, and eliminates the need for testing controllers.

Of course for more intricate applications, hand-tuned response logic may work better. Nothing wrong with that.

P.S. It's still alpha software, but feel free to give it a try and open PRs

Happy hacking,

Create a blog with Sapper & Markdown: Tagging

Joshua Nussbaum — Thu, 29 Oct 2020 06:58:21 +0000

When dealing with lots of content, it's a good idea to have some categorization. One versatile approach to categorization is tagging. Nearly all blogs use it, and ours will too.

Note: If you prefer to watch rather than read, there's a screencast version here: https://youtu.be/PGLsFfBf1UA

Adding metadata

Continuing from Part 1, our blog repo has a /posts folder filled with Markdown files. Our first step will be to add a new field called tags to the "front matter" metadata in each markdown file.

---
title: Example Post
date: 2020-10-28
+tags: hello, world
---

# Example Title

...

Parsing tags

Sine the tags string is comma-delimited, it will need to be converted into to an array during the parsing phase.

// in src/posts.js
// transform is called once for each post
function transform({metadata}) {
  ...

  // the `tags` field is optional, so default to empty list
  let tags = []

  // check if `tags` field is defined on this post
  if (metadata.tags) {
    // split the tags string by comma, and trim away any extra spaces
    tags = metadata.tags.split(',').map(str => str.trim())
  }

  // return previous data and tags 
  return {...metadata, tags}
}

Listing tags

Now that each post has a cleaned up tags array. It's ready to be displayed on the /post/:permalink page.

<!-- src/routes/posts/[permalink].svelte -->
<script>...</script>

<h1>{post.title}</h1>

<!-- new component to show tag list -->
+<Tags tags={post.tags}/>

{@html post.html}

And the new <Tags/> component will be defined as:

<!-- src/components/Tags.svelte -->
<script>
  // take in tags as a prop
  export let tags
</script>

<nav>
  <!-- iterate through each tag -->
  {#each tags as tag}
    <!-- link each tag to /tag/:tag page -->
    <a href="/tag/{tag}">#{tag}</a>
  {/each}
</nav>

Listing posts by tag

To show all the posts for a given tag, we'll need a new page and some JavaScript logic to filter posts by tag.

First, lets define the findByTag() function. It will take the tag as a parameter and return the list of posts matching the tag.

// src/posts.js
export function findByTag(tag) {
  // filter out all posts that don't include the tag
  return posts.filter(post => !post.tags.includes(tag))
}

Then, define new page for /tag/:tag that will use findByTag() to locate posts:

<!-- src/routes/tag/[tag].svelte -->
<script context="module">
  import { findByTag } from '@/posts'

  export function preload(page) {
    // extract tag param
    const { tag } = page.params
    // find posts based on tag param
    const posts = findByTag(tag)

    // return props
    return { tag, posts }
  }
</script>

<script>
  // props are provided by preload() function
  export let tag, posts
</script>

<!-- show #tag as title -->
<h1>#{tag}</h1>

{#each posts as post}
  <!-- show each post -->
{/each}

Extracting a component

Lastly, since we are showing the list of posts on 2 pages /tag/:tag and /post/:permalink, it would be to avoid duplication and have a reusable component for listing posts. This will make it easier to adjust and style down the road.

<!-- src/components/PostList.svelte -->
<script>
  // it takes an array of posts as a prop
  export let posts
</script>

<!-- iterate thru each post and output an <article> tag -->
{#each posts as post}
  <article>
    <!-- link to /posts/:permalink page -->
    <a href={`/posts/${post.permalink}`}>
      <h2>{post.title}</h2>
      <p>{post.summary}</p>
    </a>
  </article>
{/each}

And then update the pages src/routes/posts/[permalink].svelte and src/routes/tag/[tag].svelte to use <PostList/> instead of {#each}.

<!-- use our new shiny component -->
<PostList {posts}/>

Summary

Our little blog is getting better! Now that we have tagging working, in the next post we'll explore adding syntax highlighting.

You can find all the code here:
https://github.com/joshnuss/blog-template

Happy coding! ✌

DEV Community: Joshua Nussbaum

Gating entrances with Stripe and NFC passes

Digital wallet passes

Integration

Building it

Architecture

Hardware

Requirements

Wiring diagram

PassNinja setup

Purchase flow

Door access control

Conclusion

Links

Rust on a $2 dev board

Installing Rust

Create the project

The Code

Running the code

Math concepts explained with JavaScript

Is rewriting software bad?

To change? or to stay the same?

Re-write indicators

Refactor vs. Re-write

Common arguments against re-writes

When to avoid the rewrite

Summary

Using experiments to ship faster

Avoiding "Fake progress"

Finding the Real work

Improving work with experiments

How to experiment

Finding success

Be careful of time management

Long experiments are bad experiments

Don't experiment with obvious things

Be careful when re-using an experiment

Keep the quality low

Conclusion

WebAssembly: byte-code of the future

Past Attempts

What is WebAssembly?

Writing WASM

Wat is WAT?

AssemblyScript

Comparing formats

Runtime execution

Using WebAssembly in the browser

Using WebAssembly on the server

Using WebAssembly in the Cloud

Gotchas

The future

Recurring payments with SvelteKit + Stripe

Payment flow

Project configuration

Creating the customer

Creating the subscription

Payment form

Completing the payment

Handling webhooks

Conclusion

Using Prisma with SvelteKit

What is Prisma?

Code generator

Schema syncing

Setup

Starting points

Modeling

Syncing the database

Browsing your database

Accessing the database

Seeding data

Conclusion

React to Svelte Cheatsheet

Want more?

How is Svelte different than React?

Netscape and Internet Explorer

jQuery

AngularJS

React