DEV Community

Cover image for I Got Tired of Building Backends for Forms, So I Built FORX
Ezekiel
Ezekiel

Posted on

I Got Tired of Building Backends for Forms, So I Built FORX

I Got Tired of Building Backends for Forms, So I Built FORX

I don't know if I'm the only developer who does this.

You need a simple contact form.

So you create the HTML.

Then you realize:

“Okay, where does this form data actually go?”

And suddenly your tiny contact form needs a backend.

You start thinking about API routes, databases, validation, authentication, email notifications, spam protection, deployment...

All that.

For a form.

That was basically the reason I started building FORX.

The problem

Let's say I'm building a portfolio.

I want a simple form where someone can enter:

  • Name
  • Email
  • Message

That's it.

I don't necessarily want to create a database.

I don't want to build an API.

I don't want to deploy another backend.

I just want the submissions to go somewhere.

And I realized this isn't only useful for contact forms.

The same thing applies to:

  • Waitlists
  • Feedback forms
  • Surveys
  • Job applications
  • Event registrations
  • Portfolio inquiries
  • Simple data collection
  • Landing page forms

A lot of these projects don't need a full backend.

They just need a place to send the data.

So I started thinking:

What if the backend was already there?

That's FORX

FORX is basically forms without the backend.

You create an endpoint with FORX, connect your form to it, and whenever someone submits the form, FORX receives the data.

Your architecture can look something like this:

Your website
|
| POST request
v
FORX endpoint
|
v
Submission stored
|
v
FORX dashboard

That's the idea.

No database setup.

No API route.

No backend to deploy.

Just your form.

The simplest example

Imagine I have this contact form:

< form action="YOUR_FORX_ENDPOINT" method="POST">
< input
type="text"
name="name"
placeholder="Your name"
required
/>

< input
type="email"
name="email"
placeholder="Your email"
required
/>

< textarea
name="message"
placeholder="Your message"
required

</ textarea >

< button type="submit">
Send message
</ button >
</ form >

Instead of writing my own API endpoint, I point the form's "action" to my FORX endpoint.

That's basically it.

When someone submits the form, FORX receives the POST request and handles the submission.

Your frontend doesn't really care where the backend is.

It just sends the request.

Why not just build a backend?

You absolutely can.

That's actually the point.

If you're building something complex, you probably should build your own backend.

FORX isn't trying to replace that.

But sometimes you're building something like:

portfolio.html
landing-page.html
contact.html

And you just need:

POST /contact

You don't want to spend an afternoon setting up infrastructure for it.

I know I don't.

I wanted FORX to feel stupidly simple

One thing I've been thinking about while building FORX is that infrastructure products can sometimes become more complicated than the problem they're solving.

I didn't want:

“Welcome to FORX. Before you create your first form, please configure seventeen things.”

I wanted something closer to:

Create endpoint

Copy endpoint

Put it in your form

Receive submissions

That's the experience I'm aiming for.

But it's not just contact forms

This is probably the part I'm most interested in.

FORX can be used anywhere you need to collect data from a frontend without wanting to build the backend yourself.

For example, imagine you're launching a small project and want to collect emails.

You could have:

< form action="YOUR_FORX_ENDPOINT" method="POST">
< input
type="email"
name="email"
placeholder="you@example.com"
/>

< button type="submit">
Join the waitlist
</ button >

Or maybe you're building a portfolio and want people to contact you.

Or you're making a small survey.

Or you want to collect feedback from users.

The frontend stays yours.

FORX just handles the boring part behind it.

One feature I really wanted: domain restrictions

There's also something I think is important when you're accepting submissions from the public.

You don't necessarily want your endpoint being used by random websites.

So FORX lets you configure allowed domains for an endpoint.

That means you can say:

This endpoint should only accept submissions from my website.

It's a small feature, but it's one of those things that becomes important once you actually put a form on the internet.

The developer in me still wanted an endpoint

I also didn't want FORX to feel like one of those form builders where you're forced into a specific UI.

Your form can still be completely yours.

You can use:

  • Plain HTML
  • React
  • Next.js
  • Vue
  • Astro
  • Svelte
  • Basically anything that can make an HTTP request

FORX doesn't need to know what your frontend looks like.

It just needs to receive the request.

That's what I like about the idea.

Why I built it

This project started from one of those “surely someone has already solved this” moments.

I was thinking about forms and backend infrastructure, and I realized there was an interesting gap between:

“I need a backend.”

and

“I need somewhere for this form submission to go.”

Those aren't always the same problem.

And maybe developers shouldn't have to build an entire backend every time they want to collect a few pieces of data.

That's basically what I'm trying to solve with FORX.

Not every form needs a backend.

Sometimes the backend should just exist.

FORX is still evolving

I'm still building it.

There are a lot of things I want to improve and add.

I'm also still figuring out exactly how far I want to take the product.

Because honestly, one of the fun parts of building something from scratch is discovering what people actually use it for.

Maybe someone will use FORX for a portfolio contact form.

Maybe someone will use it for a waitlist.

Maybe someone will do something I didn't even think about.

That's kind of the point.

Try it

If you're building a portfolio, landing page, survey, waitlist, contact form, or basically anything that needs to collect data, you can check out FORX here:

Create an endpoint, connect it to your form, and see how it feels.

I'm especially interested in hearing what you would use it for.

Because at the end of the day, I built FORX for a pretty simple reason:

I don't want to build another backend just to receive a form submission.

And maybe you don't either. 🦊

Top comments (0)