Why so many pieces in the backend puzzle?

Ah, programming… the art of cursing life and the universe, doubting your entire life choices, feeling miserable and then suddenly… change this one line of code, seeing everything work, and feeling on…

Cover image for Why so many pieces in the backend puzzle?

Ah, programming… the art of cursing life and the universe, doubting your entire life choices, feeling miserable and then suddenly… change this one line of code, seeing everything work, and feeling on the top of the world.

Coding is hard. And is hard for a variety of reasons. Some of them I really don't have a solution for. But one way in which programming is hard, is that it is like a Jenga tower:

stacking blocks may be hard…
stacking blocks may be hard…

Programmers are flooded with frameworks, databases, connecting tissue, specialized languages, and etc. There are many techniques to keep this tower up. But if you really need to build a big tower, and not just have fun with the blocks, better abstractions go a long way.

… or it may be easy, if the abstraction is at the right place!
… or it may be easy, if the abstraction is at the right place!

Abstractions are how we can strap things together, and they are not better or worse on absolute terms: it heavily depends on what you are doing. On the backend side of life, usual abstractions are databases, message queues, connections, and APIs. If you are writing a very specialized backend, your are likely to need those building blocks and should master them.

On the frontend, usual abstractions are the various web frameworks. Much like in the backend, if you are doing something very specialized you will want to go for the individual building blocks themselves, but likely you are better off with your frameworks. They abstract away all the complexity of Javascript, events, actions, and allows you to reason at a higher level.

But let's say you are a web developer, and want to write an application that stores some extra state. You are usually covered when it comes to the web frontend abstraction, but what about the data layer?

The internet is full of tutorials and articles (like this one and this one) to help you with that, but broadly speaking you will need:

  • A web frontend framework, like Next.js, Gatsby, or Remix
  • An API layer like REST and GraphQL, to allow your data to be accessed.
  • An ORM, to deal with the databases down below
  • A serverless functions environment so you can execute your business logic, including the ORM.

It's a lot to learn, a lot to know, and a lot of blocks to stack. Connecting all of those things together to achieve a great result is a great feeling. But there has to be an easier way. What if, from the web framework down, our abstractions were different? What if your programming language was all you see, and you could just treat your backend as a natural extension to your frontend? Like two lego blocks seamlessly connecting?

For that to work, we need to move the abstractions away from databases, into something that fits the abstractions of programming better.

SQL reigns supreme in the database world. Years of NoSQL couldn't displace it. The same way years of complaining about how true + true == 2 didn't dethrone Javascript from being the most used programming language in the world. But yet, when it is time to connect them together, this is usually done with a jenga tower of stacked building blocks.

We have seen this before: 20 years ago, we had all of those fantastic gadgets that colored our lives: video cameras, CD players, calculators, phones. Many great things were done by connecting them together, until a better abstraction came along: the smartphone.

What if we instead of writing our projects by gluing together execution engines, databases, and ORMs, we could just write Javascript/Typescript, deploy it as a function and transparently access data, as if there wasn't a database, and everything was just coding?

That's the problem ChiselStrike aims to solve.

ChiselStrike allows you to execute your backend logic as functions in Typescript. It allows you to automatically wrap that into a REST API, and allows you to access your objects seamlessly, as if a database wasn't even there: just persist and retrieve objects as if you had a global shared memory system. And it works well because we're not asking you to strap together a phone to a GPS to a CD player. We're providing you with a smartphone.

That means that you can have you working serverless API so easily, we can fit it into a tweet:

In fact, while our serverless platform is in wait list mode, you can install ChiselStrike locally with a single command:

npx create-chiselstrike-app my-app

Then run the local development server:

npm run dev

which comes with an example endpoint that you can access by POSTing a JSON body and seeing it return:

$ curl -d ‘{ “hello”: “world” }' localhost:8080/dev/hello
{“hello”:”world”}

And that's it! From there, you can add your models in pure Typescript, without worrying at all about how they map to the way the data is stored, and add code to deal with them without ever worrying about the data layer. As we move the abstraction layer up, there is no need for an ORM at all, nor the need to understand how to operate a database, handle functions or operate a REST API.

So what's next? Check out ChiselStrike's documentation to learn more about how to get your app going in 5 minutes or less! If this idea appeals to you, we'd love to hear from you, so you can email us at info@chiselstrike.com, our join our discord community

Want to deploy this to the edge and never worry about ops again? Join our early access list!

scarf