How can all the forms work with no backend code?

Sapling's dynamic data backend figures out what to do based on the type of request it receives to the built-in /data route. It acts as a lightweight wrapper for abstract CRUD operations;

• GET /data/posts returns all records in the collection posts
• GET /data/posts/type/text returns records in the collection posts, where the value of type is "text"
• POST /data/posts creates a new record in the collection posts
• POST /data/posts/_id/1 modifies any records in the collection posts, where the value of _id is 1
• DELETE /data/posts deletes all records in the collection posts
• DELETE /data/posts/_id/1 deletes any records in the collection posts, where the value of _id is 1

As such, the second URL segment is the collection, and if the third and fourth segments are provided, they will act as key and value for a where clause, respectively. The method of the HTTP request determines what is done with the matching records. In cases of POST requests, any and all POST values received are saved into a new record or any matching records.

Learn more about the data API

Oh wow. Putting this on production would be insanity!

Absolutely, and Sapling's default configuration is indeed not meant for production use, but rather, optimised for rapid prototyping.

Sapling has robust support for built-in data and request validation, as well as access control for each method-route combination. By default, these are optional. However, in Sapling's production mode, both of these must be defined, and nothing is ever implicitly saved into the database.

Learn more about production mode

Learn more about data models

This must be some low-code framework for beginners, with no options for advanced development.

Just because you don't need to write code to do basic CRUD operations with Sapling, doesn't mean you can't write code when you actually need to.

When you need to write advanced functionality, Sapling will step aside, and let you handle requests just like you would with any other server framework. Organise and write your code however you wish. All of Sapling's internals methods are available to you - though you don't need to use them, if you don't want to.

Learn more about hooks

This doesn't sound very robust – this would never work for my team of 250 devs building custom enterprise banking solutions.

And that's fine. No tool is right for every job.

Where Sapling shines are situations where speed of development is critical, or available manpower is limited: MVPs, hackathons, prototypes, proofs of concept, mockups, side hustles, personal projects, one-off campaigns, and so on.

Get off the ground quickly by never having to write another login form, or worrying about backends for all the basic "put thing in database" stuff – spend 100% of your time on the things that actually butter your bread. And if you ever feel your project has "graduated" out of Sapling, all your custom-developed business logic remains easily portable to any other JS framework.

Learn more about code portability

I don't like MongoDB or Nunjucks or Vue.

You don't have to! Sapling uses these three by default, but that's all they are – defaults. Each functionality (database, templating, frontend framework) is its own separate package, which you can replace or uninstall at any time.

Sapling is fairly hands-off with the frontend stack, so you are free to use whatever frontend build pipelines you prefer.

Database and templating engines connect to Sapling via an abstraction layer called a driver. Chances are, there's already a driver for your favourite database or templating engine – and if not, you can easily write your own.

Learn more about drivers