A Beginner's Guide to Form Backends: What They Are and When You Need One

A Beginner's Guide to Form Backends: What They Are and When You Need One — with onsubmit.dev (form backend)

You built a portfolio site. The contact form looks great. The validation works. Then you click “Send” and realize there’s one missing piece: where does the form data actually go? This is where a form backend comes in. Services such as onsubmit.dev (form backend) give your form an endpoint that can receive submissions without requiring you to build and deploy your own server.

If you’re learning frontend development, this distinction can be confusing at first. Let’s look at what happens after a user presses Submit, what “form backend as a service” means, and when using one makes more sense than writing an API yourself.

A form is only the frontend

Consider a contact form containing a few familiar fields:

• Name
• Email
• Message

HTML can collect those values, and JavaScript can validate them or improve the user experience. But something still needs to receive the submitted data and do something useful with it.

In a traditional application, the flow might look like this:

Browser
   |
   | POST form data
   v
Your API server
   |
   +--> validate input
   +--> store data
   +--> send email/notification
   +--> return a response

That API server is the form's backend.

Building one can mean creating an API route, configuring a server or serverless function, validating input, handling errors, managing secrets, preventing abuse, and deploying and maintaining the whole thing.

Those are valuable skills to learn. They can also be unnecessary infrastructure when all you want is a working contact form.

What is a “form backend as a service”?

A form backend service provides the server-side endpoint for you.

Instead of sending submissions to an API that you wrote:

Browser -> Your frontend -> Your API -> Destination

you send them to a managed form backend:

Browser -> Your frontend -> Form backend service -> Destination

The important idea is that your website can remain frontend-only.

For example, you could host a static portfolio on a platform or CDN without provisioning your own application server just to process its contact form.

A form backend generally takes responsibility for receiving the HTTP request and processing the submission. Depending on the service and configuration, it may also cover things such as validation, notifications, storage, or integrations.

That makes this pattern particularly useful for static sites and relatively simple forms.

When should you use one?

A managed form backend is a good fit when the form itself isn't an important part of your application's business logic.

Common examples include portfolio contact forms, landing-page inquiries, feedback forms, waitlists, and simple lead-generation forms.

Imagine you're a junior developer building your portfolio. Creating an entire Express application, database, deployment pipeline, and email integration just so recruiters can send you a message probably isn't the best use of the project's complexity budget.

A form backend can keep that portfolio essentially static while still giving the form somewhere useful to send its data.

It can also be handy for prototypes. If you're testing whether people are interested in an idea, getting the form online quickly may matter much more than designing a permanent backend architecture.

When should you build the backend yourself?

Form backends aren't substitutes for every API.

Suppose you're creating a banking application and a submitted form initiates a money transfer. That isn't simply a message you need to collect. It involves authentication, authorization, account state, transactional database operations, auditing, and application-specific security rules.

That belongs in application backend code you control.

The same applies when a submission is deeply tied to your domain model. Creating an order, modifying a user account, accessing sensitive internal systems, or running a complicated application-specific workflow will usually require your own backend.

A useful question is:

“Am I collecting a submission, or executing my application's business logic?”

For straightforward collection, a managed service may be sufficient. For application business logic, build the appropriate backend.

There is also plenty of room between those extremes. Your requirements can grow over time, so choosing a managed service today doesn't prevent you from replacing it with your own API later.

A worked example with onsubmit.dev (form backend)

As an example of the managed approach, onsubmit.dev (form backend) provides form endpoints without requiring you to operate your own backend.

The service also provides integrations/packages for React, Next.js, Vue, and Astro, so it can fit into projects built with those frameworks rather than requiring you to restructure the application around a separate server.

The important architectural change is small:

Before:

<form>
    ↓
Nowhere to send the data


With a form backend:

<form>
    ↓
Managed endpoint
    ↓
Submission gets processed

To build the actual implementation, create/configure the form endpoint and follow the service's documentation for your framework at https://onsubmit.dev/docs and https://onsubmit.dev/integrations.

This is worth emphasizing for beginners: an endpoint URL isn't just a magic string. It represents the server receiving your HTTP request. With a managed form backend, someone else operates that server-side layer for you.

What about JavaScript validation?

Client-side validation and backend processing solve different problems.

For example, your frontend might check whether an email looks valid before allowing a submission. That's useful because users receive immediate feedback.

But frontend validation runs in the user's browser and can be bypassed. You should never treat it as a security boundary.

Think of the responsibilities this way:

Frontend:
- Display the form
- Improve UX
- Catch obvious input mistakes
- Show loading/success/error states

Backend:
- Receive the request
- Treat input as untrusted
- Process the submission
- Perform server-side checks
- Return a result

That remains true whether you wrote the backend yourself or use a form backend service.

“But shouldn't I build it myself to learn?”

Sometimes, absolutely.

If your goal is to learn backend development, building a form API is a great exercise. You can learn HTTP methods, request bodies, server-side validation, status codes, databases, environment variables, email APIs, security, and deployment from a relatively approachable project.

But learning how to build infrastructure and deciding whether a production project needs that infrastructure are two different skills.

Developers routinely rely on managed databases, authentication providers, payment processors, email APIs, cloud storage, and other services. Form handling can be another example of choosing a managed component when implementing it yourself provides little project-specific value.

The main takeaway

Submitting a form is fundamentally an HTTP interaction: the browser collects some data and sends it somewhere. The moment you need to receive, validate, store, forward, or otherwise process that data on a server, you've entered backend territory.

You then have a choice.

Build that backend yourself when the submission involves your application's business logic, specialized security requirements, or workflows that require deeper control. Consider a form backend as a service when you're primarily collecting straightforward submissions and don't want to operate server-side infrastructure just for that purpose.

Understanding that tradeoff is more useful than always reaching for one solution. The goal isn't to avoid backend development—it's to know when your project actually needs a custom backend and when a managed endpoint is enough.