DEV Community: orliesaurus

Tests with Playwright + AI: Superpowers!

orliesaurus — Thu, 14 Mar 2024 18:19:44 +0000

This post is about a new plugin that we released to help Playwright users leverage AI Vision models to achieve more.

If you're in a rush you can skip the whole article and just jump to the code examples here: https://github.com/dashcamio/goodlooks?tab=readme-ov-file#examples

End-to-end tests (E2E tests) simulate how a real user interacts with a web application, from opening the browser to clicking buttons and filling out forms.

They aim to ensure the entire user journey functions as expected.

However, sometimes tests pass, and sometimes they fail for seemingly random reasons.

These are called flaky tests.

Flaky tests suck but there are many other things that are really hard to test. Here are some examples:

Application State: If you click play on a video, has the video started playing?
Image Contents: What's this image depicting? Does it make sense in the context of the title of the page?
Responsiveness: Given a mobile design, does it match the mobile rendered version in the viewport.
Accessibility: Is this specific UI element accessible according to best practices?

Flaky tests

Developers love things that work or don't because they can fix things, but flaky tests…frustrating. They introduce uncertainty into the testing process. Test either pass or don't, they can't possibly only pass sometimes!

And the cherry on top, you have to maintain a lot of tests through a framework…sometimes there are hundreds of tests and some are flaky…

The worst type of flaky test are the E2E ones (End-2-End/End-to-End tests)

Example: Imagine testing a car. A unit test might focus on ensuring the engine starts, while an E2E test would simulate a whole driving experience. The E2E test provides a broader view but is more complex and prone to disruptions from external factors like traffic lights. What happens if the traffic light breaks? What happens if there's a massive hole on the road where you're driving the car?

Managing tests: enter testing frameworks

Developers hate flaky tests, so to make things better, they invented tools to make their lives worse...I mean better.

These tools manage the execution of tests. They will tell you whether a test has passed or failed.

Playwright is one of the many testing frameworks out there. Specifically, this one has exploded in popularity.

It is specifically designed for web applications. It allows developers to write tests in JavaScript, Python, or TypeScript.

Playwright: why it makes sense and how can we make it better

Playwright is one of the latest testing frameworks for web apps, with decent in-built reporting capability.

It is a reliable and performant framework with support for multiple browsers, so you can install it and have the certainty that your tests will run on most browsers: write a test once and let it run in parallel through different browsers with almost no adjustments.

As a tester, you know you must write and maintain tests regardless of the framework. There are some rules that need to be maintained.

Test executions needs to start from a fresh slate

You can't start tests from a "dirty" environment, because that might impact how the test execution will be performed. Thus you will be able to set up a test environment as a user would experience it, the first time..and/or the N-th time around.

Tests need to be updated

Tests are often susceptible to changes in the application. Even minor UI tweaks, like button placement or text changes, can break the tests because they rely on specific interactions with CSS selectors. This means you need to update the tests frequently to keep them working.

Tests simulate real user journeys

Tests can involve many steps and interact with various parts of the application. This complexity makes them harder to understand, debug, and modify than more focused unit tests…and sometimes on a user journey you encounter things that a computer might not be able to simulate.

It…

gets…

complicated…

👉 And we know that user journeys are complex. How do you test that a video autoplay, or doesn't autoplay on page load?

👉 How do you ensure that the brand guidelines are respected?

Extending Playwright with AI

The more time is spent maintaining tests, the less time is spent on testing new features, and new user paths and ensuring the release of good quality software…

Thus, flaky tests are time suckers for developers: it takes time to investigate a flaky test and understand whether it is a false-positive or a real issue. When flaky tests are spotted, they might influence a whole set of tests that depend on them

Validate Web Pages with AI + Natural Language

Unreliable UI tests that break with every code change are really the worst. Some things that Playwright can't do well with test that require visual consistency. This can add a lot of extra work for QA and test developers.

There are workarounds but they might take you down a horrible nightmare. A time-consuming nightmare.

Introducing our Playwright plugin: Goodlooks

GoodLooks offers a revolutionary solution: visual validation with natural language.

Here's how simple it can be:

//import playwright
const { test, expect } = require("@playwright/test");

//import goodlooks
const goodlooks = require("goodlooks");

//use this API key or register for your own
goodlooks.configure("zpka_c0d0539ada014283bc974f0fd55835ea_2b745cbf");

expect.extend(goodlooks);

// write your first test that goes to a rick roll video on YouTube
test("rickroll", async ({ page }) => {
  await page.goto("https://www.youtube.com/watch?v=dQw4w9WgXcQ");
// write in natural language the body of the test
  await expect(page).goodlooks("video is not playing");
});

The outcome should be a message similar to the following:

✅ PASS. The page shows a video with the play button available and a timeline that is not progressing, indicating that the video is currently not playing.

The Problem with Static Tests

Traditional UI testing relies on static selectors. But what happens when things change?

Is that button really missing, or did the ID just change?
Does the layout adapt seamlessly for mobile devices?
Are the correct images displayed?

Validating these visual aspects with selectors alone is impossible. Manual testing is an option, but it's inefficient and prone to human error.

Natural Language to the Rescue

With an LLM, and more generally, AI, we can enable visual validation with natural language prompts.

Instead of writing code to target specific elements, you describe what you want to see on the page.

This approach offers several advantages:

Resilience to Code Changes: Tests remain functional even if the underlying code structure evolves.
Focus on Visual Quality: Validate the actual appearance of your webpage, ensuring a consistent user experience.
Simplified Testing: Write clear and concise prompts in plain English, eliminating the need for complex code.

...and even more importantly, the ability to test things that:

Testing subjective qualities like balance, alignment, and adherence to brand guidelines - things that are difficult to capture with code.

But with goodlooks it gets as simple as that:

const { test, expect, devices } = require("@playwright/test");

const goodlooks = require("goodlooks");
goodlooks.configure("zpka_c0d0539ada014283bc974f0fd55835ea_2b745cbf");

expect.extend(goodlooks);

test("ycombinator", async ({ page }) => {
  await page.goto("https://news.ycombinator.com");
  await expect(page).goodlooks(
    "there is an orange strip at the top of the page"
  );
});

Images content: Playwright can easily verify if an image exists, but not necessarily if it's the correct one. With this approach you can fully recognize specific images and confirm they're displayed in the right places. This is particularly useful for e-commerce sites or applications with dynamic content.

But with goodlooks you can simply do:

const { test, expect, devices } = require("@playwright/test");

const goodlooks = require("goodlooks");
goodlooks.configure("zpka_c0d0539ada014283bc974f0fd55835ea_2b745cbf");

expect.extend(goodlooks);

test("correct image appears", async ({ page }) => {
  await page.goto("https://eloquentjavascript.net/");
  await expect(page).goodlooks("there is bird on this page");
});

Accessibility testing: Playwright doesn't offer built-in features for accessibility testing, which ensures interfaces are usable by people with disabilities. You might need specialized accessibility testing tools.

In conclusion the future of UI Testing has started already

Test that flake are bad, but tests that are hard to maintain are worse.

Even more so, the inability to test certain things is even worse and very time-consuming because it relies on manual testing.

