DEV Community: Miguel Piedrafita

Highlight your website's code blocks with VSCode

Miguel Piedrafita — Mon, 05 Oct 2020 00:00:00 +0000

When it comes to highlighting code blocks on your website, it may seem there aren't many options available. I'd bet a 90% of websites use either Prism or HighlightJS. While these options are good, they often miss the mark for more niche use-cases, like supporting new PHP syntax or correctly highlighting Laravel Blade views, to the point where some users opt to highlight the code manually.

When I decided to improve the code blocks on this website, my first idea was to create a custom Prism theme, taking inspiration from the VSCode Community Material theme. After almost 100 lines of hot-fixing Prism however, I gave up and started looking for alternative solutions. I didn't have much hope, but ended up finding the holy grail of syntax highlighting: a way of using the same highlighter that VSCode uses, on your website, with support for any VSCode theme and extension.

Before I get started on how you can add this to your site too, there's a catch. The package used to achieve this needs to be run on the server, which means you need some sort of build process (although there's an RFC open for browser support). I'll be showing how to make this work with a simple node script, but I've had success getting it to work with Next.js and Gatsby, and I'm sure there's a way to get it working with other frameworks too. With that out of the way, let's get into it!

First, you'll need to create a node script that takes your markdown and turns it into HTML (which you can later echo from your website). For this example, we'll assume there's a posts directory full of markdown files and a build directory where our website expects html files to be.

const fs = require('fs')
const path = require('path')
const shiki = require('shiki')
const markdown = require('markdown-it')

shiki.getHighlighter().then(highlighter => {
    const md = markdown({
        html: true,
        highlight: (code, lang) => highlighter.codeToHtml(code, lang)
    })

    fs.readdirSync(path.join(process.cwd(), 'posts')).filter(slug => /\.mdx?$/.test(slug)).forEach(slug => {
        const content = fs.readFileSync(path.join(process.cwd(), 'posts', slug), 'utf-8')

        fs.writeFileSync(path.join(process.cwd(), 'build', slug.replace(/\.mdx?$/, '.html')), md.render(content))

        console.log(`${slug} => ${slug.replace(/\.mdx?$/, '.html')}`)
    })
})

Now you just need to run that script during your build process and you'll get some awesome VSCode-powered code blocks!

Shiki comes with support for plenty of languages by default, but you can also add custom languages from any VSCode extension. You just need to find a .tmLanguage or .tmLanguage.json on the extension source, and copy it to your project. Then, you pass an array of additional languages to shiki when creating the highlighter.

const langs = [
    {
        id: 'blade',
        scopeName: 'text.html.php.blade',
        path: path.join(process.cwd(), 'vendor/blade.tmLanguage.json'),
        embeddedLanguages: {
            'source.php': 'php',
            'source.css': 'css',
            'source.js': 'javascript',
        },
    },
    {
        language: 'dotenv',
        scopeName: 'source.env',
        path: path.join(process.cwd(), 'vendor/env.tmLanguage'),
        aliases: ['env'],
    },
]

shiki.getHighlighter({ langs }).then(highlighter => {
    //
})

Finally, what about custom themes? Again, shiki includes many themes by default, but you can bring your own by finding the JSON file for that theme in its source.

const theme = shiki.loadTheme(path.join(process.cwd(), 'vendor/material-theme.json')),

shiki.getHighlighter({ theme }).then(highlighter => {
    //
})

Those are the basics, which you can then apply to your specific setup. Here's how I'm doing the highlighting with Next.js and next-mdx-remote.

import matter from 'gray-matter'
import visit from 'unist-util-visit'
import renderToString from 'next-mdx-remote/render-to-string'

export const getStaticProps = async ({ params: { slug } }) => {
    const source = fs.readFileSync(path.join(process.cwd(), 'content/posts', `${slug}.mdx`))
    const { content, data } = matter(source)

    const shiki = await import('shiki')
    const highlighter = await shiki.getHighlighter({
        theme: shiki.loadTheme(path.join(process.cwd(), 'vendor/material-theme.json')),
        langs: [{
            id: 'blade',
            scopeName: 'text.html.php.blade',
            path: path.join(process.cwd(), 'vendor/blade.tmLanguage.json'),
            embeddedLanguages: { 'source.php': 'php', 'source.css': 'css', 'source.js': 'javascript' },
        },],
    })

    const mdxSource = await renderToString(content, {
        mdxOptions: { remarkPlugins: [[remarkPlugin, { highlighter }]] },
        scope: data,
    })

    return { props: { slug, mdxSource, ...data } }
}

export const remarkPlugin = options => async tree => {
    visit(tree, 'code', node => {
        node.type = 'html'
        node.children = undefined
        node.value = options.highlighter.codeToHtml(node.value, node.lang).replace('<pre class="shiki"', `<pre class="shiki" language="${node.lang}" meta="${node.meta}"`)
    })
}

Did you add shiki to your blog? Are you using something different to highlight your code? Reach out on Twitter and let me know!

Billing access to your Laravel apps with Gumroad

Miguel Piedrafita — Sun, 04 Oct 2020 00:00:00 +0000

I recently worked on a project where users made a one-time purchase for access to the application. Following the lead of other sites with this exact system (like Tailwind UI), we decided to go with Gumroad. Here's how we made it work with Laravel.

First, you'll need to create a Gumroad account. Then, create a new product and fill out all the required fields. On the Content section, you'll need to make sure the checkbox that says Generate a unique license key per sale is checked. You will also need to set the content to a URL instead of a file. In my case, this URL will be the registration page.

Let's move over to the Laravel side now. The first thing we need is a way to connect with Gumroad. Instead of downloading any packages, we can use the new Http client on Laravel 7.x to interact with the Gumroad API. Here's a simple class that will make our lives easier.

<?php

namespace App\Utils;

use Illuminate\Http\Client\PendingRequest;

class Gumroad
{
    protected PendingRequest $client;

    public function __construct(PendingRequest $client)
    {
        $this->client = $client->baseUrl('https://api.gumroad.com/v2/')->withToken(config('services.gumroad.token'));
    }

    public function getSale(string $id) : array
    {
        return $this->client->get("/sales/{$id}")->throw()->json();
    }

    public function verifyLicense(string $license) : array
    {
        return $this->client->post('/licenses/verify', [
            'product_permalink' => config('services.microlink.product'),
            'license_key' => $license,
        ])->throw()->json();
    }
}

With this out of the way, we can now start working on validating the license key on registration. For this purpose, I've created a custom validation rule you can just add into the validation array on your RegisterController (or CreateNewUser if you're using Fortify). This rule will not only make sure that the license key exists, but also that it hasn't been used before and hasn't been refunded or cancelled in any way.

<?php

namespace App\Rules;

use Facades\App\Utils\Gumroad;
use Illuminate\Contracts\Validation\Rule;

class GumroadLicense implements Rule
{
    /**
     * Determine if the validation rule passes.
     *
     * @param  string  $attribute
     * @param  mixed  $value
     * @return bool
     */
    public function passes($attribute, $value)
    {
        $license = Gumroad::verifyLicense($value);

        return
                $license['success'] &&
                $license['uses'] == 1 &&
                !$license['purchase']['refunded'] &&
                !$license['purchase']['disputed'] &&
                !$license['purchase']['chargebacked'];
    }

    /**
     * Get the validation error message.
     *
     * @return string
     */
    public function message()
    {
        return 'The provided license is invalid or has expired.';
    }
}

We could stop here, but we can still improve the experience of our users a little more. See, when someone completes the purchase, they get redirected to the URL we specified earlier with a special query parameter called sale_id, which we can use to retrieve the license key and pre-fill the input. This will save the user searching for the email Gumroad sends with their key and copying, resulting in a better experience. To implement this, just run this code before returning the registration view.

if (request()->query('sale_id')) {
    $sale = Gumroad::getSale($request->query('sale_id'))['sale'];

    request()->session()->flashInput(['email' => $sale['email'], 'license_key' => $sale['license_key']]);
}

And that's everything you need to start billing for access to your Laravel apps with Gumroad!

How to publish your web app to the Play Store

Miguel Piedrafita — Thu, 10 Sep 2020 00:00:00 +0000

