Why do I need Form.io’s APIs? We have our own databases that store submission data, why would I need Form.io?
If this is what you’re thinking, I understand and it’s a valid question, but keep reading.
Sketching The Scenario
Let’s say you’ve built an application that services, I don’t know, maybe 1,000 agencies. Sounds ludicrous, but it’s helpful for our not-actually-made-up thought experiment here (yes this scenario is real).
This application collects user submissions for all kinds of things and let’s say there are millions of users.
Each of these agencies need HUNDREDS of their own, unique forms.
You could build all those forms from scratch with a legion of developers, but you already know it’s 1,000 times easier to build them in Form.io with the drag and drop form builder, or even better, have a small team of regular-non-developer-folk from each agency build their own forms.
They know what they need better than you do anyway.
By default, when a user clicks submit on a Form.io form, Form.io’s Submission API is called and that data is stored in Form.io’s MongoDB database.
But that’s not exactly what you need—because each agency has their own database and tools that store, report, and manage that data.
No problem.
You don’t have to use our form Submission API. You can use whatever API you want to send that data to where it needs to be.
The Core Value Of Having A Form Management Platform
In our scenario, each one of those small teams from their respective agencies is leveraging the Form API to create, edit, and manage all the forms they need.
Form.io is operating as a form management platform. It’s a single source of truth that houses all 100,000+ forms in our scenario.
The definitions of the forms, what KINDS of data they collect, through which components, what actions the execute, what they connect to, etc.
But not the actual user submission data itself in this scenario—it doesn’t have to.
ALSO, and here’s the key, all those forms are embedded in your super application:
- Not with the HTML
- Not with a clunky iframe
- Not even directly with JSON definitions that get rendered into HTML
Instead, each form is embedded with an instruction, a call to the Form API, that basically says “give me [form-name].”
So when a user loads a page in your application, any forms that are on that page are fetched from your deployed Form.io instance, at that moment.
That snippet of code with the API call/instruction that is embedded in the application never changes.
Which means that all those small teams in each agency can modify and update their forms, anytime they want, independent from you. No one has to bother you, or any other developer to make a change to a form. Yesterday a form that appears in your app may have had 3 fields. Today it has 4. No need to update any code in the app.
Decoupled.
This is one of the big values with Form.io. This is what organizations ask for the most—the ability to free their developers from having to deal with forms in the applications they’re building, so they can do other things. It often cuts development time in HALF.
That’s what the Form API does, even if you’re using your own form submission APIs.
Papers Please
For some of the agencies managed by this app, they still accept, and sometimes still demand a partially-completed-printed-out form—yes, a PAPER form.
And it has to be perfect—the form—it has to be their official form, with all their boxes and fine print, but with partially filled in data.
For these agencies, they’ve leveraged Form.io to create pixel-perfect PDF forms.
When a user views a page with this kind of form, they can either see a standard web form or the branded, fillable PDF that looks exactly like the paper version—either version works. Then the user can fill in the fields they have information for and leave the rest blank. Again, a partially-completed form is all that’s needed.
When the user clicks Submit (or View PDF), a PDF is generated using Form.io’s PDF API.
Voila, the PDF, with their information pre-filled, opens in a new tab, which they can download, or print and mail it to the specific agency’s office.
Once again, no call was made to the submission API.
The D-Team And The B-Team
In 8th grade, I only made my school’s Soccer B-Team, not the A-Team. It happens. I did a good job, but I just wasn’t an A-player—or I didn’t have an in with the coaches—I’ll never know. That’s another story.
The difference in our scenario is that there are going to be some folks on the D-for-developer-team and some on the B-for-business-user team. For the purposes of this post, everyone’s an A-player in their domain, okay? Good.
And so someone within each agency creates two teams using the Teams API, one team for the developers who have more access to accomplish developer things and a second team for the business users who are mostly responsible for creating and managing the forms.
No offense to the B-team, but they shouldn’t necessarily have the same level of access as the D-team so that they don’t accidentally mess something up.
At one point or another, all of us have been the person who knows enough to be dangerous. The Teams API enables an administrator to create a layer of protection around the B-team, so those dangerous moves are contained.
Again, none of this involves our Submission API.
Easy Street APIs
Maybe it was obvious, but this scenario paints a picture of a multi-tenanted environment. The super app is servicing 1,000+ tenants.
The Multi-Tenant API enables you to create a primary project that then allows this project to operate as a template for all other tenants created as sub-projects.
Which means when any given tenant/agency logs in to your app, they only see their own forms, not everyone else’s. Besides, no one group should manage 100k+ forms.
But it gets better.
Let’s say the drag and drop form builder is embedded in your app. Because you’re not creating 100k forms yourself, remember? Small teams from each agency will build their own when they login to your app.
But each agency is a little different from the others. You may want to customize the form builder itself, for each tenant. That may involve hiding some complex components they’ll never use, renaming some components to match agency vernacular, and/or creating a custom component that’s unique to that agency.
For example, what if each agency needs to slap their logo at the top of their forms?
No problem.
Each agency can build a logo component, unique for them, that lets them drag their logo onto a form.
The Multi-Tenant API enables you to provide granular, tailored experiences to each of your tenants.
Another thing on managing tenants.
99.99% of the time, each tenant is already going to have a database of users…somewhere else. You can configure each tenant’s authentication schema to leverage their existing user databases so users don’t have to create yet another login.
Our Enterprise Form Builder (working name) together with the Multi-Tenant API makes this easy.
A Suite Of APIs
We know that not all of our customers need to use our Submission API, and that’s okay, but Form.io’s suite of APIs go far beyond passing data as they also:
- Provide a JSON standard for how all submission data is structured.
- Help you manage the deployments of development, testing, and production environments because you can integrate APIs into your CI/CD pipelines
- Help you manage projects, forms, resources, tenants, teams, roles, permissions, actions, and PDFs
- Enable you to build advanced functionality in your runtime application
If you want to see the full list of APIs you can leverage in your app, check out https://apidocs.form.io/.
Even if you’re not managing 1,000 tenants, you might need to manage 100s or 1,000s of forms in your app and the users working with them—across multiple environments. Having API-driven tools to tackle this heavy-lift can mean the difference between going to market in 6 weeks instead of 6 months.
It’s worth mentioning that our Submission API makes server-side validation of forms effortless.
One more thing I hinted at earlier.
Form.io, as a platform, deploys in your environment. We have a SaaS app, but 90% of our customers self-host Form.io, which means that it’s not just the forms that embed in your environment, it’s all the tools and platform that embed in your environment—for a true native experience.