Obtaining feedback is crucial to ensure that users comprehend the content, can easily accomplish their objectives and tasks, and find your webpage appealing.

Due to the costs and delays involved, running frequent manual tests can be a challenge, but AI can provide assistance whereas a year or so ago, this was much harder to implement.

👉 Take a look at Goodlooks on Github:

dashcamio / goodlooks

Visually Validate Playwright Tests Without Flaky Selectors

Static selectors break with code changes and can't prove that a site "looks good". Is that button really missing or was the id changed? Is the site responsive on mobile? Is the correct image showing? These kinds of tests are impossible to validate with selectors alone and take a lot of time to test manually. GoodLooks.ai lets you visually validate your web pages with natural language prompts instead of selectors.

Check out our other products: TestDriver.ai and Dashcam.io.

Quickstart

git clone git@github.com:dashcamio/goodlooks.git
npm install
npx playwright test

Note that these examples use a demo key that gets rotated weekly; you'll want to create your own API KEY.

Examples

Element Visibility

Validate that a cookie banner shows up.

Input	Code
	const { test, expect } = require("@playwright/test"); const goodlooks = require("goodlooks"); goodlooks. …

View on GitHub

Build your own Raycast extension, step by step, tutorial

orliesaurus — Mon, 20 Nov 2023 23:36:27 +0000

I’m a huge user of Raycast: I use it for everything from window resizing, to code snippets, to screenshots and shortcuts to my Github favorites.

While I was creating my own extension Dashcam extension to capture videos, I thought, maybe I could write something so that anyone can learn how to make their extension!

I think it would become handy, eventually. This guide explains how to create and debug your Raycast extension’s while you learn how its ecosystem works.

All of what I wrote in this article can be achieved using 3 ingredients:

Raycast, your favorite code editor and the Dashcam screen recorder for developers!

Intro

Raycast is a fast, customizable macOS launcher that lets you quickly and easily create shortcuts to save time and make your workflow easier. This tiny, free app lets you open programs, search for files, and create keyboard shortcuts for literally anything! It has gained popularity as a powerful Spotlight alternative. This guide covers creating and publishing a Raycast extension from start to finish, adding a little oomph to traditional tutorials by leveraging videos and interactivity!

I hope this can help anyone get started build their own extension.

Getting started with your extension

We’re going to be using JavaScript to build our extension!

I assume you have already downloaded and set up to Raycast. This guide complements, but does not replace, the official Raycast documentation – so if you’re a complete beginner read it here.

In this article I will do a walkthrough of the full process of creating an extension from nada to hero!

Create your project

This is a Dash showing you how to create a project and extension in Raycast

I created a folder where I am going to initiate my Raycast project. To achieve this, I simply created an empty folder somewhere on my drive that I can get to easily

mkdir raycast-ext

Initiate a new extension

Next, as the Raycast documentation indicates, you have to create the scaffolding of your project.

Open Raycast and Type Create Extension

The Create Extension – Developer command shows up, run it by clicking Open Command

This part enables the proper project structure to be created by the Raycast app itself.

Then, go through the following screens and configure them as shown below.

Set up your extension details

These are the options I chose, but you can choose to pick whatever makes most sense for you:

– Organization: None

– Unless you’re part of an Organization – most likely scenario is that you are not at first, this article explains what teams are

– Template: Detail

– Extension Name: Extension Demo

– Description: This is just a demo

– Categories: Fun

– Location: Select the folder you created a moment ago

– Command name: Demo command

– Subtitle: Demo subtitle

– Description: This is just a test

After completing these fields, create the extension by using the key combo

⌘+Return

or click the Create extension text in the right corner

Congratulations! You’ll see in the next screen that the extension has been successfully created and registered inside the Raycast app!

Running the extension for the first time

Next, let’s run the demo extension for the first time!

To see your extension run for the first time, open the directory you created, locate the project, and run the command:

Pretty cool!

The extension is running, showing you a hello world message, the reason for that is that we chose a template in the previous step – we still haven’t touched the code!

So let’s do that next.

Running and editing the template

To build your own extension, you can use Raycast’s own SDK, which includes set of UI components that you can use to assemble your extensions.

Before we continue, get familiar with the Raycast SDK: There are multiple components in the SDK. You can find a listing here: https://developers.raycast.com/api-reference/user-interface

Another important thing is to become familiar with the extension folder structure: If you use an IDE editor like VScode, open your extension folder, and you should be presented with the following project structure:

Now, we’re ready to start developing our extension!

Inspecting the main file

If you open src/index.tsx you will see the following code:

```
import { Detail } from "@raycast/api";

export default function Command() {

return <Detail markdown="# Hello World" />;

}
```

To test this command again in Raycast, ensure you’re running it with npm in your terminal.

Type demo “Demo command” should show up and now hit return:

Building your own

Now let’s change it up: let’s build an extension that.. will fetch a random picture from a dog API, as it might bring a little happiness to the world!

We can call this extension “Dogjoy” or something funny like that.

Let’s create a new file called fetchdata.tsx inside the src folder

We’re going to import useFetch from the utils SDK and use it to call an endpoint.

Specifically, it is the dog.ceo API endpoint which returns random pictures of dogs, one at a time.

Installing Raycast helper library

Before we continue let’s raise a glass of your favorite cheering drink to ourselves

👏

We’re using the useFetch hook so this extension will use a helper library that we need to install called @raycast/utils

Using this helper library will allow us to use a custom React.js hook called useFetch: using this hook, we can execute an API request to an endpoint.

Let’s go ahead and install this library through npm by executing this in the root of our project:

npm install @raycast/utils

Calling the API

We specifically want to retrieve the message – which corresponds to the URL of the image – like in the code below.

    import { useFetch } from "@raycast/utils";

    export default function showDog () {

    console.log('Fetching API')

    return useFetch("https://dog.ceo/api/breeds/image/random").data.message;

    }

Next we need to call this function from the main file

Creating the command

Let’s open index.js and add the following code:

    import { Detail } from "@raycast/api";

    import showDog from "./fetchdata";

    export default function Command() {

    return <Detail markdown={`

    ## Random 🐶

    ![](${showDog()})`} />;

    }

This imports the showDog function from the fetchdata file, then wraps it around the Detail component, which renders, amongst other things, markdown!

We use markdown to render the image because it’s fast!

Debugging with the help of Dashcam

It’s never easy to fix issues in your extension, in fact there’s a whole community effort on Raycast’s community Slack trying to help each other to fix them.

While you’re developing, showing someone else what you were doing and went wrong can be quite powerful.

When you run this extension for the first time in developer mode, you will notice that when you run your extension, there are multiple console.log functions being called.

You might wonder: is this a bug?

The short answer is no. Here’s a Dash that shows you what I am talking about

Watch 4x fetch on Dashcam

I shared this code with someone who understands really well how the render method behind useFetch works, and they assured me that while the function might be re-rendered multiple times, the power of useFetch is that it only triggers one API call to your backend!

Let’s now change the URL on line 5 to another one. this time we’re retrieving memes from imgflip’s API:

    return useFetch("https://api.imgflip.com/get_memes").data.message;

Now run the extension again and see what happens!

Watch imgflip error on Dashcam

As you can see we’re getting an error because there is no object key named message.