I recently had to figure out a way of making an Android app for one of my projects. I looked into Android Studio, Koltin, and Flutter, and quickly learned it takes a massive amount of work to make an app from scratch.

So, instead of doing that, I decided to cheat a little bit, and use my already-responsive web app as the mobile app. I even managed to package it into a real Android app and submit it to the Play Store! Here's how you can do the same.

1. Make your web app responsive

This is not strictly required, but no one wants to use a web app that looks bad. You want to make sure your website looks great on mobile, which you can do from your browser's developer tools. I'd also recommend you to preview your website from your phone since the devtools simulator isn't always perfect.

2. Create a Web Manifest

This may sound complex, but it's actually pretty easy, and you can get most of the way there using almost any favicon generator.

What am I talking about? You probably know that you can change this globe icon that appears next to your website's title on your browser by adding a favicon.ico file with your logo. What you may not know is that your favicon is also used in many other places, like when adding your website to the home screen on iOS or Android.

While we can use the same file for everything, different platforms have different requirements, and we can provide different versions of our logo for optimal results. While we could generate all these different variations ourselves, there are plenty of tools online that can do this for us. We'll be using favicon.io since it's one of the few that don't look like they were designed ten years ago. We just need to upload a high-res version of our icon and click the download button, and we'll get a ZIP file with a bunch of icons and a manifest file. We'll add these to our site and copy the following tags to the head of our HTML.

<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png">
<link rel="manifest" href="/site.webmanifest">

Finally, we'll need to tweak a few things on our manifest file, like adding the name of our app, changing the theme and background colors (which are used for the splash screen), and adding a start URL (start_url), which indicates which page will users see when they open your app.

{
    "name":"Example App",
    "short_name":"Example App",
    "icons":[
        {
            "src":"/android-chrome-192x192.png",
            "sizes":"192x192",
            "type":"image/png"
        },
        {
            "src":"/android-chrome-512x512.png",
            "sizes":"512x512",
            "type":"image/png"
        }
    ],
    "theme_color":"#ffffff",
    "background_color":"#ffffff",
    "display":"standalone",
+   "start_url": "/dashboard"
}

3. Add a Service Worker

The next step is to add a service worker to our website. Service workers can be used for a lot of interesting things, like background sync or push notifications, but we'll be using them to cache the pages of our app so they load while offline.

To do this, we'll first need to create our service worker file, which we'll call sw.js, and add the following code:

const cacheName = "offline-pages";

importScripts('https://storage.googleapis.com/workbox-cdn/releases/5.0.0/workbox-sw.js');

self.addEventListener("message", (event) => {
    if (!event.data || event.data.type !== "SKIP_WAITING") return

    self.skipWaiting();
});

workbox.routing.registerRoute(
    new RegExp('/*'),
    new workbox.strategies.NetworkFirst({ cacheName })
);

Keep in mind this needs to be in a different file from your existing javascript, and can't be bundled alongside it.

Finally, we'll load our service worker from our website's javascript, with the following code.

if ("serviceWorker" in navigator) {
  navigator.serviceWorker.register("sw.js");
}

4. Bundle everything into an app

With our manifest and service worker running in production, we're ready to make our Android app, or rather have it made for us. For this, we're gonna use bubblewrap, a CLI tool developed by the Chrome team to generate Android apps from Progressive Web Apps (which is what we just created by adding a manifest and a service worker).

Before we install it though, we need to make sure we have downloaded JDK 8 and the Android command line tools. We can either download and unzip these libraries individually (links in the description) or install Android Studio and have them be downloaded automatically. With both dependencies installed, we'll run yarn global add @bubblewrap/cli to install bubblewrap.

When running it for the first time, it'll ask for the dependencies we downloaded earlier. If you decided to install Android Studio (and you're on a Mac), your JDK path is /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk and your SDK path is /Users/YOUR_USERNAME_HERE/Library/Android/sdk.

Alright, with all this done, let's create a new directory and run bubblewrap init --manifest https://YOUR_WEBSITE/site.webmanifest from inside it. This process will ask you a few questions and generate a signing key if you don't already have one. Make sure to backup this key, and take note of the keystore password, key password, and key alias, or you won't be able to release future updates to your app.

You can build your app by running bubblewrap build --generateAppBundle and grabbing the app-release-signed.apk, which we can then go and install on our phone.[

This will also generate app-release-bundle.aab, which we'll need for submitting our app to the Play Store later, and assetlinks.json, which we'll need to upload to our website at /.well-known/assetlinks.json for our application to work.

5. Submitting your app to the Play Store

We already have an app we can install on our phone, let's now get it on the Play Store so everyone can download it. Let's head to the Play Developer Console and create a new app. If you don't have a Play Developer account yet, you'll need to accept some conditions and pay a one-time $25 fee.

After answering a few questions like the name of our app, it's main language, it's price, and whether it's an app or a game. We'll be able to create our app. We'll need to complete every task listed under First Steps before we can create a release, and set up a store listing including a description for our app, a feature graphic, and at least three screenshots, which will be shown in our Play Store page.

Once that's done, we can move on to creating our first release. We'll do this from the production menu, where we'll first need to select what countries we want our app to be available on. Then we can create a new release and upload the app-release-bundle.aab file we created earlier. We'll also need a release name (invisible to our users) and some release notes (shown in our Play Store page).

With that filled in, we can publish our release and sit back, because the review period can last anywhere between one and twenty days. Once the review is complete, you'll get an email letting you know your app is now available for download from the Play Store.

Building a Chrome Extension to highlight my Things tasks

Miguel Piedrafita — Mon, 25 May 2020 10:49:26 +0000

I've been really into doing live-coding threads on Twitter and turning them into articles lately. After doing it two days in a row, building VAT handling into Sitesauce first and a referral system the day after, I figured out I'd continue and do it for the entire week.

Instead of continuing to work on Sitesauce though, I decided to build something I had been wanting to build for a while: a chrome extension to showcase my current task on each tab I open.

This may sound simple, but the software I use to log my tasks, Things, is notoriously difficult to integrate with. They don't provide any kind of API for pulling data out except for some AppleScript macros (which we can't execute from our Chrome extension). I also couldn't find any documentation online on how to do this, so I had to get creative

Part 1: The Backend

Things is a macOS app. Tasks need to be stored somewhere, and even though it syncs with iCloud (and their proprietary cloud service), the app also works offline, which means they needs to store data somewhere, even temporally. Indeed, after some digging through my filesystem, I found a sqlite database located at ~/Library/Containers/com.culturedcode.ThingsMac/Data/Library/Application Support/Cultured Code/Things/Things.sqlite3. Let's open it up and see if we can use it as a data source.

Here's the structure of the TMTask table, which seems to contain our tasks (along with Projects for some reason).

CREATE TABLE 'TMTask' (
    'uuid', 'userModificationDate', 'creationDate', 'trashed', 'type', 'title', 'notes',
    'dueDate', 'dueDateOffset', 'status', 'stopDate', 'start', 'startDate', 'index',
    'todayIndex', 'area', 'project', 'repeatingTemplate', 'delegate', 'recurrenceRule',
    'instanceCreationStartDate', 'instanceCreationPaused', 'instanceCreationCount',
    'afterCompletionReferenceDate', 'actionGroup', 'untrashedLeafActionsCount',
    'openUntrashedLeafActionsCount', 'checklistItemsCount', 'openChecklistItemsCount',
    'startBucket', 'alarmTimeOffset', 'lastAlarmInteractionDate', 'leavesTombstone',
    'todayIndexReferenceDate', 'nextInstanceStartDate', 'dueDateSupressionDate'
);

It's a lot of data, but after playing around with the data, I managed to craft a query that gets all the items in our Today list. The status field represents the status of the task (0 seems to stand for unfinished task) and getting all columns where startDate is set does the trick!

select * from "TMTask" where "status" = "0" and "startDate" IS NOT NULL;

Now that we've got the query we want to run, we need a server that can execute it when we request it from our extension. I would normally create a new Laravel app, but it seems overkill for a single endpoint which makes a bunch of database calls.

