Show HN: thin.dev, back end for making realtime, typesafe React Apps

Hey there, Founder of digitally induced here. Happy to share what&#x27;ve been working on with Thin Backend over the last months.<p>Thin is a version of the IHP Framework (<a href="https:&#x2F;&#x2F;ihp.digitallyinduced.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ihp.digitallyinduced.com&#x2F;</a>), designed to be used by frontend developers. Instead of building APIs with low-level `fetch` calls, we provide high-level APIs like `createRecord(&#x27;tasks&#x27;, { title: &#x27;Hello World&#x27; }`, `updateRecord(..)` and `deleteRecord(..)` to update your database.<p>To simplify state management (which is typically hard and lot&#x27;s of boilerplate), we provide realtime APIs so that all app state is always in sync with the actual database. Previously your react app might have been rendered from the redux state, now it&#x27;s rendered directly from the server state.<p>The Schema Designer and the migration tools make it really easy to get going with a project.<p>Internally Thin is built with Haskell and powered by IHP DataSync (<a href="https:&#x2F;&#x2F;ihp.digitallyinduced.com&#x2F;Guide&#x2F;realtime-spas.html" rel="nofollow">https:&#x2F;&#x2F;ihp.digitallyinduced.com&#x2F;Guide&#x2F;realtime-spas.html</a>).<p>Happy to hear everyone&#x27;s feedback! :)

I&#x27;ve been playing with the Thin API and prototyping some small applications (music streaming and comms type stuff). It seems like one of the most production ready ways of designing [Data-Centric Apps (<a href="https:&#x2F;&#x2F;riffle.systems&#x2F;essays&#x2F;prelude&#x2F;" rel="nofollow">https:&#x2F;&#x2F;riffle.systems&#x2F;essays&#x2F;prelude&#x2F;</a>).<p>From a developer point of view with Thin it feels like you can move directly from a schema to a user interface without having to spend a single line of code on network configuration or intermediate application layer logic.<p>Some of the Data-Centric patterns like storing component state in the server-DB would be really cool to play with in &#x27;Thin&#x27;. I think being able to access your app from different devices&#x2F;sessions and having the state preserved could be a fun feature and there seems like a lot of potential for multi-user collaborative type apps to be written using this framework.

Saw the demo - and love the simplicity of backend calls. It makes a lot of sense for full-stack devs to increase development velocity, but how do you see this fit in with teams that already have a backend stack? What’s the value prop for backend devs to adopt this?<p>It also seems like Blitz.js[0] has a similar approach to yours (batteries-included, integrated FE &amp; BE). Is there anything in particular that separates out thin.dev from Blitz?<p>Edit: Learning more about IHP, I haven’t seen such a promising Haskell web framework since Happstack, very eager to try that out!<p>[0] <a href="https:&#x2F;&#x2F;blitzjs.com" rel="nofollow">https:&#x2F;&#x2F;blitzjs.com</a>

Seems great for simple applications. But i will always prefer choosing every tool myself. I want to be able to choose which DB i use, which backend language, which frontend framework. I dont like locking myself in. Nice website though :)

I might be wrong here but it just dissecting this two principles I can see few issues:<p><pre><code> All data is realtime and reflects the latest database state: Local state management is fundamentally hard as it&#x27;s dealing with distributed system problems. Best to avoid it alltogether. </code></pre> Local state is hard because of state management available. MobX largely addresses the issue and it&#x27;s not really related to distributed systems.<p><pre><code> All database operations go through a unified standard interface, IHP DataSync in our case. </code></pre> Yikes. Absolutely do not want to replace an established, transparent, &quot;boring&quot; process with some Rube Goldberg machine that I&#x27;m held hostage to.<p>This looks okay for building MVP, as most of these tools seem to be aimed at. However, companies with existing product or looking to make their APIs as a core product wouldn&#x27;t want to lock it down and be held hostage by a Rube Goldberg machine. For full stack developers, it really isn&#x27;t too much of an effort to create backend API endpoints separately and hooking it up to your frontend either.<p>I invite you and others to share their points but just from the get go, perhaps I&#x27;m older now and have become wary of the next shiny solution favoring boring tech, the problem you are solving appears to be a non-issue for most live world existing API&#x2F;Frontend products, as well as full stack developers (for ex. scaffold crud generators are a thing). The cost of moving faster by taking on hidden technical debt especially in a core, essential part (the api) of the product by a 3rd party looking to remove that have typically ben risky. Also, I couldn&#x27;t quite understand what was happening underneath the hood so might be good to share more technological risks&#x2F;debts that is implicit.

Looks cool! How does this compare to something like Firebase&#x2F;Supabase?

Since this highlights the goal of making database state the app state, how does this compare to going the RxDB&#x2F;PouchDB syncing to Couchbase route?

Love the website color scheme. Here&#x27;s a tiny feedback.<p>On MacOS Safari using a large monitor, the line background in the back doesn&#x27;t fit the entire width:<p><a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;72xTlLp.png" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;72xTlLp.png</a><p>Will look good if it fit the entire width.

All I see is “502 Bad Gateway”. Too much traffic or a bad deploy?

Are there any plans to decouple this from React, either by making it framework-agnostic, or by adding support for other frameworks like e.g. Svelte and Vue?

There&#x27;s a typo on the pricing page:<p><pre><code> Free For personal, &quot;non-commerical&quot; use</code></pre>

it&#x27;s so funny to read day after day, month after month, people working on the same problem that other people have already solved. tech is dead.

Seems like hot web3 buzzwords without much substance.