Form to DB(formtodb.com) |
Form to DB(formtodb.com) |
So we decided to build a form builder. It allows you to:
1. Send data directly to your database (Postgres in our case), your data warehouse, or wherever else you want it
2. Write JS almost anywhere on the front-end, including libraries like moment and lodash, for custom validations, conditional logic, and data parsing
3. Run any arbitrary code in form submission (or validation), via our Workflows product
4. Store it in our database (where we give you a connection string), or your own database
5. Self-host it in your own VPC
And it’s free with no arbitrary limits on the number of users, forms or submissions.
I’m hoping to ship a bunch more features like integration to any REST API, more styling options, etc. If you have any feedback please let me know!
> and b) building my own frontend (probably via React, and then maybe via formik)
There's also a new technology called HTML. It comes with a <form> tag, <input> field tags, and even a <button> to submit!
Although new, they managed to get all browsers on board to support it.
You will not need to import 150kb of JavaScript, though, which is sad. And it's not shiny to speak about in the interview for your next job.
I guess the pros dont overweight these cons... Yes, "probably via React" is the way!
It has an "action" attribute that points to a server you need to own and run a code you need to code in order to validate the input and store it in the database. If you are comfortable doing this, which no doubt you are, then you are not the target audience of this tool.
I’m curious how to interpret the “trusted by” statement here
Does this count: https://airforms.com/
When did you start building it? Budibase does exactly this since 2020.
https://docs.retool.com/education/labs/self-hosted
Edit: the right page seems to be https://docs.retool.com/self-hosted but it’s about Retool in general; I doubt you need 8 vCPUs and 16GB of RAM to host forms [1].
[1]: https://docs.retool.com/self-hosted/quickstarts/docker#vm-co...
I enjoy the technical side, but I'm struggling to commercialise it so don't hesitate to give me your feedback here or on https://www.myowndb.com/contact.html which is of course powered by a myowndb public form :-)
Where were all these alternatives when I was looking for a WYSIWYG form builder?
Retool is very widely adopted by major companies.
I may very well be nitpicking unfairly here, those marketing "trusted by" blocks on brand new products just always rub me the wrong way.
I said this in a sibling comment too, I may just be unfairly nitpicking here but these "trusted by" marketing blocks just rub me the wrong way when the product is brand new.
For building Retool Apps/Workflows, our pricing is here: https://retool.com/pricing
I never really understood why InfoPath didn't catch on better.
- We still had to have paper forms for legally required forms in case someone didn’t have a computer, etc. so then we needed a regular printable PDF. InfoPath native forms had issues with printing.
- The InfoPath-PDF integration was not very good and not usable for my production.
- The data on the other end went into bizarre formats and thus needed a job to convert it to the format we needed (and take action).
In the end this solution was deployed, and shockingly is still online and in production in 15 years later:
- A graphic designer (often an intern) took the original paper forms or fillable PDFs and made basic HTML forms with them.
- jQuery used for user friendly form validation.
- These forms were integrated with an SSO to allow e-signing.
- “Print” and “Submit” buttons on the form invoked a Perl script which (1) transformed the HTML form to having the content filled in, (2) ran headless Firefox and print-to-PDF to archive the form for legal purposes, (3) stored the form values in the native database, and (4) fired off a stored procedure based on the form name.
In effect, the same things InfoPath was supposed to do, but it didn’t need a dedicated administrator or complex integrations.
Don't get me wrong, it was an amazing tool for its day, but had some steep and proprietary onramps that limited adoption. I'm personally not at all surprised that it faded from general consciousness.
It was surprisingly good at letting non-computer-people build data gathering applications though.
Plenty “SSR” (the only place to render, so it wasn’t called that) tempting engines of the day, if you had an ODBC connection, you could generate form handlers with “one click”.
Of course, this was also before OWASP (started circa 2001)...
Which should I use for new projects? I assume the new one?
i assume for amazon, mercedes, etc. it's talking about retool? or are there some employees using formtodb?
Grist is open source, Python scriptable and each project is stored in a SQLite database.
Thus I came to the conclusion that any Access database is probably better off being a spreadsheet, even with all the chaos that not having forms as a front end and not having relational structure entails. At least people can understand other peoples spreadsheets (up to a point)
Recently I discovered https://directus.io/ which comes pretty close and it's open source.
* Forms (ie the product here) is free.
* We’ve always aimed to build a sustainable business where we charge reasonable prices and can guarantee we’ll stay in business ourselves. It’s true there are other products that are cheaper, but every single one of those companies is unprofitable and many will probably be dead in a few years. See, for example, Airplane, Interval, or Dynaboard. Dynaboard just got acquired today (their founder is apparently “thrilled” about it: https://dynaboard.com/blog/figma-acquires-dynaboard) and they’re shutting down on April 30th. If you’re a paying customer you’ll need to rebuild all your apps by then. Ouch! (I’d rather pay more and not have worry about core pieces of my business getting shut down with three months’ notice.)
You're right that it's a big concern, but it's a pretty tough sell to solve this problem by just charging so much that it's clear you could not possibly go out of business. I had to go pretty far down the list of your top competitors to find a good one that was open source, but I did find it.
All that said, Retool's pricing at that time was MUCH worse than it is today. This is what Retool was offering us at the time: https://web.archive.org/web/20230315060042/https://retool.co... -- no distinction between developers and end users! No access controls until the $50/user/month level! That was totally out of the question. The current pricing looks a bit more reasonable, but it's too late; we already committed to the competitor offering an open source solution.
I help companies with digital transformation, what it usually entails is deploying solutions to small teams and then growing them as we get buy in from the business. The initial users are high frequency users of the tools, and later users might be infrequent users.
The problem I found with Retool was that as I scaled to the infrequent users the cost per user remained static, so I would be punished for my tool becoming more popular.
From a Low Code product perspective, we were still able to build a beautiful and functional product. Our product unit/engineer ratio is much higher than our competition (see, for example, Retool), which allows us to provide the best value for our users. Regarding the transition, I don't see any indication from the note you posted that users will have to rebuild all their apps. Rather, the founder is saying he will provide more information and possible steps. Who knows – maybe it would be integrated into Figma? And Figma would gain great runtime and IDE capacities?
I want to create customer accounts, apply settings (e.g. I delimit the data their account can access, basically adding WHERE clauses on a per-account basis), and they can access white-label read-only dashboards with their own user/pass.
Retool seemed 100% insistent on being an internal-only tool with a high cost per user.
We were emailing back in 2021 about one of the many products you and your team have built for developers. Exciting conversation, for sure!
If anyone is interested in reading about my experience with ReTool's approach to developer tools, I have a link: https://marak.com/blog/2021-04-25-monetizing-open-source-is-...
FWIW I run growth for a low code platform company and we are one of the retool alternatives. One of the things I am trying to get right is getting the value proposition right for different scenarios like say building a customer portal (unlimited external users) to admin tools (few internal users). So far we have been able to do good on this front by helping customers with usage based pricing or even developer based pricing. But yet curious to hear your use case and see if there is something I am missing.
It actually sounds like an interesting service in my opinion, but it is another SaaS that is giving me an API for a form handler that I could otherwise host myself.
Personally I wouldn't see the use case of using your own DB as helpful, if you already have your own database the odds that you aren't hosting APIs as well seems low.
I do think there is more work for us to do — I do think especially as we get more enterprise customers (currently 4 of the Fortune 10 are customers; we're aiming to get to all 10 soon!), we'll be able to make it cheaper and cheaper for indie developers (maybe one day even totally free for up to, say, 100 users, or perhaps to introduce a plan that you can build public apps with unlimited users for free).
We have considered open-coring Retool. I think there are many pros to that (as you note). But my main fear is that it would be difficult to build a business around it, since we'd be stuck selling either hosting or support (neither of which is particularly high margin; cf. Elastic). Or we'd be forced to limit the open-source version to not have important features (e.g. SSO)... and it feels like we wouldn't be true to the open-source philosophy if so.
Thank you for considering Retool!
Would be more than happy to talk through your use case; feel free to reach out at antony[at]retool[dot]com.
[0] https://retool.com/pricing [1] https://retool.com/products/portals
Was curious to apply your use case and see if our pricing model maximises ROI.
Disclaimer: I am co-founder at a retool alternative platform for building internal tools and enterprise apps.
If you read the comment again, you'll see I'm replying to OP's scenario of setting his own server and frontend.
I'm questioning the "probably using React" part of the frontend because... it's an overly complex solution to an already elegantly solved problem?
Pure-HTML forms work exactly like React forms; React does the lifting but it doesn’t change anything to the fact that the data eventually needs to be sent to a server to be stored in the database.
This should probably read "React forms work exactly like pur-HTML forms" seeing as HTML came first and react ultimately spits out either an HTML form or a form request.
The original point still remains though, reaching for react just for forms is really heavy handed. It works fine if everything on the site is react already, though that's an assumption that I wouldn't make and that I hope will die soon enough if devs finally start moving away from massive react apps.
If you don't think that's a fair reaction, would love to hear your perspective and buy you a coffee next time I'm in NYC. I'll send you an email now. :)
Keep up the excellent work, creating value with your ReTool company. I am confident you will find continued success with your sustainable approach.
From the dev experience perspective, these 150kb of Javascript and the complexity you'll build upon it will come with bugs, security holes, updates, maintenance. Personally I wouldn't want this for me unnecessarily.
I mean it’s a form; we already have all the HTML elements already; why do you need React for? This is why nowadays we end up with Electron apps that take 6GB of RAM to display a chat.
What about complex validation rules? Do you really think it's user friendly to require them to send the whole form just to tell them "sorry no" 10 times over until they get it right?
What about multi-value selects, potentially with rules? E.g. form field like "choose up to 5 locations in the radius of 10km".
What about form fields like "pick a point on a map"?
Etc. Don't act like every form is 5 simple text inputs.
You'll have to do in the server, if you're sane.
I bet Retool Forms does in the server.
You're worried the page will refresh with an empty form, if it fails. It's simple, just collect the data and return the form pre-filled using the value attribute, along with the error message.
If you don't want to refresh the page, you could even use something like htmx, which is a LOT simpler than React, but really not necessary for simple form submission.
Well to be honest 99% of forms are 5 simple text inputs with a select. What was the last time you had to implement a "choose up to 5 locations in the radius of 10km", really?
> What about form fields like "pick a point on a map"?
Same thing: of course there are rich forms for which you need JS, but they are the exception, not the rule.
Doing form validation in event handlers for DOM events works very well, and a simple script tag or custom element is all that's needed to build a multi-value select.
I wpould use my server-side form and database library, Bozen[1] to do this.
>
In the late 90s I built some quite big things in Access and promptly regretted it. I guess Access got used for those projects because the organisation already 'owned' it as part of the Office bundle whereas Visual Studio 6 was seen as 'expensive' (I think it was about £500 per developer or something).
But these days that problem would not occur. The days of development tools needing comparatively expensive licences are over.
> The days of development tools needing comparatively expensive licences are over.
That's exactly the motivation I saw for Access being used in the past. I agree, those days are over and that justification for using Access is moot.
Let me tell you some news, they just launched an integration of this new HTML <form> thing with javascript, so you can have JS listening to inputs and displaying information anywhere on the page. Cool, isn't it?
Ah, but the sad part, again, is you don't get to download an unnecessary library for that. It comes baked and activated into all browsers by default. It doesn't make your resume shine, either...
I don't care about resumes, I own my consultancy. I care about quickly solving business problems for my clients, not making new problems in the process, and reusing the solutions. I am not paid hourly, I don't make money from fixing spaghetti code broken by adding a stateful form control elsewhere.
I really don't want to go back to the jQuery days. You do you, but don't say it's easier - it really isn't.
BTW you can just use Preact if you're worried about the bundle size. I do that, it's perfect and just a little performance impact, usually not visible in small apps.
I reach for a state machine whenever possible to manage the complex flow of the multi-page or multi-step form, even if react is still used for custom inputs.
But it's not that necessary in my case, my forms are usually not complex statecharts, just a lot of individual and largely decoupled complex form controls - multiselects with rules, map pins, tag inputs with autosuggest, data grids etc.
But you want to provide better UX to the user.
Htmx is not simpler than React. I can't deploy that without a server that knows everything about the frontend. React allows me to decouple. Templates are hell. I lived in it for many years, never again.
BTW: jQuery is 85.1 kB minified and 29.7 kB gzipped. Preact (same API/dev experience as React, minimal performance impact) is 11.4 kB minified and 4.5 kB gzipped. Who has the smaller JS bundle now?
https://htmx.org/essays/splitting-your-apis/
I just don't get what you're chasing after. All this seems more complex (to develop, to maintain, to operate, to manage) than what I'm doing with (P)React (Native) and APIs.
And where are the thousands of pre-made components like React has?
- no reduction in app ux
- code base reduced by 67% (21,500 LOC to 7200 LOC)
- total JS dependencies reduced by by 96% (255 to 9)
- web build time reduced by 88% (40 seconds to 5)
- Time-to-interactive reduced by 50-60%
- htmx allowed them to display much larger data sets
- memory usage reduced by 46% (75MB to 45MB)
the essays above also discuss why to split your apis (disentangle web app churn from your general purpose data API) and how to avoid duplicating logic (the mvc essay)
i take pains to reiterate in the essays and book that htmx isn't right for every application, but it is a good architectural choice for some, and many more than most web developers who are used to reactive-style programming would think
there are not thousands of pre-made components for htmx because there are no components for htmx: there are rather components for HTML. those components should integrate with htmx in the HTML-standard manner: events & form participation
Time-to-interactive has never been a problem for me. My code-splitted bundles are so small they're pre-loaded quicker than the server-rendered HTML code. And builds? My apps - even big ones - build in single digit seconds (using swc or esbuild), and small ones like forms we're talking about in less than a second. The only thing that takes long time is TypeScript typechecking, I do that in a separate task in my CI while the build is long done and tests are in progress at the same time.
I'm not saying all this is super easy - obviously it's the product of using React literally since it's first public beta release. But it's also not impossible to do, and setting up a htmx and a server to run it on is IMHO similar complexity.
The biggest mistake people do - they use stuff like create-react-app with a bunch of absolutely unnecessary cruft. And then they follow some tutorials made by a dude who knows React for 2 months. Just read the React docs (except for the create-react-app part) and you're good to go.
BTW: jQuery is 85.1 kB minified and 29.7 kB gzipped. Preact (same API/dev experience as React, minimal performance impact) is 11.4 kB minified and 4.5 kB gzipped.
there's always gonna be a hypothetical objection if you want there to be
maybe read the essays and/or book, maybe try it out on a simple project
or don't, doesn't really matter much