Instead, we can use Laravel's amazing query builder on regular PHP apps by installing it with composer. We can get the required boilerplate fromMatt Stauffer's Torch project, which provides examples of Illuminate components outside of Laravel. According to their database example, we need to create a new instance of the query builder and connect it to Things' database. After that, we can use DB:: methods as we're used to.

<?php

require_once 'vendor/autoload.php'

use Illuminate\Database\Capsule\Manager as DB;

$connectionManager = new DB;

$connectionManager->addConnection([
    'driver' => 'sqlite',
    'database' => '~/Library/Containers/com.culturedcode.ThingsMac/Data/Library/Application Support/Cultured Code/Things/Things.sqlite3',
    'charset' => 'utf8',
    'collation' => 'utf8_unicode_ci',
    'prefix' => '',
]);

$connectionManager->setAsGlobal();

Let's reconstruct our query on the Query Builder, and see what we get.

<?php

require_once 'vendor/autoload.php'

use Illuminate\Database\Capsule\Manager as DB;

// connection is added here, removed for brevity

$tasks = DB::table('TMTask')
    ->where('status', 0)
    ->whereNotNull('startDate')
    ->orderByDesc('todayIndex')
    ->get();

var_dump($tasks);
exit();

/* Here's the output */
object(Illuminate\Support\Collection)#1058 (1) {
    ["items":protected]=> array(1) {
        [0]=> object(stdClass)#1056 (36) {
            ["uuid"]=> string(36) "5E966A73-19D1-4AA9-B4B9-A2C5541AB021"
            ["userModificationDate"]=> string(16) "1589845969.23817"
            ["creationDate"]=> string(16) "1589447418.40047"
            ["trashed"]=> string(1) "0"
            ["type"]=> string(1) "0"
            ["title"]=> string(29) "Write article about extension"
            ["notes"]=> string(0) ""
            ["dueDate"]=> NULL
            ["dueDateOffset"]=> string(1) "0"
            ["status"]=> string(1) "0"
            ["stopDate"]=> NULL
            ["start"]=> string(1) "1"
            ["startDate"]=> string(12) "1589414400.0"
            ["index"]=> string(4) "-343"
            ["todayIndex"]=> string(3) "334"
            ["area"]=> NULL
            ["project"]=> NULL
            ["repeatingTemplate"]=> NULL
            ["delegate"]=> NULL
            ["recurrenceRule"]=> NULL
            ["instanceCreationStartDate"]=> NULL
            ["instanceCreationPaused"]=> string(1) "0"
            ["instanceCreationCount"]=> string(1) "0"
            ["afterCompletionReferenceDate"]=> NULL
            ["actionGroup"]=> NULL
            ["untrashedLeafActionsCount"]=> string(2) "-1"
            ["openUntrashedLeafActionsCount"]=> string(2) "-1"
            ["checklistItemsCount"]=> string(1) "0"
            ["openChecklistItemsCount"]=> string(1) "0"
            ["startBucket"]=> string(1) "0"
            ["alarmTimeOffset"]=> NULL
            ["lastAlarmInteractionDate"]=> NULL
            ["todayIndexReferenceDate"]=> string(12) "1589414400.0"
            ["nextInstanceStartDate"]=> string(14) "-62135769600.0"
            ["dueDateSuppressionDate"]=> NULL
            ["leavesTombstone"]=> string(1) "0"
        }
    }
}

That's a lot of data we don't need (and some I don't even know what it stands for). Let's make sure we're only asking for what we need.

<?php

require_once 'vendor/autoload.php'

use Illuminate\Database\Capsule\Manager as DB;

// connection is added here, removed for brevity

$tasks = DB::table('TMTask')
    ->select('title', 'notes')
    ->where('status', 0)
    ->whereNotNull('startDate')
    ->orderByDesc('todayIndex')
    ->get()
    ->map(fn ($task) => ['title' => $task->title, 'description' => $task->notes])
    ->reverse()
    ->values()
    ->toArray();

var_dump($tasks);
exit();

/* Here's what we get now: */
object(Illuminate\Support\Collection)#1061 (1) {
    ["items":protected]=> array(4) {
        [0]=> array(2) {
            ["title"]=> string(29) "Sixth module of the Go course"
            ["description"]=> string(66) "https://www.educative.io/courses/introduction-to-programming-in-go"
        }
        [1]=> array(2) {
            ["title"]=> string(18) "Write Vercel Guide"
            ["description"]=> NULL
        }
        [2]=> array(2) {
            ["title"]=> string(41) "A new-tab extension for your Things tasks"
            ["description"]=> string(0) ""
        }
        [3]=> array(2) {
          ["title"]=> string(54) "Get Vercel login working on static site with functions"
          ["description"]=> string(0) ""
        }
    }
}

That's much better. Let's now turn our script into an API with the oldest method known to the PHP developer, echo.

<?php

require_once 'vendor/autoload.php'

use Illuminate\Database\Capsule\Manager as DB;

// connection is added here, removed for brevity

header('content-type: application/json');

echo DB::table('TMTask')
    ->select('title', 'notes')
    ->where('status', 0)
    ->whereNotNull('startDate')
    ->orderByDesc('todayIndex')
    ->get()
    ->map(fn ($task) => ['title' => $task->title, 'description' => $task->notes])
    ->reverse()
    ->values()
    ->toJson();

One Things feature I use a lot is tagging, and it'd be cool to show the tasks attached to our task on our extension. After a few failed tries, I managed to get everything working using an additional query to the pivot table.

<?php

require_once 'vendor/autoload.php'

use Illuminate\Database\Capsule\Manager as DB;

// connection is added here, removed for brevity

$tasks = DB::table('TMTask')
    ->select('uuid', 'title', 'notes')
    ->where('status', 0)
    ->whereNotNull('startDate')
    ->orderByDesc('todayIndex')
    ->get();

$relationship = DB::table('TMTaskTag')
    ->select('tasks as taskId', 'title as tag')
    ->whereIn('tasks', $tasks->map->uuid)
    ->join('TMTag', 'TMTag.uuid', 'TMTaskTag.tags')
    ->get();

header('content-type: application/json');

echo $tasks->map(fn ($task) => [
    'id' => $task->uuid,
    'title' => $task->title,
    'description' => $task->notes,
    'tags' => $relationship->where('taskId', $task->uuid)->map(fn ($rel) => $rel->tag),
])->reverse()->values()->toJson();

And, after a few hours of digging through Things' database and playing around with queries, we now have our API ready to be consumed by the extension. Let's work on that next!

A screenshot of the Insomnia HTTP client showing the results of an example API call

Part 2: The Extension

The first thing we need to create is our manifest file, which will tell Chrome (or Brave in my case) what our extension does. For our purpose, we can use the chrome_url_overrides property to have our HTML file load each time we open a new tab.

{
    "name": "Things New Tab",
    "version": "1.0",
    "description": "A new tab extension for personal use.",
    "chrome_url_overrides": {
        "newtab": "newTab/index.html"
    },
    "manifest_version": 2,
    "icons": {
        "16": "icon.png",
        "128": "icon.png"
    }
}

Before we start working on the frontend though, we need to load the extension into Brave. We can do this by going to brave://extensions and loading the extension folder with the Load Unpacked option.

Using Tailwind and Vue, I got a basic version to pull my current task from our backend and displaying it along with the tag and optionally the description. Here's a timelapse of the process.

Once I got the basic functionality working (and after taking a break), I started working in making it look good. Here's another timelapse of the process.

Here's the design I ended up going with. It uses multiple shadows to give the illusion of stacked layers, which gives a fun look. The background was taken from this awesome collection of SVG patterns. Really like how it ended up looking.

After digging a bit more into the Things documentation, I found their URL protocol, which allows you to visit specially-crafted things:// links to perform actions, like editing tasks. With this functionality, I made it so you could mark your current task as completed right from your browser. Here's how that looks.

I've extracted all required configuration (a URL to the backend and the Things token, required for marking a task as complete) to an .env file and open-sourced the extension and the server in case someone else finds it useful.

As with the two others, this article started as a Twitter thread, you may want to follow me there for more live-coding threads. If you'd like to see me do something like this in video format, you can subscribe to my YouTube channel, where I'm planning to produce some video content this summer. Have a great day!

Building an affiliate program with Laravel

Miguel Piedrafita — Sun, 24 May 2020 02:22:59 +0000

