The Story Behind SnipForm

Jumping into serverless hosting for our public pages was a game-changer. Lighting page speeds, instant deployment with nothing to provision. Amazing. A smooth ride, until I hit a speed bump: the contact form - a server side requirement.

I'm not the first to get here, the market is flooded with form services for exactly this purpose. Yet they basically all parade the same offering: They give you a unique endpoint for your form to post to, example:

<form action="https://some-pricey-serivce.io/<your-form-id>" method="post" >

It seemed straightforward until it wasn't. Them glaring issues:

  1. Exposed Endpoints: These endpoints are sitting ducks, openly advertised in your page's source view and wide open for any bot to target.
  2. Security Overheads: Implementing security measures like reCaptcha was necessary and cumbersome, often detracting from the user experience yet still leaking in spam.
  3. Data Validation? Ye, nah: These services would accept any form data - no questions asked. Pushing the responsibility of validation onto me which I could only do client-side. And since it's client-side it can be easily bypassed (and it was).
  4. Clunky Response Handling: Managing the success/error responses from these form services added another layer of hackiness, disrupting the seamless user experience I envisioned.

The deal-breaker for me though was the cost.

The pricing model for most was a subscription plan limited by submissions. A submission tally that's out of my control and where the surplus didn't carry over into the next month. So if you had a quiet month, you pay your rate. If you had a busy month, you pay your rate and at some point your form stops working. Awesome.

So... I built SnipForm

Well, not at first, and not out of some grand vision, but out of necessity. I needed something that wasn't just a band-aid but a solution. So, deciding to take matters into my own hands, I forged ahead to build a central backend service for all my forms - addressing these issues head on.

What I didn't expect was just how transformative my internal project would be. Spam literally disappeared overnight (still waiting for a leak), in fact, I initially thought the forms were broken and kept filling them out on my sites to check. More striking though was the rediculous ease of integration and the dev experience that came with it. It just worked.

This convinced me of its broader value. So, I gave it a name, SnipForm, and released it to the public.

How SnipForm Works:

SnipForm parses your HTML form and adds a stateful engine to handle everything for you. The engine handles security, validation, error states, valid states, loading/submit states and result content state, right out the box.

You simply build your form to your own design and wrap it in <snip-form> tags to apply the engine. Then, in your markup, you can add various directives (attributes) to configure the features you require. Example:

<snip-form key="YOUR_KEY">
    <!-- Your normal form -->
    <form>
        <div class="mb-2">
            <label for="name" class="form-label">Full Name</label>
            <input sf-validate:required="Please enter your name" type="text" name="full_name" id="name" class="form-input" />
            <p error-show:full_name error-text:full_name class="form-error-text"></p>
        </div>
        <div class="mb-2">
            <label for="email" class="form-label">Email</label>
            <input sf-validate:email type="email" name="email" id="email" class="form-input" placeholder="[email protected]" />
            <p error-show:email error-text:email class="form-error-text"></p>
        </div>
        <div class="flex justify-end">
            <button type="submit" class="form-button">Submit</button>
        </div>
    </form>
    <!-- /Your normal form -->
</snip-form>

In the above example, the name field is required (and will return the message "Please enter your name") and the email field is required to be an email address. Below the input fields, I've added a paragraph tag to display the error message if the field did not validate. If they are valid, then the tag will be hidden.

This is just a basic example. If you're curious, you can see a full (and over the top) example here.

How SnipForm Solved the Issues:

  • Security: Security wasn't built as a feature; it was the foundation. Each form request (ie page view of the form) will load a unique temporary endpoint (along with a few other security features). These dynamic, ephemeral URLs turn form endpoints into moving targets, elusive to bots.
  • Built-In Validation: Validation was no afterthought, it was baked right into the engine to load them server-side where they are tamper-proof and robust, completely sidestepping the inadequacies of client-side efforts.
  • Seamless Integration: The goal was to equip the form (as is) with a secure, validated backend without disrupting its design or function. Ensuring an effortless implementation to managing both successes and errors, all without interrupting the user's journey on the site.
  • reCaptcha Integration: LOL, no.

Once I decided to make SnipForm public, it was important to make it as accessible as possible with no goddam submission limits - even on the free plan. Perhaps a bad idea, but I'm happy to take the hit on that.

Reflecting on the Journey:

SnipForm's creation was a pivotal moment. It started as a way to solve my own problem, but it quickly grew into something much bigger.

It became more than a tool; It's a testament to the idea that great solutions often come from deep personal frustration. It's a reminder that sometimes, the tools we need aren't out there yet. Sometimes, we need to roll up our sleeves and build them ourselves.