If we want to use this API we need to extract the URL by changing the code to look like this


    return useFetch("https://api.imgflip.com/get_memes").data?.data.memes[Math.floor(Math.random() * 100)].url;

This retrieves one meme at random from the imgflip meme API.

Using Dashcam to check for bugs

Now you’re wondering, how can I verify that the API isn’t being called 4 times?

Good question and here’s the answer

You can verify this by replacing the URL on line 5 of fetchdata.tsx with a local endpoint running on your machine (localhost) through a simple HTTP server .

Let’s do this:

Watch npm install on Dashcam

What I did is the following:

I started a simple HTTP server and changed the fetch-able URL in fetchdata.tsx file to call my local server.

Then I look at the HTTP request logged by the local server and I see it’s only one.

Meanwhile the console.log has output 4 messages saying Fetching API that means, that although it’s re-rendering 4x the API call is only called one.

You can see how by using Dashcam, I am sharing the full context of what I am doing, this is very beneficial when debugging with others!

Now let’s put the files back to its initial state, so I can show some Dogs!

Commands

In Raycast, you can have multiple commands. Your extension might be using them to achieve numerous things.

In this extension we created we called initially the command “Demo” – let’s now change that so our extension is complete.

You can change commands and its associated data through the package.json file or the UI. I’ll do it in the editor – I am confident I can simply edit the data in this file and then reload the extension.

Publishing your extension: debugging build errors

The last part of this tutorial is the most fun one, publishing your extension.

To do this instead of running the code locally with npm run dev you will have to run it through npm run build

This will alert you if the code passes the build checks…

Surprise, it’s not passing the checks YET!

So let’s go ahead and get fixing it

First we’re going to add an interface

The full code should look like this:

    import { useFetch } from "@raycast/utils";

    interface DogAPIResponse {

    message: string;

    }

    export default function showDog () {

    const { data } = useFetch<DogAPIResponse>("https://dog.ceo/api/breeds/image/random");

    return data?.message;

    }

Publishing your extension onto the Raycast Github repo

Now that your extension is valid you can ship it to the Raycast extension repo, where all other extensions live!

You can run npm run publish to publish your extension now. You will be asked to authenticate with GitHub.

Raycast creates an open a pull request in their repository, on your behalf!

Conclusion

Hopefully, this article shows you how simple it is to create your first extension and publish it to the Raycast store.

This is a simple extension, you can add much more – especially fall back and error catching… but hopefully this gives you a good introduction to building extensions.

You’ve noticed that we had a couple of situations where we had to debug issues with the extension, luckily I was able to show you the issues using Dashcam to show you exactly how I solved them, it’s like a YouTube video but with better logs 😉 and context.

If you want to learn more about how to create & publish extensions on Raycast feel free to browse the documentation here.

If you’re interested in how Dashcam works and why it helps developers debug faster, you can find further details on the Dashcam website

👉 If you just want a Raycast PRO code to try Raycast PRO for free, ask in the comments!

Everything I learned debugging my first Box app

orliesaurus — Thu, 28 Sep 2023 17:36:13 +0000

Writing your first Box app is sort of magical; in a couple of hours, you can go from having nothing to integrating with a bulletproof cloud filesystem.

Wondering how I did it?

Well, strap in because we're about to take a magical tour through the Box SDK and navigate through the ocean that is its first developer experience.

What we're trying to do?

I will show you how to overcome the most common issues with the Box Node.js SDK, when building something for the first time.

By the end of this article, you'll be a certified Box ninja, able to effortlessly chop, kick, and grab data from Box with Javascript.

The Box SDK provides a sweet wrapper around the Box API, making incorporating fancy file features into your node apps simple.

Like most beautiful things in life, however, there are some gotchas when getting started that you will learn by reading this article, and you will be glad that you did.

By the way, I used Dashcam - the best screen recorder for developers - to take video clips of the flow and bugs discussed below!

Issue #1: Misconfigured Authorization Callback

Problem:

When developing your Box app, after creating an Oauth2 authentication page, you might encounter an error saying Redirect URI mismatch, as shown below:

Solution:

To solve this, please ensure that you have configured the redirect URI on the Box Developer platform to match the one URL in your code. This is the URL within your application that will receive OAuth 2.0 credentials and can be configured within the configuration tab of your app here

Issue #2: Wrong token

Problem:

When trying to retrieve information (after successful authentication) with the Box API, I am hitting an error about the token being improperly formatted, as shown below.

Error occurred: AssertionError [ERR_ASSERTION]: tokenInfo is improperly formatted. Properties required: accessToken, refreshToken, accessTokenTTLMS and acquiredAtMS.

Solution:

This error is caused by your secrets data: CLIENT_ID, CLIENT_SECRET, SECRETKEY need to be defined as strings.

Double-check and ensure that your token is wrapped in quotes in your .env file to prevent this error!

Issue #3: Creating items - lack of permissions

Problem:

When you try to create a folder or a file with the Box API you might encounter an API response similar to the below one and the file/folder does not get created.

An error occurred Error: Unexpected API Response [403 Forbidden | .0a9157099d2d6c5f27336708e21f80f90]

Solution:

To recover from this error, provide a higher auth scope to your app by navigating to the developer console and ensuring the "Write all files and folders stored in Box" is selected. You can see the solution in the video embedded above. Do not forget to restart your app and re-authenticate!

Below, you can see how the same issue happens when trying to upload a file:

Issue #4: Issues with webhook

This is a fun one because it contains multiple levels of problems into one!

Problem A):

Using the Box API, you can modify files and folders and create a webhook that alert you when certain actions occur. You can create a webhook through the API, but sometimes you will face the following error when attempting to set it up

Unexpected API Response [403 Forbidden | .0738507f87ab4740283c35d3701e5d9ad]

Solution A)

Most likely, you haven't given your Box App the permission to create webhooks.

This setting differs from the ones that let you create files/folders.

See here:

Problem B)

When creating a webhook, even after having given your Box App the right permissions, you are facing a 400 error like the one below:

Unexpected API Response [400 Bad Request | nqr3b4hhsa30fy93.0a89df5b6bfbff030bc864b4d4c81e393] bad_request - Bad Request

Solution B)

The Box API requires you to create a webhook that uses SSL: The notification URL specified in the address parameter must be a valid URL starting with HTTPS

For example using Node.js

const result = await client.webhooks.create(
        '1303381221506', //my file id
        client.itemTypes.FILE,
        'https://some-endpoint-webhook.mydomain.com',
        [
            client.webhooks.triggerTypes.FILE.RENAMED,
            client.webhooks.triggerTypes.FILE.DOWNLOADED
        ])

Problem C)

When you create a webhook for a specific item, you cannot create a second webhook that is associated with it. You will otherwise face the following error.

Unexpected API Response [409 Conflict | 7ejx8thhsa6jg839.05e8c637b1ef2870c7ff9ae16cfddaac8] conflict - Bad Request

This means that we’re going to figure out another way…

Solution C)

The solution is to retrieve the existing webhook for this file/folder and then edit it. More information is available from this Github repository

You can also delete it first and then re-create it. There is no other way to modify an existing webhook at this moment.

By the way - here's a comprehensive list of actions the Box platform can send you a webhook for

Conclusion