I recently built a simple affiliate program for Sitesauce. Here's a short article detailing how I implemented it.

Note: I built this from scratch as a way to have more control over the affiliate experience, but you may want to use a platform like Rewardful to implement something similar with little work on your part.

The basics of our program will be the following: users can register for our referral program and get a special link to share. When someone registers through their link, they'll be marked as referred by our user, and they'll earn a comission on all future purchases they make.

Let's first figure out how we want our affiliate experience to be. I was initially planning to take the Fathom approach, where referred users are linked to a special referral page which marks them as referred, but ended up deciding to go with an approach similar to what Rewardful does, allowing our affiliates to append ?via=miguel to any URL of our marketing site to count them as referrals.

So let's start by creating the script that allows us to register referred users when they visit a page with the via query param. The code is pretty straightforward, if the parameter exists, we store it in a cookie for 30 days. Since our marketing site and Laravel app are on different subdomains, we add a . in front of the domain, which makes it available on all subdomains.

import Cookies from 'js-cookie'

const via = new URL(location.href).searchParams.get('via')

if (via) {
    Cookies.set('sitesauce_affiliate', via, {
        expires: 30,
        domain: '.sitesauce.app',
        secure: true,
        sameSite: 'lax'
    })
}

This does the trick functionality-wise, but I wanted to take it a step further by showing a special call-to-action and the name of the affiliate, which should both make it more compelling and make it clear you just followed a referral link. Here's a mockup of how I wanted my banner to look like when visiting a referral link.

To make that work though, we need to store more than the affiliate tag. Let's prototype an imaginary API that returns some data from a tag, and get our example working.

import axios from 'axios'
import Cookies from 'js-cookie'

const via = new URL(location.href).searchParams.get('via')

if (via) {
    axios.post(`https://app.sitesauce.app/api/affiliate/${encodeURIcomponent(this.via)}`).then(response => {
        Cookies.set('sitesauce_affiliate', response.data, { expires: 30, domain: '.sitesauce.app', secure: true, sameSite: 'lax' })
    }).catch(error => {
        if (!error.response || error.response.status !== 404) return console.log('Something went wrong')

        console.log('Affiliate does not exist. Register for our referral program here: https://app.sitesauce.app/affiliate')
    })
}

See that encodeURIComponent call when constructing the URL? It's there to protect us from a Path Traversal vulnerability. We're sending a request to /api/referral/:via, so if someone crafted a link containing ?via=../../logout, users would be logged out when clicking on the link. No much harm done in this scenario, but you can probably imagine many others where this would not be good.

Since the Sitesauce landing already uses Alpine in a few places, let's build our banner as an Alpine component. Props to my friend Ryan for helping out why my transitions weren't working.

<div x-data="{ ...component() } x-cloak x-init="init()">
    <template x-if="affiliate">
        <div>
            <img :src="affiliate.avatar" class="h-8 w-8 rounded-full mr-2">
            <p>Your friend <span x-text="affiliate.name"></span> has invited you to try Sitesauce</p>
            <button>Start your trial</button>
        </div>
    </template>
</div>

<script>
import axios from 'axios'
import Cookies from 'js-cookie'

// We're using template tags and $nextTick so that transitions for our banner get executed, thanks Ryan for helping me figure this out!
window.component = () => ({
    affiliate: null,
    via: new URL(location.href).searchParams.get('via')
    init() {
        if (! this.via) return this.$nextTick(() => this.affiliate = Cookies.getJSON('sitesauce.affiliate'))

        axios.post(`https://app.sitesauce.app/api/affiliate/${encodeURIComponent(this.via)}`).then(response => {
            this.$nextTick(() => this.affiliate = response.data)

            Cookies.set('sitesauce.affiliate', response.data, {
                expires: 30, domain: '.sitesauce.app', secure: true, sameSite: 'lax'
            })
        }).catch(error => {
            if (!error.response || error.response.status !== 404) return console.log('Something went wrong')

            console.log('Affiliate does not exist. Register for our referral program here: https://app.sitesauce.app/affiliate')
        })
    }
})
</script>

Let's now bring that imaginary API to life so we can see the whole thing working. Instead of creating a new Affiliate model, I'll add a few fields to our existing User model. Ignore the last two for now, we'll get back to those later.

class AddAffiliateColumnsToUsersTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('users', function (Blueprint $table) {
            $table->string('affiliate_tag')->nullable();
            $table->string('referred_by')->nullable();

            $table->string('paypal_email')->nullable();
            $table->timestamp('cashed_out_at')->nullable();
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('users', function (Blueprint $table) {
            $table->dropColumn('affiliate_tag', 'referred_by', 'paypal_email', 'cashed_out_at');
        });
    }
}

For our API route, we'll use the new binding fields routing feature (available on Laravel 7.X) to get everything working with a single line of code.

Route::post('api/affiliate/{user:affiliate_tag}', function (User $user) {
    return $user->only('id', 'name', 'avatar', 'affiliate_tag');
})->middleware('throttle:30,1');

Before we start working on marking users as referred on registration, we need to make sure Laravel can read our cookie. Since it's not encrypted, we'll need to add it to the exceptions list of our EncryptCookies middleware.

// app/Http/Middleware/EncryptCookies.php

use Illuminate\Cookie\Middleware\EncryptCookies as Middleware;

class EncryptCookies extends Middleware
{
    /**
    * The names of the cookies that should not be encrypted
    *
    * @var array
    */
    protected $except = [
        'sitesauce_referral',
    ];
}

With that out of the way, let's move to marking users as referred. We can use the authenticated method on our RegisterController to execute logic after our user has been created. We'll make sure that both the cookie and the affiliate exist, and mark the user as referred if they do.

/**
 * The user has been registered.
 *
 * @param \Illuminate\Http\Request $request
 * @param \App\User $user
 */
protected function registered(Request $request, User $user)
{
    if (! $request->hasCookie('sitesauce.referral')) return;

    $referral = json_decode($request->cookie('sitesauce_referral'), true)['affiliate_tag'];

    if (! User::where('affiliate_tag', $referral)->exists()) return;

    $user->update([
        'referred_by' => $referral,
    ]);
}

We're also going to need a way to retrieve a list of users our affiliate has referred. We can achieve this by creating a hasMany relationship with the User model from our User model.

class User extends Model
{
    public function referred()
    {
        return $this->hasMany(self::class, 'referred_by', 'affiliate_tag');
    }
}

Let's now take a break from the backend to design a nice page where our users can register for the program. We'll allow them to select their tag and ask them for their PayPal email, so they can cash their earnings out. Here's how my design turned out:

Once our affiliate has registered, we should also allow them to update both their email and their tag. If they update their tag, we'll need to update it across all their referred users to make sure reporting doesn't break. We'll do it on a database transaction to ensure that, if one of the two operations fail (updating the tag across referred users and updating the tag on our affiliate user), both of them are reverted.

public function update(Request $request)
    {
        $request->validate([
            'affiliate_tag' => ['required', 'string', 'min:3', 'max:255', Rule::unique('users')->ignoreModel($request->user())],
            'paypal_email' => ['required', 'string', 'max:255', 'email'],
        ]);

        DB::transaction(function () use ($request) {
            if ($request->input('affiliate_tag') != $request->user()->affiliate_tag) {
                User::where('referred_by', $request->user()->affiliate_tag)
                    ->update(['referred_by' => $request->input('affiliate_tag')]);
            }

            $request->user()->update([
                'affiliate_tag' => $request->input('affiliate_tag'),
                'paypal_email' => $request->input('paypal_email'),
            ]);
        });

        return redirect()->route('affiliate');
    }

Finally, we'll need a way of calculating how much our affiliate has earned. We can do this by adding together all invoices from referred users and calculating a percentage. To calculate the current balance, we'll only take into account invoices since the last payout date. We'll use Mattias' percentages package to make the calculation clearer.

use Mattiasgeniar\Percentage\Percentage;

const COMMISSION_PERCENTAGE = 20;

public function getReferralBalance() : int
{
    return Percentage::of(static::COMISSION_PERCENTAGE,
        $this->referred
            ->map(fn (User $user) => $user->invoices(false, ['created' => ['gte' => optional($this->cashed_out_at)->timestamp]]))
            ->flatten()
            ->map(fn (\Stripe\Invoice $invoice) => $invoice->subtotal)
            ->sum()
    );
}

