Console #111 -- Interview With Marc of Thin Backend

Featuring Markwhen, uBlacklist, and Thin Backend.

Jackson Kelley

Jun 26, 2022

🤝 Sponsor - PostHog

PostHog: Open-source product analytics you can self-host

With PostHog's open-source analytics platform, customer data never has to leave your infrastructure.
Featuring product analytics, session recording, feature flags, heatmaps, experimentation, and more - all available for free!
The best part is everything is seamlessly integrated, so you can spend less time configuring different tools and more time getting valuable insight into user behavior.

Get Started

🏗️ Projects

Markwhen

Markwhen is a text-to-timeline tool. You write markdown-ish text and it gets converted into a nice-looking cascading timeline. Supports simple American/European date styles, ISO8601, images, links, locations, and more.

language: Vue, stars: 1141, issues: 27, last commit: June 19, 2022
repo: github.com/kochrt/markwhen
site: markwhen.com/docs

uBlacklist

uBlacklist blocks specific sites from appearing in Google search results

language: TypeScript, stars: 3258, issues: 11, last commit: June 21, 2022
repo: github.com/iorate/ublacklist
site: iorate.github.io/ublacklist

Thin Backend

Thin Backend is a Blazing Fast, Universal Web App Backend for Making Realtime Single Page Apps

language: JavaScript stars: 646, issues: 9, last commit: June 21, 2022
repo: github.com/digitallyinduced/thin-backend
site: thin.dev

🎤 Interview with Marc of Thin Backend

Hey Marc! Thanks for joining us again! How have you been?

Hey Jackson! Thanks for having me. It’s going great!

Last time you were on Console we spoke about IHP. How has that project progressed since we last spoke in 2021?

IHP has grown quite a bit. I think when we talked last time IHP had around 1600 GitHub stars. It’s now at 3300 and steadily growing. Actually, IHP is now the biggest Haskell web framework measured by GitHub stars.
There’s also more and more people doing interesting web projects with IHP.
We’re still part of the version 0-based versioning club. We initially wanted to release v1 already last year, but so far there was always something keeping us from tagging it :) We’re now at v0.19 already.

What sort of things were stopping you from tagging v1?

One big blocker was Apple M1 support. This was recently fixed via v0.19. We also wanted to re-design the local development migration workflow, as this was causing troubles oftentimes. Then there's refactorings we want to do before V1 that might break existing apps (e.g. functions like `redirectTo` stop the execution of the current action by throwing an exception which is caught by the framework. This doesn't play nice with Haskell's type signatures, so we want to remove that behavior). We also want to upgrade to the latest major version of the Haskell compiler. This is currently not possible without major changes as some language features have changed.

What have you been up to since then?

We have done quite a lot of new IHP versions, added tons of new features like Payments with Stripe, Dark Mode, Breadcrumbs, a new Design for IHP, and much more. With v0.14 we’ve added a new commercial version of IHP, to support IHP’s long term development.
We’ve also recently started a new variant of IHP called Thin Backend. Basically making the Design ideas behind IHP easy to use for people using React.js. To achieve this, we’ve ported the IHP query builder and CRUD functions to JavaScript. So that you could use the IHP query builder directly from within react.js, to run database queries, and write to your database right from within a single page application instead of IHP actions.

Why was Thin started?

This was born when we thought about how to make IHP and React.js work together nicely. While IHP initially was very anti-JS, we always had cases coming up where we needed to build small, very dynamic parts of an app with JS.
It always felt like this would be an easy job to do with React. We used data attributes to pass database state to the small react components. If there was something that writes to the DB, we tried to use our form action handlers or wrote an API endpoint.
After a while I was thinking about how great it would be to be able to call something like IHP’s `createRecord` right from the React code itself.
The idea matured and at some point I created the first prototype for this. It was initially called IHP DataSync (for syncing data between frontend and backend). Playing with this new API, I figured out that IHP DataSync might be useful beyond just IHP Apps.
So I started a new variant of IHP. It was called IHP Backend. It was just designed to be used as a backend for single page apps with IHP DataSync. During the first tests with people trying it out, we quickly realized that people easily confuse what is IHP Backend and what is IHP. We started searching for a new name. We ended up with Thin.

Where did the name for Thin come from?

The idea is that with Thin you’ll have a thin backend layer in your stack (basically the backend is just syncing data between database and frontend), and a rich frontend.

Who, or what was the biggest inspiration for Thin?

Well, IHP :) I really like our database layer with query, createRecord, updateRecord and deleteRecord. Its beauty lies in its simplicity.
All functions are named the same and follow the same design choices as IHP’s database layer.

Are there any overarching goals of Thin that drive design or implementation? If so, what trade-offs have been made in Thin as a consequence of these goals?

One overarching theme is that we aim to make everything realtime by default. This allows state management of the client to be simplified a lot, because the local state and the database state are only out of sync for a very short amount of time.

Are there any competitors or projects similar to Thin? What were they lacking that made you consider building something new?

There are quite a few similar tools. Fundamentally, most of them expose a low level API, where you manually need to be dealing with HTTP calls, headers, and retrieving results in a type safe way. Basically exposing the transport layer into your application layer.
Thin operates at a higher level, offering a few basic data operations (createRecord, updateRecord, deleteRecord, useQuery). You never think about HTTP (or actually WebSockets, as Thin uses WebSockets for lower latency), headers, or fetching from the right endpoint. You’re only thinking in terms of a few TypeScript function calls.
This simple, high level design allows us to implement higher level abstractions like optimistic updates. E.g. with most GraphQL or REST APIs it’s not possible to implement optimistic updates in a generic way for the full application.

What was the most surprising thing you learned while working on Thin?

The frontend ecosystem has matured quite a bit in the last few years. Newer tools like esbuild work right out of the box and are very performant.

Is Thin intended to eventually be monetized?

It’s not monetized yet. We plan to sell licenses for an enterprise version to companies in the future.

What is the best way for a new developer to contribute to Thin?

It’s best to first get familiar with Thin’s features. A good starting point for a first pull request might be a change on some of the TypeScript libraries https://github.com/digitallyinduced/thin-backend. If you’re familiar with Haskell, you could also jump into the Server code in the IHP repo.

What motivates you to continue contributing to Thin?

I need Thin to exist so I can use it myself in the future. It’s such a huge improvement over handcoded APIs or GraphQL that I’d miss it dearly.

Are there any other projects besides Thin that you’re working on?

IHP of course :-)

Where do you see open-source heading next?

It looks like one of the open questions that might be solved in the future is the question about monetizing open source projects and aligning interests in a way that a project is developed and maintained for the long term.

How do you foresee this problem being solved?

I don’t have any direct solutions to how this could be solved. There’s a lot of smart people working on this problem, so that makes me optimistic. E.g. I’ve recently talked to Avi Press when I was in California, and they’re working on some good ideas for commercial open source projects with Scarf. (We interviewed Ari in Console, you can read about Scarf here.)

Want to join the conversation about one of the projects featured this week? Drop a comment, or see what others are saying!

Console by CodeSee.io

Discussion about this post

Ready for more?