This article showed you some of the most common issues and how to solve them with the support of video clips and error logs.

This should help you overcome these initial blocks to your developer experience when using the Box SDK for Node.js.

Getting started is pretty straightforward. The documentation is clear and has many examples- making it easy to get started. However if you face any issues, you can jump on the Box community forums and ask for help. Their developer relations team is constantly monitoring it and ready to help you get rolling with any technical, SDK or API question! Alternatively reach out to the unofficial community on Stackoverflow!

Made this meme but it's ONLY html and css

orliesaurus — Sat, 09 Sep 2023 20:47:23 +0000

I am pretty sure EVERYONE must have seen this meme** before...did you? (p.s. ⚠ turn the volume down):

So, out of boredom I challenged my friend framp to see who would be faster at recreating it.

Me with emacs or him with vim

The result

Well I don't know if it's because I suck at CSS or because my fingers are too slow but...

...he won.

Check it out 👇

Smooth right?

How much would you rate the implementation?

See anything that could be improved?

Leave a rating as a reply - could you do better?

The ability to toggle and the animation using only CSS is mind blowing 🤯.

P.S. It only took 4 hours hehehe xd
** (source: tiktok https://www.tiktok.com/@never.more17/video/7224470057282178305)

Debugging Typeform webhooks

orliesaurus — Tue, 08 Aug 2023 18:06:19 +0000

I love using Typeform to capture data from users, especially because it provides me with an EASY and truly SMOOTH user experience to capture data from users anywhere and everywhere.

When a new submission is recorded in Typeform, I realized that the best way to poll to get the results was to use webhooks and not hammering the API every 15 minutes 🔨!

However during the process of implementing a small webhook backend, I encountered quite some issues with the "verification" of the signature header.

In this post, I will go over what I did to fix it!

Why webhooks?

Now you might wondering - "but orlie why not just use an API"?!

APIs are not the right choice for this because they require you to manually prompt them.

They need to be invoked every time you want to check for data.

On the other hand webhooks automatically send me data in response to a specific event.

After learning that webhooks were natively supported by Typeform, I decided to dig right in!

Typeform and webhooks

You can use Typeform webhooks to alert your application, or to connect it to an integration platform like Zapier: the basic idea is that your application wants to get notified when certain event happens in Typeform without having to ask consistently.

Here's what it would look like if I implemented it with an API pull strategy (N.B. read the graph starting from the bottom)

        Nope.
  ┌───────────────────────────┐
  │                           │
  │         Still nothing     │
  │ ┌───────────────────────┐ │
  │ │                       │ │
  │ │         No            │ │
  │ │ ┌───────────────────┐ │ │
  │ │ │                   │ │ │
┌─┴─┴─┴────┐         ┌────▼─▼─▼─┐
│ Typeform │         │My Backend│
└▲─▲──▲────┘         └───┬───┬─┬┘
 │ │  │                  │   │ │
 │ │  └──────────────────┘   │ │
 │ │Is there a new response? │ │
 │ │                         │ │
 │ │                         │ │
 │ └─────────────────────────┘ │
 │  Is there a new response?   │
 │                             │
 │                             │
 └─────────────────────────────┘
    Is there a new response?

Instead of your app constantly polling Typeform to check if anything has changed, Typeform can use a webhook to push new data to your application when it is available.

          Here's a response
        ┌───────────────────┐
        │                   │
  ┌─────┴────┐         ┌────▼─────┐
  │ Typeform │         │My Backend│
  └────▲─────┘         └────┬─────┘
       │                    │
       └────────────────────┘
              thanks

This becomes specifically awesome because it allows you to:

Work in real-time:
Webhooks allow data to be sent immediately when an event happens, without almost any delay.
Work more efficiently:
No need to write polling algorithms. This saves you time and resources.
Stay flexible:
Webhooks can be used for many different types of applications and events.

Here are some examples of using webhooks with Typeform:

When a new Typeform response is registered → send a webhook to my backend to retrieve that data and insert it into a queue
When a new Typeform response is registered → send a webhook to Zapier to perform further automation with the data

Webhooks provide a simple webhook mechanism for different applications to communicate real-time data in an efficient way. Whether it's your backend or a middleware platform that enables you to run automation of any sort, webhooks are truly an integral part of your API plumbing toolkit, which is why they are commonly used for notifications, automation, and integrating modern services.

What can go wrong?

Sometimes Webhooks fail to be delivered, or the payload content changes and thus it becomes difficult to parse the content.

Using tools like Dashcam and ngrok you can understand when a webhook delivery has failed when working on your local development environment, or during experimentation (like during a hackathon).

Specifically Dashcam, a screen recorder for debugging makes it simple to find and fix bugs in your locally running apps. When you encounter an error, Dashcam will play back your screen in sync with terminal, logs, and network requests in a format called a "Dash."

This form of debugging is known as time-travel debugging. Time Travel Debugging (TTD) can help you debug issues easier by letting you "rewind" your desktop, instead of having to reproduce the issue until you find the bug.

This is important because as you develop your platform you want to add enough flexibility to catch errors in webhooks so that the rest of your code doesn't error out.

If you want to learn how to setup Dashcam to create cool videos and catch bugs here's a mini guide

How to catch Webhooks errors

Let's fire up our code editor and write some code to catch a webhook!

We're gonna use Fastify as our library, so let's install it with npm i fastify

Then let's create index.js as our entry point

const fastify = require('fastify')({
  //this enables the logger, good to have enabled while we develop locally
  logger: true
})

// Declare a route called /response to which we send a response when we parse the request
fastify.post('/response', function (request, reply) {
  const payload = request.body;
  reply.code(200).send({ status: 'ok' });
})

// Run the server on port 5544!
fastify.listen({ port: 5544 }, function (err, address) {
  if (err) {
    fastify.log.error(err)
    process.exit(1)
  } 
})

Let's fire up our server!

I'm using ngrok to expose my localhost and port to the internet and I am logging any error to ngrok.log in the current directory where my code lives

ngrok http 5544 --log=stdout > ngrok.log

Then once that's running I take the URL that ngrok gives you!

Open up ngrok.log and see what that address looks like, for me it was:

https://dd6e2439d50e.ngrok.app/response

Finally run

node index.js 2>&1 | tee -a typeform.log

This will write all errors to a log file called typeform.log

Setting up Typeform's webhooks

Navigate into Typeform and add that address as the Webhook configuration endpoint

If you click the Send Test Request button, you should see an example request being sent to your backend

Now if you go back to your terminal, you should see your code run and accept the example webhook payload!

What happens when you hit a 404 early on?

Many times when you get started with Webhooks you configure it a little wrong…

When I first ran the above code, I realized I forgot to add the name of the endpoint ( defined on line 7 in index.js). The name of the endpoint is /response.

Luckily I was running Dashcam so I caught the error on video and created a Dash below!

Watch on Dashcam

To solve this problem, I had to change the webhook address to actually be

https://dd6e2439d50e.ngrok.app/response

In the video, you will note the extra s at the end of my path

Debug your Webhooks further

In this other example, I will add a security layer to the backend so that it will only accept webhooks if they're signed!

To learn how to set up a signed webhook follow the instructions here, specifically step 9

This is secret key I used in my example:

mysupersecret

This means that if another person sends data to my backend endpoint, without using my secret key as the hashing key, the backend will not process the data because it's not coming from Typeform!

To do this, I change my backend to look like this:

const fastify = require('fastify')({
  //this enables the logger, good to have enabled while we develop locally
  logger: true
})
//require the crypto module to verify the signature
const crypto = require('crypto');

// Declare a route called /response to which we send a response when we parse the request
fastify.post('/response',
function (request, reply) {
  const payload = request.body;
  // This is where the magic happens, we take the whole body
  // turn it into a string and format it so it can be verified
  const signature = request.headers['typeform-signature'];

  if (verifySignature(signature, JSON.stringify(payload))) {
    reply.code(200).send({ status: 'ok' });
    return
  }
  else {
    reply.code(401).send({ status: 'unauthorized' });
    return
  }
})

// Run the server on port 5544!
fastify.listen({ port: 5544 }, function (err, address) {
  if (err) {
    fastify.log.error(err)
    process.exit(1)
  } 
})

// This function verifies that it's a valid  & signed request
const verifySignature = function(sign, payload){
    const hash = crypto
      .createHmac('sha256', process.env.SECRET)
      .update(payload)
      .digest('base64')
    return sign === `sha256=${hash}`
  }

I launch the app passing the secret as an environment with the following command

SECRET=mysupersecret node index.js dev 2>&1 | tee -a typeform.log

and the following happens:

Watch on Dashcam

If we inspect line 34 to 40 we can see that we're not doing anything strange….

BUT HERE's THE CATCH

When we want to verify the signature and the hashed payload we need to add a new line to the request's body.

To do this let's modify the code to add a new line so the hashed body and the signature will match

check out line 16 of the code below to see what has changed

const fastify = require('fastify')({
  //this enables the logger, good to have enabled while we develop locally
  logger: true
})
//require the crypto module to verify the signature
const crypto = require('crypto');

// Declare a route called /response to which we send a response when we parse the request
fastify.post('/response',
function (request, reply) {
  const payload = request.body;
  // This is where the magic happens, we take the whole body
  // turn it into a string and format it so it can be verified
  const signature = request.headers['typeform-signature'];

  if (verifySignature(signature,`${JSON.stringify(request.body)}\n`)) {
    reply.code(200).send({ status: 'ok' });
    return
  }
  else {
    reply.code(401).send({ status: 'unauthorized' });
    return
  }
})

// Run the server on port 5544!
fastify.listen({ port: 5544 }, function (err, address) {
  if (err) {
    fastify.log.error(err)
    process.exit(1)
  } 
})

// This function verifies that it's a valid  & signed request
const verifySignature = function(sign, payload){
    const hash = crypto
      .createHmac('sha256', process.env.SECRET)
      .update(payload)
      .digest('base64')
    return sign === `sha256=${hash}`
  }

When I run the code, the signature matches and the webhook is "accepted" and can be processed.

Watch on Dashcam

Conclusion

You can see that using Typeform and Webhooks is truly a lifesaver.

With a simple backend, you can capture data from Typeform and process the user's data in any way you desire.

You don't have to poll Typeform for all the request and see if there's a new response added to your list.

You also can use cryptographic methods to verify that the data you receive is truly from Typeform.

If you want to learn how to setup Dashcam to create cool videos and catch bugs here's a mini guide

I debugged and fixed Stripe Quickstart issues, so you don't have to

orliesaurus — Thu, 03 Aug 2023 20:31:59 +0000

Today I went through the Stripe Quickstart for the web (node + react). It wasn't a super smooth experienced, so if you also looked at this code and couldn't get it to work...I fixed it for all of us.

Quickstarts are awesome to get you from 0 to 100, very fast! 🏎️

Sometimes, however, things change, and tutorials' code (or libraries) fall a little behind. That causes me (and everyone else) some friction.

In this article, I will show you how I debugged the issues I found.

I am using Dashcam to explain (and show you) the issues I faced. I captured them as they were happening and...I show you how I resolved them.

I hope this unblocks you and help you build your first custom Stripe payment form!

Let's start

Navigate to the Stripe Quickstart page and download the zip file.

Once you download this, unzip it somewhere that makes it accessible for you.

For me, that folder is /Users/orlie/projects/stripe-sample-code/

Once in there, you want to install the dependencies.

npm install

You will then want to start the project by doing.

npm start

I immediately saw an error. Let's see how to fix this.

Yarn installation not found - How to debug and fix it

Watch missing yarn error on Dashcam

The error shown is:

/bin/sh: yarn: command not found

There are two solutions to this problem:

Either you install yarn
You replace the entries in package.json to use npm, the default package runner

I will opt for the second option, so open up package.json and edit lines 24 so it looks like this:

"start": "concurrently \"npm run start-client\" \"npm run start-server\""

Let's rerun the app; you will notice it's finally working. JK - well, we're now hitting another error!

SSL Error

This time the error has to do with SSL...

Watch SSL Error on Dashcam

I found the solution after researching the error message (ChatGPT helps with this!):

To fix the error I need to pin the react-script library installed to a higher version (5 or higher):

I go ahead and edit package.json and change the line 10 to look like this

"react-scripts": "^5.0.0",

That should fix the issue - let's give it another go!

👉 Run npm start again

Uncaught runtime error

Relaunching the project using npm start - the localhost server goes up but...another error appears!

Watch Uncaught runtime Error

To make this error go away and continue with creating your first Stripe payment page, you can either comment out the inside CheckoutForm.jsx or fix it.

To fix, I changed the code in the following ways.
First I changed the <LinkAuthenticationElement> component to look like this in CheckoutForm.jsx:

<LinkAuthenticationElement
  id="link-authentication-element"
  onChange={handleChange}
/>

and secondly I added a function called handleChange

const  handleChange = (e) => {
  setEmail(e.value.email);
}

and voilà the code works!

Watch successful run on Dashcam

Why I used Dashcam to catch errors

Debugging software sucks, I get stuck, you get stuck, we start googling for answers - what a waste of time!
Dashcam tracks errors so not only I can get help faster, but I can show exactly what caused an error to someone with full context!

In this blogpost I use Dashcam. When I encountered any of these errors, Dashcam helps me play back the screen in sync with terminal, logs, and network requests.

This form of debugging is known as time-travel debugging. I can "rewind" my desktop, instead of having to reproduce the issue!

How set up time travel debugging with Dashcam

First every time I launch my app from the CLI, I use this command:
npm start 2>&1 | tee -a stripe-debug.log

What this command does is take all of the output that is shown on screen and write it using the tee command to a file.
In this example I called the file stripe-debug.log

Using this method you can use Dashcam to debug server Logs, you can use the Chrome extension to get console Logs from Chrome and Network Requests

Learn how to set up Dashcam to debug your local dev environment

I built a checkout button with vue-stripe

orliesaurus — Mon, 24 Jul 2023 18:47:00 +0000

TL;DR

In this blogpost, I explain how I built a very simple product page using vue-stripe. If you decide to follow along, you can too start selling your product or your services today!

I am also going to share about how to resolve the most common problems while building this, using a tool called Dashcam.

Why?

Selling online is fun! If you have a project you want to monetize, this is the fastest way to get started!

Let's get started! 🔥

Let's assume you already have node.js and npm installed. If not, you can learn how to do it here

The first thing we want to do is set up the environment. We're going to be super vanilla and make a folder called:



stripe-vue

This will be the root directory, within which we're gonna initiate our Vue project!

Go ahead and type the following command in your terminal of choice:



mkdir stripe-vue && cd stripe-vue

Next, we want to initiate a Vue project, so let's create a Vue app



npm init vue@latest

What this does is, it initializes a new project with Vue.js as a dependency using npm.

I use vue@latest - because @latest indicates that the latest version of Vue.js should be installed.

🤫
(I use npm but if you're more advanced, or picky, you can choose your package manager of choice)

Configure your vue project

When you run this command, npm will prompt you to provide information about the project (e.g., project name, options, etc).
npm will generate a package.json file and install the latest version of Vue.js as a project dependency.
Personally, I selected No on each option, because I am just building a simple checkout button, but your mileage may vary

After this step, the CLI tells me to run some commands



cd vue-stripe-checkout
npm install
npm run dev

I am going to run the top 2 of them, but not the last one, because I don't wanna run the project just yet...!

The first two commands place me inside the actual project folder, where our code will go and install the dependencies.

When that's finished I need one more dependency: vue-stripe



npm install @vue-stripe/vue-stripe

Wait! 👋 Before you continue!

Create products and prices on Stripe and enable Checkout

If you want to sell something you need to tell Stripe what you're selling.

In this demo we're selling Jars of spicy condiment/ $15 a jar. It's delicious, I promise

Creating a product & set price

Before we continue, we have to do something on Stripe's side. We have to create the product, and attach a price to it. There's a beautiful step by step tutorial on the Stripe Doc portal

Once you have created your product with a price, you need to note down the SKU id, you can find this on the Product settings page you just created and it looks like this sku_OHSgXJ1rXvtqrt

Using the SKU id value will tell Stripe's Checkout to find the default price of the product.

Creating a product price

If you have multiple prices for the same product (perhaps you're offering different geo location/currencies) instead of noting down the SKU id (red arrow), find the price id (green arrow)

Ensuring checkout is enabled

We also need to make sure that the checkout functionality is enabled, that's just a switch and it can be done quickly, the docs on Stripe's website clearly show the steps

After creating the product, having attached a price to it (and additionally another price), making sure checkout is enabled… now let's move on to creating the actual checkout page in Vue.

Creating a vue component

Back to our Vue project, let's make a new file in the components folder, if you followed this article step by step that should be:



stripe-vue/vue-stripe-checkout/src/components/CheckoutButton.vue

Now let's write some code.

Open the Checkout component and let's build a button that will lead to a Stripe checkout, first by importing StripeCheckout from the vue-stripe library

Then we're going to export an object with the default export.

We make StripeCheckout as an exportable component. This way it can be rendered and used within our app!



<template>
  <!-- We're going to put our Stripe Checkout code here in a moment -->
</template>

<script>
import { StripeCheckout } from '@vue-stripe/vue-stripe';
export default {
  components: {
    StripeCheckout,
  },
};
</script>

Next we're going to write some code to customize our Stripe Checkout button.

We're gonna write some code in this component within the <template></template> section.



<template>
    <div>
      <stripe-checkout
        ref="checkoutRef"
        mode="payment"
        :pk="publishableKey"
        :line-items="lineItems"
        :success-url="successURL"
        :cancel-url="cancelURL"
        @loading="v => loading = v"
      />
      <button @click="submit">Pay now!</button>
    </div>
  </template>

The interesting things here are to be noted:

mode: This is the type of Checkout we're asking Stripe to create, either payment or subscription. We're making a one-time payment form, so let's set it to payment.
line-items: The items that should be purchased by the customer, they're shown on the Checkout interface and make up the total amount to be collected by Checkout.
success-url: The success URL to redirect the customer after purchase
cancel-url: The cancellation URL that we should redirect customers when payment is canceled (i.e. you click the back arrow on the Stripe checkout UI)

Also, let's add a button with a label saying "Pay now!" so we can purchase the Spicy jar condiment we're going to sell when clicking the button.
Let's write some JavaScript to specify the config for our Stripe checkout that will appear once the button is clicked!

vue-stripe component setup

Let's now hook up the component we have added with the ability to be purchased.

We're going to set it up like this between the <script></script> tags

Notice that we have to set up a couple of variables:

publishableKey: your PK from Stripe's developer dashboard
lineItems: an array of objects; each object has a price for a product you're trying to sell and a quantity. You can have multiple objects in this array to create more "complex" checkouts, for example, if you sell multiple products at once
succesURL: The value of the URL after the user purchases
cancelURL: The value of the URL if the user cancels



<script>
  import { StripeCheckout } from '@vue-stripe/vue-stripe';
  export default {
    components: {
      StripeCheckout,
    },
    data () {
      return {
        publishableKey: "<YOUR-STRIPE-PUBLIC-KEY>",
        loading: false,
        lineItems: [
          {
            price: '<YOUR-SKU-ID>', // The SKU id of the product created in the Stripe dashboard
            //price: '<YOUR-PRICE-ID>', // the Price id of the product I want to sell, if you have multiple prices, pick one

            quantity: 1,
          }
        ],
        successURL: '<URL_SUCCESS>',
        cancelURL: '<URL_CANCEL>',
      };
    },
    methods: {
      submit () {
        this.$refs.checkoutRef.redirectToCheckout();
      },
    },
  };
  </script>

Now that we're done with the code, our final component should look like this:



<template>
    <div>
      <stripe-checkout
        ref="checkoutRef"
        mode="payment"
        :pk="publishableKey"
        :line-items="lineItems"
        :success-url="successURL"
        :cancel-url="cancelURL"
        @loading="v => loading = v"
      />
      <button @click="submit">Pay now!</button>
    </div>
  </template>
<script>
  import { StripeCheckout } from '@vue-stripe/vue-stripe';
  export default {
    components: {
      StripeCheckout,
    },
    data () {
      return {
        publishableKey: "<YOUR-STRIPE-PUBLIC-KEY>",
        loading: false,
        lineItems: [
          {
            price: '<YOUR-SKU-ID>', // The SKU id of the product created in the Stripe dashboard
            //price: '<YOUR-PRICE-ID>', // the Price id of the product I want to sell, if you have multiple prices, pick one

            quantity: 1,
          }
        ],
        successURL: '<URL_SUCCESS>',
        cancelURL: '<URL_CANCEL>',
      };
    },
    methods: {
      submit () {
        this.$refs.checkoutRef.redirectToCheckout();
      },
    },
  };
  </script>

Display the Checkout component

We're going to load our component into the App.vue file so that it can be shown to our

So create an App.vue file (if one exists, delete the original one) and let's write some code



<script setup>
import CheckoutButton from './components/CheckoutButton.vue'
</script>

<template>
  <div>
    <h1>Purchase a Spicy Jar</h1>
    <p>A Spicy Jar of condiment, delicious and adds a touch of fire to blander dishes</p>
    <div id="image"></div>
    <Checkout></Checkout>
</div>
</template>

<style>
  #app {display: inline-block;}
  #image {
    width: 108px; 
    height: 108px; 
    border-radius: 4px;
    background-size: cover;
    background-image: url("https://stripe-camo.global.ssl.fastly.net/1da6f350ad1131277e51712ee1b3a992efb07a9333055c2926e8db1ceb633ab6/68747470733a2f2f66696c65732e7374726970652e636f6d2f6c696e6b732f4d44423859574e6a6446387851335673596e564762484e50633367355a58565366475a735833526c6333526663564a3463577075617a4a51654746784e57786857585a61656c4261633063793030657347736d436d4f");
  }
</style>

First let's import our Checkout element from the CheckoutButton.vue file we created a moment ago, on line 2.

Then within this file, let's add some context (line 7-9) so users know what they're buying and the <Checkout></Checkout> component (line 10). When this component renders, a button will be rendered.

Launching the Vue app

Save all your files and head to your terminal:

Make sure you're in the right directory stripe-vue/vue-stripe-checkout and run npm run dev

Navigate to the URL and see your checkout button in action!

Debugging the Vue app

What do you do when the code doesn't work?

To debug the Vue app we're going to use Dashcam (disclaimer: I am working on Dashcam, a video-first code debugging tool for debs).

Dashcam allows you to debug your work, it's a screen recorder app for debugging that gives you the error logs alongside a video of what caused them, all locally on your computer.

Here's an example of me using Dashcam to debug the above code while I was writing this tutorial.

Watch it now

👀 Looking at the video I can see that I made a typo when pasting the API key (publishable one) that caused to Stripe checkout to not be able to be launched when I clicked the button.
🫠 Easy fix!

Conclusion: Writing code and understanding errors

In this article we learned how to:

👀 Set up a simple Vue project from scratch
🙏 Create a checkout button (some would call it a product page or a one-item cart page) that leads to a checkout page hosted by Stripe using Vue.
🔥 Debug your web apps using video and error logs through Dashcam.

Just looking at error logs sometimes is just not enough, especially when you're working with friends or team-mates asynchronously.

Sharing a video is worth a million words. IMHO adding video evidence to error logs truly makes a difference: I truly believe debugging with Dashcam is pretty useful because it gives you the video context alongside the Dev Tools and Network errors.

We'll see how to debug the backend in the next article!

Thank you for reading this far and let me know if you have any comments or questions below this article!

Download Dashcam (Free - Open Beta)

Explore vue-stripe further

6 things I do (and you should too) when I release open source code

orliesaurus — Wed, 21 Dec 2022 22:33:40 +0000

Every day 100+ open source libraries and projects are launched in the wild.

Launching an open source project can be daunting, especially if you haven't done it before.

Preparation + perseverance + luck are key to success here too - as much as anything else launched online.

👉 Does IT work?

The first thing you want to do before you open source something is to make sure - the project - WORKS and it is stable.
Test your code in different environments and keep track of every step, you're gonna need it.

👉 Write a good README.

This is to me the most crucial experience of a good open source project. Be clear and aim to be successful by mentioning:

Quick Get Started / HowTo
Contributing guidelines
License
Project leads

Add as much useful Documentation as you can. It's hard. I know.

👉 Show immediate VALUE.

A live-demo is worth a 1000 words. A good video/images are ok too! When people browse your project they want to immediately be captured and understand what you're sharing.

👉 Write great DOCUMENTATION.

It matters a lot, once readers are past your README, which should include the demo, they're going to jump and test it out immediately (if you made it easy to do so) and DIVE into the DOCUMENTATION to learn more about it.

Pro-tip: Keeping Documentations up to date is hard, there are effective portals like that can help:

VuePress
Gitbook
Docusaurus
Readme(.com)
Markdoc Pick what you prefer and your most comfortable building upon.

👉 PROMOTION of your project.
If you have an audience of thousands, leverage your audience to help you spread your project far and wide: word of mouth always beats other forms of promotion.

If you do not have an audience - hard work by creating content and posts around the web.

Other forms of promotion are talking at local meetups, conferences (online/offline), guest blogging and general writing for the purpose of SEO.

Notice any pattern here? Does it feel a bit "marketing heavy"? That's because it is - be creative!

Specifically on guest blogging if you wrote a tool to improve let's say online payments, find companies that might work in this vertical and suggest to talk about your open source project on their blog.

👉 COMMUNITY & MAINTENANCE
Every OS project needs maintainers, writing the code and letting it sit still does NOT work well in our always-changing world.

Updates/Vulnerabilities needs to be addressed
Features can be added, not removed
Issues need to be seen and triaged

MOST importantly the community of users that use and rely on your project needs to be nourished and helped.

Whether it's entirely via your project's tools (i.e. Github discussions, a wiki, newsgroup) or a more social tool perhaps Discord, a forum, twitter..

Here are some examples of great open source projects I collected as inspiration:

opensource #maintain

Writing great tickets in open source projects

orliesaurus — Sun, 07 Aug 2022 16:58:45 +0000

In the last couple of months, I have been working on a "new" open source project - an open source enterprise Stripe App!
How can I improve collaboration when writing issues/tickets? Read more to learn my thoughts

The importance of writing good issue tickets on open source projects

If you're working on an open source project (on github) with other people spread across the internet, it's important to write clear and concise issue tickets.

This way, everyone knows what needs to be done and no one wastes time doing things that aren't necessary.

There are a few different ways to go about writing an issue ticket.

The first one: use a template.

Issue templates for open source projects

You can find heaps of github issue templates online or in various text editors (like VS Code). Using a template ensures that you include all ✨ the important information in your ticket.✨

However, templates can be a little dull. You might have to customize templates to match the type of project you're working on, so choose wisely.

Another way to write an issue ticket is to simply include a title and brief description of the problem. This is usually sufficient for small issues. However, for larger issues, it's often helpful to include more information such as screenshots, steps to reproduce the problem, etc.

In general, it's best to err on the side of too much information rather than too little. That way, whoever is assigned the task can quickly understand the problem and get started on a fix.

How to write a good issue ticket on an open source project

There are a few best practices to follow. First, be sure to include clear and concise titles and descriptions.

If your issue is related to a specific piece of code, include that in the ticket as well. It's also helpful to include:

logs
screenshots
.. or videos if applicable.

Finally, be sure to tag the issue (do NOT tag the members of the project directly) so you can categorize appropriately the issue.

Tips for writing a good issue

If you're new to open source, collaboration, or just want to improve your issue-reporting skills, read on for some tips on how to write a good issue ticket.

1️⃣ First, be sure to include a clear and concise summary of the issue in the title. This will help others quickly understand what the problem is and whether they can help.

2️⃣ Next, provide as much detail as possible in the body of the issue. Include screenshots or screencasts if they would be helpful in understanding the problem.
(Speaking of screencasts - my friend Ian is working on making screencasts awesome at replayable.io if you want to give him some love - I would be appreciative of your time)

👉 And be sure to include any relevant error messages or logs.

3️⃣ Finally, if you have any ideas about how to fix the issue, feel free to include them in the issue ticket. It might help shape the solution, in a form or another - by the way, this is totally optional!

Hope this helps, I've been using this method for my own work on Github and I think it has been working out pretty well!

How do you monetize open source?

orliesaurus — Wed, 03 Aug 2022 14:48:59 +0000

Developers who have started dabbling in the open source space often wonder:

Can you live a normal life off of open source contributions?
Can you build a business on top of open source software?
Can you make open source software your business?

All of the answers to the above questions are the same: yes but it's not easy.

You might be wondering why are you writing this? Who on earth are you?

I am orlie, working on OSS and building in public.

My goal is to create a profitable open source business with my best friend.

For starters, we're building a Stripe App that is completely open source to sync data between Salesforce and Stripe! Curious? Check it out here

In over 15 years of building stuff online I have NEVER heard of someone who launched something from scratch into the open source world and started making money right away.

Most times there's a story of long hours of grinding behind it. 🤯

You might wonder, so how can I do it?
How can I monetize open source software I write?

Glad you asked.

Here are various ways to monetize yourself or business the open source way.

How I have seen monetization succeed in open source

1. Donations & Sponsorships

Perhaps the most common way to support open source project and their maintainers.
For businesses it makes sense to sponsor development: it ensures the project stays stable, up-to-date and actively maintained.
You can sponsor a whole project OR individually the people that work on the project.

Regardless of the platform you're using to ask for recurring donations, if you're able to market your open source software or library to a community you can monetize...your community.
Bootstrap, cURL, Vue.js and many other projects use this method.

If you have $1 donation from 10000 people, that's $10,000 a month. You can use Github sponsors, OpenCollective or Patreon. There are many other

2. Paid features as open source projects add-ons

Easier said than done because most businesses do not start as open source projects. Those who do usually follow this path:
1) They create an open source solution
2) They realize there's a paid market
3) They add extra features to the open source solution and charge for them
Notable examples:

Docker
Kong
IntelliJ

Other businesses do the opposite, they take their closed source software and rebuild a light version for "community use"

3.Charge for running the software on behalf of your customers

Simple enough business model once you create the infrastructure - as this can scale massively - you can get paid to manage your customer's instances of an open source software.

Forum and blog engines like Ghost are a prime example of companies that managed to monetize open source by providing hosting. Another example is Bitbucket and Github's rival...Gitlab!

👀 BTW, did you know that the software that runs dev.to is open-source but you will be soon able to pay for someone to run it for you:

4.Paid consulting and support

Nginx PRO is a prime example of software which is open source practically but you can be paid to support the installation.
You are not hosting the software for your customers but you're helping them configure it in a way that works best for them.

5. A company hires you to maintain your project

Some companies will hire developers/teams of devs to maintain an open source project on which they rely heavily

In an ideal world if you write software and it gets used, you'd be able to capture some share of that value. But we're not there yet.

In a great universe this model would be not needed, every company that is profitable (and non-profitable too) should:
Create and maintain open source libraries
Updating documentation, samples and tutorials
Push forward the level of technology by innovating.

But alas, we're far away from those models

How I used an open source mentality to dig my path forward through school

orliesaurus — Sat, 30 Jul 2022 19:48:00 +0000