The only thing left to do is to manually send affiliates their earnings at the end of each month and updating the cashed_out_at timestamp. Here's how our result looks:

Hope this was useful! This article started as a Twitter thread, you may want to follow me there for more semi-live-coding and tips. And if you'd like to see me do something like this in video format, you can subscribe to my YouTube channel, as I'm planning to produce more video content this summer. Have a great day!

After finishing my exams, I launched my startup

Miguel Piedrafita — Wed, 20 May 2020 01:00:36 +0000

I've been coding as a hobby since I was 10. I started building little projects and open-sourcing them and ended up building bigger and more ambitious projects. This year, after finishing my final exams, I launched a startup.

Meet Sitesauce, a service that can convert any site into a static site and deploy it to Vercel in seconds.

I started building Sitesauce a few months ago (using my regular Laravel-Vue stack), but never found a time to finally set it live. After quarantine hit and we finished our exams, I finally decided to share it with the world. It's been around two weeks since the launch, and Sitesauce has reached its first $1k of revenue!

If you're curious and want to learn more about how the launch went, I wrote an article about it. There's also another one talking about my journey building the app, if you're curious. You can also follow me on Twitter, where I'm sharing my journey as a maker.

Implementing VAT into a Laravel app with Stripe and Cashier

Miguel Piedrafita — Sat, 16 May 2020 23:00:00 +0000

I recently had to update the Sitesauce billing system to account for the European Value Added Tax (VAT). Here's a short article detailing how I implemented it.

First of all, I decided to get rid of as much of the existing billing-related logic as I possibly could. This meant implementing Stripe's new self-serve portal, which can take care of viewing invoices and managing payment methods and subscriptions. Since Cashier already takes care of keeping our database in sync with Stripe, the only thing we need to do is create a new session to redirect the user to.

public function portal(User $user)
    {
        $this->authorize('update', $user);

        return with(\Stripe\BillingPortal\Session::create([
            'customer' => $user->stripe_id,
            'return_url' => URL::previous(),
        ]), fn ($portal) => redirect($portal->url));
    }

Here's how the portal looks in action:

While we're fixing billing stuff, multiple people have complained that the current credit card input (while looking cool) does not work on Safari, which means you cannot currently complete the onboarding on iOS devices. Let's get rid of it and give the page a quick redesign.

Here's a before and after comparison of the Sitesauce billing page

You may now be wondering, where am I asking them for their credit card details? Instead of using Stripe Elements to capture their credit card details on page, I'm going to switch to the new Stripe Checkout, which will later make implementing VAT simpler.

To get it working we're gonna need to make two changes. First, we need to create a new checkout session and return the session ID, so we can redirect to checkout from the frontend. I've also added some logic to apply coupon codes, and fail validation if they don't exist.

public function checkout(Request $request)
    {
        $this->authorize('update', $user = $request->user());

        $request->validate([
            'plan' => ['required', 'string', 'in:monthly,yearly'],
            'coupon' => ['nullable', 'string'],
        ]);

        try {
            return with(\Stripe\Checkout\Session::create([
                'payment_method_types' => ['card'],
                'customer_email' => $user->email,
                'subscription_data' => [
                    'items' => [[ 'plan' => $request->input('plan')] ],
                    'coupon' => $request->input('coupon'),
                    'trial_period_days' => 7,
                ],
                'mode' => 'subscription',
                'client_reference_id' => $user->id,
                'success_url' => route('setup'),
                'cancel_url' => URL::previous(route('setup.billing')),
            ]), fn ($session) => $session->id);
        } catch (\Stripe\Exception\InvalidRequestException $e) {
            throw_unless($e->getStripeParam() == 'subscription_data[coupon]', $e);

            fail_validation('coupon', 'The specified coupon does not exist');
        }
    }

We also need to handle the checkout.session.completed webhook Stripe returns. We can do this by extending the default Stripe webhook controller and adding the following method:

public function handleCheckoutSessionCompleted(array $payload)
    {
        $session = $payload['data']['object'];
        $team = Team::findOrFail($session['client_reference_id']);

        DB::transaction(function () use ($session, $team) {
            $team->update(['stripe_id' => $session['customer']]);

            $team->subscriptions()->create([
                'name' => 'default',
                'stripe_id' => $session['subscription'],
                'stripe_status' => 'trialing',
                'stripe_plan' => Arr::get($session, 'display_items.0.plan.id'),
                'quantity' => 1,
                'trial_ends_at' => now()->addDays(7),
                'ends_at' => null,
            ]);
        });

        return $this->successMethod();
    }

Here's how our billing flow looks with all this implemented:

With both of these refactors done, it's time to dive into our main subject: VAT. Let's first make sure we understand what we need to implement:

// keep in mind this is based on a conversation I had with someone from the Spanish Tax Agency
// please consult with your accountant, I'm just a random teenager on the internet

it('should help me understand this mess', () => {
    if (! isEu()) return // nothing to do here, you lucky bastards are exempt from VAT

    if (isSpain()) {
        // users from the country I'm registered at need to pay VAT no matter what
        return 'apply 21% tax'
    }

    // okay, here's where it gets complicated
    const vatID = '...'

    if (vatID) {
        // if the customer has a VAT-ID, they handle all this mess by themselves and there's not much I need to do
        // still, I store their ID on Stripe for invoicing
        return addToStripe(vatID)
    }

    // if the customer doesn't have a VAT-ID, I need to apply their country's tax rate
    return `apply ${getTaxRate(getCountry())}% tax`
})

The first thing we need to do is detect the country our customer belongs to. For this, we'll use Cloudflare's IP Geolocation service to make an educated guess and correct it with the customer's credit card origin country after.

Once we know our customer's country, we can conditionally show the VAT-ID field when they're on the EU but not in Spain.

As I mentioned at the start, I want to be responsible for as little logic as possible. Luckly, Stripe has a tax system we can use. They unfortunately don't have built-in VAT support though, so we need to seed the data ourselves. Here's a quick script I made which takes an array of country codes and tax percentages and creates tax data on Stripe:

collect(['BE' => 21, 'BG' => 20, 'CZ' => 21, ...])->each(function ($percentage, $country) {
    \Stripe\TaxRate::create([
        'display_name' => 'VAT',
        'percentage' => $percentage,
        'inclusive' => false,
        'jurisdiction' => $country,
        'description' => 'VAT for '.locale_get_display_region('-'.$country, 'en')
    ]);
});

Here's how the result looks in our Stripe dashboard:

With the data seeded into Stripe, we can now tell Checkout to apply a specific tax when creating a subscription. To make this easier, I've created a TaxRate model using Caleb's Sushi package that fetches the rates from Stripe.

<?php

namespace App\Models;

use Sushi\Sushi;
use Stripe\TaxRate as StripeRate;
use Illuminate\Database\Eloquent\Model;

class TaxRate extends Model
{
    use Sushi;

    public function getRows() : array
    {
        return collect(StripeRate::all(['limit' => 100])->data)->map(fn (StripeRate $rate) => [
            'stripe_id' => $rate->id,
            'country' => $rate->jurisdiction,
        ])->toArray();
    }
}

Then, we query the model for our tax rate and apply it to Checkout (notice the default_tax_rates key on the subscription_data array below).

public function checkout(Request $request)
    {
        $this->authorize('update', $user = $request->user());

        $request->validate([
            'plan' => ['required', 'string', 'in:monthly,yearly'],
            'coupon' => ['nullable', 'string'],
        ]);

        try {
            return with(\Stripe\Checkout\Session::create([
                'payment_method_types' => ['card'],
                'customer_email' => $user->email,
                'subscription_data' => [
                    'items' => [[ 'plan' => $request->input('plan')] ],
                    'coupon' => $request->input('coupon'),
                    'trial_period_days' => 7,
                    'default_tax_rates' => [TaxRate::whereCountry(getCountry())->firstOrFail()->stripe_id],
                ],
                'mode' => 'subscription',
                'client_reference_id' => $user->id,
                'success_url' => route('setup'),
                'cancel_url' => URL::previous(route('setup.billing')),
            ]), fn ($session) => $session->id);
        } catch (\Stripe\Exception\InvalidRequestException $e) {
            throw_unless($e->getStripeParam() == 'subscription_data[coupon]', $e);

            fail_validation('coupon', 'The specified coupon does not exist');
        }
    }

