by Joe Marshall on June 6th, 2020
When you're designing a JAMstack site (Javascript - Markup - APIs) there's a good chance you'll need a form, contact or otherwise, which begs the question - where to send its data? Normally you'd have a server sitting somewhere on your network listening to those POST requests, but the whole JAMstack approach sort of precludes that.
That means you basically have three options:
I kid. This invalidates your whole reason for going JAMstack in the first place! It also creates both a performance bottleneck and the whole need-for-managing-infrastructure thing you're getting into JAMstack to avoid.
Part of JAMstack is taking a jumble of server logic and trying to build it into reusable, component-ized APIs that are then served over HTTPs to interact with the dynamic Javascript you're serving up on your CDN. Depending on what else you have to do with your API, adding some form API component might be as easy as grafting on another function. But if your app only allows limited interaction and you don't have that much API functionality already, it might be smarter not to roll-your-own.
Though you have the intermediate option in the form of setting up your own open source form backend with something like Formplug that still leads you into the issue of managing your own infrastructure.
If you already have your own Lambda, SES, etc services set up it makes sense but if not, it might be a bit much for forms. That leads you to a managed backend form service.
ahem
Creating a quick JAMstack-friendly form is easy using Formcake, and allows you to pipe the information you collect to whatever source you'd like via webhooks, email, or our Zapier integration, without having to rely on coding your own integrations.
But whichever route you choose (well, except the server), there's a way to make JAMstack compatible with forms without having to sacrifice the security, stability, and performance of the JAMstack.