What have we learned from a year of ChiselStrike?

For the past year, we have been building ChiselStrike in the open. During this time, we have built a great Discord community with over 200 members, and got a decent amount of Open Source activity.

We're Open Source veterans, so for us building this– or whatever we build– as an Open Source project was always a no brainer. But as a company, our goal was to use this to power our Backend-as-a-Service offering, to where people could deploy ChiselStrike code.

From the start, we had in mind that we would build a SQLite-on-the-edge solution to power the ChiselStrike platform. However, as we got closer to fulfilling that goal, and combined with other feedback we received from the community, we realized that this, which we named Turso, should become our main product.

Today, we are discontinuing the hosted BaaS offering (but not the ChiselStrike Open Source project, more on that below), to focus on Turso.

Discontinuing a project is never an easy decision. But hey, it's better than firing 20% of your staff, quoting some famous personality, and spewing some empty “I take full accountability” BS email.

In this article, I'd like to say a few words about what learnings drove us to do it, and what's the future of the ChiselStrike Open Source project.

#What people loved about ChiselStrike

We have received so much good feedback about the things we built. For brevity, I will highlight the main ones:

#It's all TypeScript

Unlike standard ORMs, ChiselStrike is TypeScript-first, not database-first. Models are defined in TypeScript, and are not auto-generated from an intermediate representation. With the addition of the client API, types are propagated all over, so everything is typesafe. There are no migrations.

#The developer experience is great

Built on SQLite, it's easy to get started locally and there is no need to connect it to external databases, complex setups, and the like.

Also, once you have a TypeScript class mode, .crud() is all you need to spawn a full CRUD REST API. You're ready to go in seconds.

#What people didn't like about ChiselStrike

However, we have received unequivocal feedback about some things that weren't quite right.

#There is no escape hatch

As much as we received praise for our abstractions, developers overwhelmingly told us that they would like to have the ability to go down the SQL layer when needed. This is one of the main driving forces behind our investment in libSQL as an Open Source project, and Turso as a product built on that foundation.

#It is confusing to understand where my code is running

Serverless is becoming second nature for web developers. Our original intent was that developers would deploy their application to their favorite serverless platform, and the “backend code”, that lives together with the data, to the ChiselStrike platform.

But that immediately raised questions about which code goes where? Can I deploy ChiselStrike itself as part of my Next.js project? The two most common mistakes people made in the platform were to deploy their entire web application, or try to add ChiselStrike code to be deployed using serverless functions on Vercel, Netlify, or Cloudflare.

#The future of our ChiselStrike Open Source backend project

We are still maintaining the Open Source project, but only for people who want to self-host it. Fly.io and Digital Ocean are great platforms for that, or any infrastructure where you have access to a server.

Because of the way we initially tied code and data in our architecture, ChiselStrike embeds a TypeScript runtime (Deno).

The decision not to host code anymore, and focus exclusively on the database layer, also offers some very enticing possibilities.

Firstly, we can simplify the database product by removing Deno from the build and relying on an external runtime. Colocating the runtime in the same process as the database, while great for performance, binds them too close for the flexibility we need to move forward. Instead, developers can rely on other edge-hosted products like Cloudflare to run their backend code.

Secondly, we can introduce a new layer of security to the database that allows frontend code to query the database directly to get the best possible edge performance, without compromising the integrity of application data.

#Final words to all our loyal developers

We still hope that you will continue to benefit from ChiselStrike Open Source backend to make creating your backends a breeze. And if you haven't joined our Discord yet, we're still there!

And if you loved what we've done so far, we're certain you will love Turso as well. Turso is now in private beta, and you're welcome to join our waitlist.