This will not only apply the tax to the subscription, but also show our customer a nice breakdown of the costs.

Let's now work on the VAT-ID logic. As we learned before, we don't need to apply any taxes to customers who provide a VAT-ID, but we still want to register their id for invoicing. Checkout doesn't have any way of registering tax exemptions for new customers, but we can work around this by applying the tax after the customer has started their subscription, where we are able to register the exemption. To pass data around, we can use the metadata attribute.

public function checkout(Request $request)
    {
        $this->authorize('update', $user = $request->user());

        $request->validate([
            'plan' => ['required', 'string', 'in:monthly,yearly'],
            'vat' => ['bail', 'nullable', 'string'],
            'coupon' => ['nullable', 'string'],
        ]);

        try {
            return with(\Stripe\Checkout\Session::create([
                'payment_method_types' => ['card'],
                'metadata' => [
                    'vat_id' => $request->input('vat'),
                    'taxrate' => $taxRate = isEu() ? TaxRate::whereCountry(getCountry())->firstOrFail()->stripe_id : null,
                ],
                'customer_email' => $user->email,
                'subscription_data' => [
                    'items' => [[ 'plan' => $request->input('plan')] ],
                    'coupon' => $request->input('coupon'),
                    'trial_period_days' => 7,
                    'default_tax_rates' => $taxRate && is_null($request->input('vat')) ? [$taxRate] : [],
                ],
                'mode' => 'subscription',
                'client_reference_id' => $user->id,
                'success_url' => route('setup'),
                'cancel_url' => URL::previous(route('setup.billing')),
            ]), fn ($session) => $session->id);
        } catch (\Stripe\Exception\InvalidRequestException $e) {
            throw_unless($e->getStripeParam() == 'subscription_data[coupon]', $e);

            fail_validation('coupon', 'The specified coupon does not exist');
        }
    }

Then, we update our webhook code to register the exemption and add the tax after the customer has completed the checkout process.

public function handleCheckoutSessionCompleted(array $payload)
    {
        $session = $payload['data']['object'];
        $team = Team::findOrFail($session['client_reference_id']);

        // Add the subscription to the database as seen above, removed for brevity

        if (! is_null($vatId = Arr::get($session, 'metadata.vat_id'))) {
            \Stripe\Customer::createTaxId($session['customer'], [
                ['type' => 'eu_vat', 'value' => $vatId]
            ]);

            \Stripe\Customer::update($session['customer'], [
                'tax_exempt' => 'reverse'
            ]);

            \Stripe\Subscription::update($session['subscription'], [
                'default_tax_rates' => [Arr::get($session, 'metadata.taxrate')
            ]]);
        }

        return $this->successMethod();
    }

Now we just need to ensure our customer's VAT-ID is not only valid but also exists. We can use Danny Van Kooten's package to get this without any extra work on our part.

We won't need any special logic for Spanish users since the VAT-ID input is hidden for them, and so they'll always get taxed, ticking our last box on this VAT puzzle. Let's take a look at the result.

Hope this was useful! This article started as a Twitter thread, you may want to follow me there for more semi-live-coding and tips. And if you'd like to see me do something like this in video format, you can subscribe to my YouTube channel, planning to try producing more video content this summer. Have a great day!

How I Developed A Tool That Generates Static Versions Of Dynamic Websites

Miguel Piedrafita — Thu, 06 Feb 2020 08:41:01 +0000

I was interviewed for the 8BitMen blog about my experience developing Sitesauce. Here's a transcript of the interview.

Miguel is the Founder of Sitesauce, a tool that generates static versions of dynamic websites. Static sites can be rendered completely off a CDN hence are pretty quick to load as opposed to a dynamic site that needs a backend server to render different pages.

In a conversation that I had with Miguel, he shared insights into how he developed this novel product. So, without further ado. Let’s get on with it.

Tell us a bit about yourself

Hi! I’m Miguel Piedrafita, a 17-year-old maker from Spain who loves to spend his free time building cool things and learning. I’ve been coding for seven years now, in which I’ve contributed to over 500 open-source projects, and started multiple startups, including Blogcast, a platform that uses AI to produce audio versions of articles, and Sitesauce, a service that generates static sites from dynamic websites, and the one this article focuses on.

Tell us about your product. What pain points are you trying to solve?

I started Sitesauce out of frustration with both CMS platforms and static site generators. I wanted something as easy to customize and manage as WordPress or Ghost, but as fast, secure, easy, and cheap to host as static sites. I couldn’t find any product that covered this space, so I decided to build one using a novel approach to the static site generating I had been brainstorming for a different product.

So, how does Sitesauce work?

Basically, Sitesauce crawls your entire site, making your backend render each page and turning the results into static pages, then it automatically uploads them to Zeit or Netlify. Every time your content is changed (like, for example, when publishing an article), Sitesauce regenerates your site, making sure your static version is always updated with the latest content. It’s also incredibly fast and easy to set up, generating your site with the click of the button and in under a minute in most cases.

Would you like to talk about your customer acquisition strategy & the user engagement & retention rate?

Sure! That’s an interesting question, as I’ve never used any kind of paid acquisition technique for my products and prefer to rely on content marketing and social networks mostly. I’ve been growing my audience over the past few years, and continuously sharing my progress and updates on social networks has driven a considerable amount of traffic and leads to the service. The strategy is simple: be helpful on the internet, drop a link to your product in a non-intrusive way, and people who are looking for a solution will sign up.

What is your monthly revenue, if you don’t mind sharing?

Sitesauce is an open startup, which means all our numbers are public. At the time of writing this, MRR is at ~$76/month, but if you want to check real-time data and other interesting data out, have a tour around our Open Startup page.

Let’s talk about the technology stack you’ve leveraged to build your product

When I started working on Sitesauce, I just used my regular stack, that is, Laravel (PHP) for the backend + Vue.js for the frontend + Inertia.js for tying both together + Tailwind CSS for styling. I’ve tried multiple stacks over the years, but I feel this is the one that better adjusts to my way of thinking and makes me the most productive.

Two months into the product, I built a CLI tool to allow users to generate static sites from websites running locally in their computers without needing a publicly-accessible server. To build the Sitesauce CLI, I used Node, as I feel it’s the best language for creating CLI tools out there at the moment, only rivalled maybe by Go, which I didn’t know at the time. The CLI also has a backend component for temporally tunnelling local websites to the Sitesauce server, and that’s built on Node as well, mostly for consistency.

There’s a third component in the stack that I introduced recently: the generator. This component was initially a part of the Laravel application, but I ended up extracting it to a standalone Go CLI tool, which improved performance and speed massively.

To put it in context, it used to take around a minute to generate a static version of my personal website, and it can now process a site as big as the Laravel News website in that time. I did not know Go when I started, so I sort of learned along the way with intuition and much googling around, but it ended up turning out great.

The only external tool Sitesauce currently uses is Fathom Analytics, which does not only power our privacy-first analytics but also our public analytics dashboard, where you can also dive deeper into how people discover Sitesauce.

So, how’s your infrastructure organized? Which platform have you picked to deploy your service?

The frontend is structured as a Vue-powered SPA thanks to Inertia.js, which bridges the gap between the backend and the frontend and allows you to keep using traditional routing. The backend and all the different microservices (the CLI backend and the generator) communicate using an internal HTTP API and are all hosted on a Google Cloud VPS for simplicity.

The marketing site uses Statamic but is turned static and hosted on Zeit using Sitesauce to take advantage of all the benefits static sites provide (speed, infinite scaling, etc.). It also serves as a way to use Sitesauce on production and ensure everything works correctly (dogfooding!).

Zeit and their amazing CDN manage auto-scaling on the marketing page. For the actual app, scaling is handled manually by upscaling the server when needed.

Here’s a diagram showing how everything is organized and connected:

If you are interested in the running costs for our setup, there’s a conveniently-named costs section on our Open Startup page just for you 🙂