I like to believe I have been always involved in open source. Even as a kid and a student.

When I was in school, I came up with an "open source"/"open collaboration" methodology to finish my homework fast with little effort. Back then I had no clue what open source was - but now I can find a parallel line of thinking between the two.

Here is how it would work:
Given a certain homework of 4 parts, I would start working on a part it, maybe do Part A) and B).

Then I would ask someone else in my class to do part C) and D)

Then ask someone else to verify all of A), B), C) and D) - did all parts make sense?

If so, then great homework done for everyone. This applies to most homework in a way or another

This could scale further...depending on the amount of work required.

Everyone who'd have collaborated on the homework would at that point have the full answer.

It was part of the process - if you're part of the "homework project", you get full access to the full homework.

Strength in numbers?

In the end, before submission everyone would just take all of the work done as a group, change it a little bit & submit it.
Worked. Every. Single. time.

Homework done. Open source style.

Was this legal at school? Probably not.

Later in life

In the world of software however, collaborating in plain sight is absolutely rewarded.

Open source works pretty much just like that.

I have a couple of open source projects under my belt, some a little successful other, not so much. (if you're interested check my Github here
Open source to me, has always been an interesting concept:

I build something that I think is useful
I put the code in the public domain
Other people CAN use my code for free to solve their problems faster
People can help me make the code better
[Repeat this a few tens of times]
Eventually, the next person that uses the project has a much better experience

...but can someone make a living out of it?

That's something I will explore in the next piece!

What about you?

🤔 Have you worked hard through school, or did you work smart?
Was the approach you took worth it?
Let me know in the comments!

Just released an open source Stripe App

orliesaurus — Mon, 18 Jul 2022 20:45:40 +0000

So I just open sourced something, and now what you may ask....?

If you're familiar with Stripe, you might have heard that they've recently announced the Stripe app store.

Yes! You can now build apps and let 3rd party users install them on their Stripe dashboard - and yes, you can ✨ monetize it ✨.

I have recently pushed an open source Stripe to Github so others can learn how to build on top of the Stripe marketplace.

SFDC Insights for Stripe Apps · GitHub

An open-source Salesforce integration that shows your instance's customers insights inside the Stripe Dashboard - SFDC Insights for Stripe Apps

github.com

It's actually not simple to create open source projects and if you're not going to put efforts in it, it might be a wasted effort (your time, energy, resources etc) and it will fail.

That's when reality kicked in

I felt like I had a good idea, but will I be able to be successful in growing interest and an audience around this project?

Why creating an open source Stripe?

I was actually shocked there wasn't any end-to-end open source Stripe app to inspire others.

I thought this was a big enough gap where it would make sense that I would be able to create something that would help the wider community.

First of all, I planned this would take 2 sprints, I set aside evenings and started building.

It all started with the Stripe tutorial and this commands

stripe plugin install apps && stripe apps create helloworld

Building the app

I knew I wanted to create something useful, and if you want to build something useful you have to start building something that alleviates someone's pain-point.

They say the idea is the most important thing...not always!
This is how I came up with it: I hate looking up data between tabs. Copy-pasting is fun, so anything that makes a boring and repetitive process better is a pot of gold for me!

Next I had to find a target: There are thousands of companies out there but I picked the largest CRM as the subject of what I was going to build: an integration between Salesforce and Stripe.

From there, I started writing code.

The idea is that any other app developers can take inspiration from this end-to-end implementation and build on top of it, fork it, improve it or ignore the project!

Small steps to open sourcing.

First of all, I started by committing ALL the code needed to run the app successfully.

I then added a README.md file that hopefully will help people understand how to best use the front-end and back-end of the app.

However the list of things to add to make this open source project more successful are still a lot.

✅ Create a Github org for the project
✅ Push code to the repository on Github
✅ Write a quality README.MD
🔳 Write a CHANGELOG.MD
🔳 Write a CONTRIBUTING.MD
✅ Choose an open source license
🔳 Write tests
🔳 Create label for Github issues

Going forward

I hope I didn't break any ToS and that I can keep improving the code, I have a lot of work ahead of me to make this project successful but I hope that by building it in public it will help keep me accountable AND inspire others to hopefully open source some of their code for the first time, or maybe just to contribute to my project!

If you want to learn more, follow me on Twitter and/or Github!