If you were to rebuild your service from the bare bones, is there anything you would do differently?

If I were to start building Sitesauce again, I’d make some changes to how certain features are offered (like removing the Netlify integration and focusing exclusively on Zeit). Still, I would undoubtedly keep the stack as it is now.

Are there any invaluable learnings during the whole product development process that you would like to share with the readers?

Try to get something you can charge someone for, then iterate on that and focus on everything else. This is something I learned from one of my previous projects, Snaptier, which failed because of an overly ambitious MVP (minimum viable product). I wrote about what happened and the lessons I learned from it here if you want to know more.

Is there any advice that you have for the entrepreneurs who aspire to or are already building their product from the ground up?

Share what you’re doing. Get people involved in your journey. Not only will it serve as an outreach for your product and grow your audience, but you’ll be helping others who are behind you on the same path.

Where can people keep up with what you’re doing?

The best place to find me is on Twitter, where I regularly tweet about what I’m working on, new things I learn as I go, and give tips I wish I had been given. You can also subscribe to my personal newsletter, a hand-made weekly email on a more personal tone, where I explain what I’ve been doing more extensively and share fresh content I find around.

Miguel, thank you for giving us a technical insight into your product & I wish you success as an entrepreneur.

Adding Two Factor Authentication to a Laravel application

Miguel Piedrafita — Fri, 25 Oct 2019 13:14:46 +0000

I recently added 2FA (Two Factor Authentication) support to Sitesauce. While I did follow some existing tutorials (this Scotch tutorial was really helpful) it still took me some hours of debugging to get everything running, so I thought I'd write about my approach in case it's useful to anyone else.

I started by requiring some composer packages to make our life easier. The first one will take care of generating and validating the codes (and also includes some Laravel magic to make our lives easier) while the second is required to generate QR codes the user can scan with their 2FA app.

composer require pragmarx/google2fa-laravel bacon/bacon-qr-code

The tutorial I linked above then proceeds to add 2FA on registration, but I wanted to make it an optional thing so I added it to the settings page instead. I added a button that, when clicked, would make an AJAX request to fetch a new code and its QR instead of associating it with the user directly. This way, if the user exists mid-process, they won't be locked out of their account.

use PragmaRX\Google2FALaravel\Facade as TwoFactor;

/**
* Generate two factor authentication keys.
*/
public function generate()
{
    $key = TwoFactor::generateSecretKey();

    return [
        'key' => $key,
        'qr' => TwoFactor::getQRCodeInline(
            config('app.name'), // A name for the code in 2FA apps
            auth()->user()->email, // The user's email
            $key,
        ),
    ];
}

The code above returns an array with two items: the secret key that the user will use to generate codes (and your app will use to verify them) and a QR code that the user can scan to easily configure their 2FA application of choice with your app.

Once the user has configured 2FA I ask them for a code before persisting any changes. This is a really common pattern across sites, and also helps ensure users won't get locked out of their accounts by misconfiguring their code-generating application. Once the code is verified, I save the secret key to a row in the users table.

use PragmaRX\Google2FALaravel\Facade as TwoFactor;

/**
* Validate & configure two-factor authentication.
*
* @param \Illuminate\Http\Request $request
* @return \Illuminate\Http\RedirectResponse
*/
public function configure(Request $request)
{
    $request->validate([
        'key' => ['required', 'string'],
        // PRO TIP: You can use closures to quickly create Laravel validation rules
        'code' => ['required', 'string', function ($attribute, $value, $fail) use ($request) {
            if (! TwoFactor::verifyKey($request->input('key'), $value)) {
                $fail('The code you provided is not valid.');
            }
        }],
    ]);

    $request->user()->update([
        'twofactor' => $request->input('key'), // This contains the secret key we generated earlier
    ]);

    return redirect()->back()->withSuccess('Two Factor Authentication has been successfully configured.');
}

Your users can now configure two-factor authentication but they can't disable it. Let's fix that.

/**
* Remove the specified resource from storage.
*
* @param \Illuminate\Http\Request $request
* @return \Illuminate\Http\RedirectResponse
*/
public function destroy(Request $request)
{
    $request->user()->update([
        'twofactor' => null,
    ]);

    return redirect()->back()->withSuccess('Two Factor Authentication has been successfully disabled.');
}

There's one piece left in the puzzle: enforcing 2FA on login if the user has configured it. For this, we can use the middleware bundled with the package we installed earlier:

// app/Http/Kernel.php
protected $routeMiddleware = [
    ...
    '2fa' => \PragmaRX\Google2FALaravel\Middleware::class,
];

// routes/web.php
Route::get('dashboard', 'DashboardController@index')->middleware('2fa');

This middleware will search for a view file on /resources/views/google2fa/index.blade.php (although you can configure this), so make sure to create that. For my specific case though, I made the following changes to get it working with Inertia.js

// app/Providers/AppServiceProvider.php
public function register()
{
    $this->app->singleton(\PragmaRX\Google2FALaravel\Support\Authenticator::class, function ($app) {
        return $app->make(\App\TwoFactorAuthenticator::class);
    });
}

// app/TwoFactorAuthenticator.php
class TwoFactorAuthenticator extends \PragmaRX\Google2FALaravel\Support\Authenticator
{
    protected function makeHtmlResponse($statusCode)
    {
        $inertia = inertia($this->config('view')); // Return an Inertia view instead of a View

        if ($statusCode !== 200) {
            session()->flash('errors', with($this->getErrorBagForStatusCode($statusCode), function($bag) {
                $bag->add('code', $bag->get('message')[0]);

                return (new \Illuminate\Support\ViewErrorBag)->put('default', $bag);
            })); // Add errors to the session, if any
        }

        return $inertia->toResponse(request())->setStatusCode($statusCode); // Return a regular Laravel response
    }
}

Congratulations! Your app now supports two-factor authentication. You should probably tweet it out so your users can start enjoying improved security while using your app.

// Detect dark theme var iframe = document.getElementById('tweet-1187488988594085888-732'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1187488988594085888&theme=dark" }

Building complex interfaces with Stripe Elements

Miguel Piedrafita — Fri, 25 Oct 2019 11:03:02 +0000

It all started with a Tweet by Muhammed Erdem where he showcased a cool credit card form he had designed on Codepen:

// Detect dark theme var iframe = document.getElementById('tweet-1186335420327645184-112'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1186335420327645184&theme=dark" }

I was using the standard Stripe Element input (pictured below) and challenged myseld to implement the above design into a real application.

Default input for Stripe Elements

I started by copying the styles for the card and moving the Vue code to a single file component (Card.vue). After getting the original code working on Sitesauce I noticed the first problem: the code was using regular inputs to capture the credit card details and show them in the card while I needed to use Stripe Elements to be able to process payments to that card.

After digging through Stripe's documentation I found that just as there was a Card element that encapsulated the card number, expiry date and CVC code there were individual CardNumber, CardExpiry and CardCvc elements that I could use.

My solution consisted on adding the inputs directly on the card. This involved updating the styling both on the card and on the elements (which you can do with the style & class options when creating it).

const cardNumber = elements.create('cardNumber', {
    classes: {
        base: 'card-item__number',
        focus: 'card-item__focus',
    },
    style: {
        base: {
            color: '#ffffff',
            lineHeight: '1',
            fontFamily: '"Source Code Pro", monospace',
            fontSmoothing: 'antialiased',
            fontSize: '27px',
            fontWeight: "500",
            '::placeholder': {
                color: '#cbd5e0'
            }
        },
        invalid: {
            color: '#fa755a',
            iconColor: '#fa755a'
        }
    }
})

I also updated the logic for detecting the card brand to rely on Stripe (which I assume is more accurate and also means I have less code to maintain) and added automatic focus to make the input more intuitive, and ended up with a really cool result.

// Detect dark theme var iframe = document.getElementById('tweet-1187478918967640064-78'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1187478918967640064&theme=dark" }

A video of the interface I ended up with

My first conference

Miguel Piedrafita — Mon, 14 Oct 2019 22:00:00 +0000

This summer, I attended LaraconEU Amsterdam. It was my first conference ever, and I had a great time, made some friends and even gave an improvised Unconference talk! Here's my attempt at describing my experience in Amsterdam.

👥 Meeting internet friends IRL

I arrived at the Schipol airport on Wednesday morning, a day before Laracon. I was really excited to finally meet two long-time online friends. We spent most of the day together, joking around and geeking about code, design, DevOps & other fun stuff (yeah, I know, what normal teenagers do).

🗣 The Unconference

I had joined the LaraconEU Telegram group earlier that day, and when I got home I was surprised to find out that Xander Smalbil, the organizer of the Unconference, had messaged me to ask if I wanted to give a talk. I initially said no, but after really thinking about it (and some peer pressure from Twitter) I finally agreed to do it. The next day, when I got to the venue, I wrote about the talk on a small piece of paper, and kind of forgot about it for the rest of the day.

1️⃣ The first day

I woke up relatively early (7:30 is early for me) and jumped into the ferry that would take me to the NDSM area, where the venue was. I checked in, got a cool lanyard and a badge with my name, and got inside.

I honestly didn't expect the venue to be so big. Maybe it's because it was my first ever conference and I didn't have anything to compare to, but I was really impressed. I spent some time awkwardly walking around (I'm kind of an introvert) and ended up sitting on a sofa and coding while I waited for the first talk to start.

The first break came after two great talks (the first one, about Persuasive Design Patterns, was especially awesome, one of the best IMO), and I finally started getting used to talking with people I only knew from Twitter. Meeting Caneco, who had been waiting to see "if I had a real face" really helped. Before I knew, it was time for more talks again.

Another three great talks (though I zoned out on the second one, not my topic I guess). The last one, a talk about the Laravel Notification System by Christoph Rumpel was probably the best of them. It was one of these talks where I didn't think I was gonna learn anything but ended up picking a few tricks. Anyway, Christoph was one of the people I wanted to meet, so I found him around the Unconference zone on the next break and joined into the conversation (in retrospect, the fact that this went well gave me a lot of confidence to continue approaching people and joining conversations the next day). He is a really nice guy, and we ended up talking a lot through the conference. We also took a picture that would later become my first photo online:

The rest of the day was filled with a rather chaotic lunch and some amazing talks (including one of the best talks on the entire conference if not the best, by Antti Rossi, a talk with amazingly-crafted slides by Caneco and a really interesting talk about performance by Kasia Zien). And, just like that, the first day was over. I wanted to join some folks for dinner, but my parents wanted me to spend the rest of the day with them (and, like, they weren't asking) so I caught the ferry again and got back into the boat-apartment my parents and I were staying in.

🌇 Oh shit the slides

When I arrived home, I luckily remembered I had to prepare some slides for my Unconference talk (don't want to think about what would have happened if I had forgotten). I opened Deckset and got to work. I wanted to get everything done quickly but I ended up spending a lot (and I mean A LOT) of time on the details, like carefully designing a pattern-based background for my slides with Sketch or coming up with jokes for placeholders on the examples. I finally finished the slides at 1 AM, put out a tweet in hopes someone would come to the talk (I was honestly afraid no one would) and went to bed.

2️⃣ The second day

I woke up early again, just a lot more nervous because I was completely sure I was going to mess up my talk. Fortunately, as I got into the venue, I got more and more relaxed until I just forgot about it. I was more comfortable talking with people, but still ended up coding a bit while waiting for the talks to start (I optimized one request from 5s to .2s using techniques learned at the performance talk from the day before and was really happy about it 😁).

The first talk of the day was somewhat boring for me (SOLID architecture isn't exactly my favorite topic), but after that, Dries' talk about Event Sourcing got me excited again. I kept talking more and more with a lot of different people on the break, and especially enjoyed Sebastian's talk on Inertia.js (which I've been trying out lately). After that was another technically difficult lunch (someone could say they... forgot to start horizon to process the queues) and a really interesting talk about deploying Laravel to Kubernetes (another one of the best talks in the entire conf). While I was learning how to use the kubectl CLI, I could feel I was getting more and more nervous about what came next.

🗣 My Unconference Talk

I left as soon as the Kubernetes talk ended, and moved to the Unconference zone to listen to Povilas' unconf talk on managing junior developers (ironic, I know). I checked multiple times to make sure my slides hadn't magically disappeared (they were still there) and nervously shifted in my seat, growing nervous as my clock approached three o'clock. And finally, Povilas hanged the mic over to me.

After some problems when setting up the screen (which Cristoph helped me with), I finally started. I was really nervous (and maybe talked a little bit too fast) but people seemed to be enjoying the talk. When I finished, I got A LOT of positive feedback from everyone. In retrospect, it was an awesome experience, and I'm really looking forward to doing it again soon (and hopefully at the main stage next year 😁).

🔥 <<<EOC (End of Conference)

After my unconf talk, a break and another talk, it was finally time for the big reveal. Freek and Marcel went on stage to talk about Ignition, a Whoops replacement for Laravel 6.0 and Flare, an exception reporting service. It was an awesome presentation, and I'm hoping to write some cool Ignition extensions soon.

Then it was finally time for Taylor to close the conference with his keynote. He talked about all the new things coming to Laravel 6.0, and he mentioned my unconf talk because I spoiled some of his black magic. Sorry, Taylor! 😁

🌆 After-Dark

After the conference finished, I had dinner with a bunch of fellow artisans, including Taylor and David Hemphill. We talked about Vapor, Nova, Forge, Laravel Cloud, open-source & general cool stuff, joked around and tried to avoid getting our food raided with bees.

After that we headed to the After-Dark, where I had lots of great conversations with almost everyone that attended, and also got to meet and talk with Freek & Marcel, two people I strongly admire for their contributions to the Laravel community & open-source. I stayed there, talking with people until 1 AM, when my parents came to pick me up.

👋 Goodbye, Laracon!

I had one of the best times of my life at this conference. The talks were great, everyone was incredibly nice, I met lots of great people & learned a lot of cool stuff. I hope I'll be able to come back next year (hopefully as a speaker, we'll see).

This article was first sent to my personal newsletter a day after Laracon. If you're interested in knowing what I'm working on and get insider info on my work, you'll probably want to join.

Building Sitesauce: static sites for everyone

Miguel Piedrafita — Sun, 13 Oct 2019 15:14:48 +0000

If you follow me on Twitter you have surely seen me tweet about the project, teasing out little details of my "secret project". I've had a lot of fun with cryptic tweets and blurred out screenshots but now that the project has reached a usable state (in fact both this website you're on right now and the Sitesauce landing page are using it) it's finally come time to announce what this thing I've been building since I came back from LaraconEU actually is.

It all started last Christmas when I was looking to move from my Ghost setup to a static-site generator. I had suffered from a server incident that took my website online and was looking for a solution where my online presence didn't depend on a server going down while I was sleeping. I looked around for better options and noticed that a few sites I had on Netlify had a 100% uptime in the last three months and started looking into Netlify and static sites. While my main concern was with uptime, other benefits like almost-instant loading times, incredible scaling or unbreakable security (there's nothing to hack when you're dealing with HTML files) motivated me to make the move. I continued using Ghost as a data-source but switched to Jigsaw.

It took a while to get things where I wanted them to be. I had to rewrite my Ghost theme to a new templating engine, modify some of the Jigsaw core to make it work like I wanted to and manually trigger a new build every time I changed something. It also meant an added layer of complexity, not being able to instantly preview my changes and more things that distracted me from writing, which is why I had been using Ghost in the first place. I ended up getting all the static benefits, but at a high time & complexity cost, so I started thinking about how to make switching simpler.

What I set out to build was a one-click solution that got rid of all the drawbacks that I had experienced and worked with any platform , be it Ghost, Wordpress, Statamic, a Laravel-based blog or any other CMS. I worked on it for a few days, but some technical problems with my implementation made me give up. I threw the code on a private repo and forgot about it.

Fast-forward to LaraconEU, where a new Laravel feature (Lazy Collections) and a talk about improving performance gave me some tips on how could I make my implementation work. I then rescued my old code and managed to get a basic prototype working. Since then, I've been hands-down working on fixing edge-cases and building the best experience for everyone using Sitesauce.

I'm incredibly excited to finally share my work with everyone and continue building it in the open. You can get more information about Sitesauce and sign up for early access here.