Show HN: thin.dev, back end for making realtime, typesafe React Apps | Hacker News Reader

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

thin.dev

147 points_query33 comments

Hey there, Founder of digitally induced here. Happy to share what've been working on with Thin Backend over the last months.

Thin is a version of the IHP Framework (https://ihp.digitallyinduced.com/), designed to be used by frontend developers. Instead of building APIs with low-level `fetch` calls, we provide high-level APIs like `createRecord('tasks', { title: 'Hello World' }`, `updateRecord(..)` and `deleteRecord(..)` to update your database.

To simplify state management (which is typically hard and lot'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's rendered directly from the server state.

The Schema Designer and the migration tools make it really easy to get going with a project.

Internally Thin is built with Haskell and powered by IHP DataSync (https://ihp.digitallyinduced.com/Guide/realtime-spas.html).

Happy to hear everyone's feedback! :)

How does pricing compare to Firebase which lets frontend devs think in terms of modifying their JSON data without thinking about the REST equivalent?

You can find our pricing here https://thin.dev/pricing If you're not using the free plan, you're paying 10$ + (2$ * GB of data traffic). This is likely a bit cheaper than Firebase (but Firebase has many more pricing variables, so it's non trivial to compare) :)

I think you have to specify the use case.

I have an app that I built which has a couple hundred users. I pay just a couple dollars per month to use firebase firestore, authentication, cloud functions, storage, analytics, and crashlytics.

I’m sure thin.dev is very cool and I’m excited to check it out but I expect in the distribution of possible use cases, thin pricing is cheaper than firestore or real-time database in a vanishingly small number of them.

Thanks for your honest feedback.

Our pricing still might change a bit in the future. I'm with you that with a couple hundred users it shouldn't cost more than 5-10$ to host this app.

The Thin Pro plan already includes 5GB for free, so we might increase these 5GB to a bit more.

I'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 (https://riffle.systems/essays/prelude/).

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.

Some of the Data-Centric patterns like storing component state in the server-DB would be really cool to play with in 'Thin'. I think being able to access your app from different devices/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.

Thanks for giving it a try so early! :)

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?

It also seems like Blitz.js[0] has a similar approach to yours (batteries-included, integrated FE & BE). Is there anything in particular that separates out thin.dev from Blitz?

Edit: Learning more about IHP, I haven’t seen such a promising Haskell web framework since Happstack, very eager to try that out!

[0] https://blitzjs.com

Thanks for the input!

Thin can quickly be integrated in an existing stack as long as you're using postgres.

The value proposition with an existing backend can be: Improved UX thanks to very low latency. E.g. Thin automatically does optimistic updates when you're inserting or updating a database record. This results in a really nice user experience compared to what you'd get with a normal REST Backend.

I've no experience with blitz.js. From a first look it seems it goes in the same direction. Blitz.js is not leaning on realtime as much as we're doing. Additionally it seems that it doesn't provide optimistic updates out of the box.

On IHP: Yes! :) IHP has a promising future ahead! All the Thin Feature are btw also supported in IHP. The Thin JS library is just a small wrapper around the IHP DataSync SDK :)

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 :)

Thanks for your input! In the end every Thin app is just a postgres database. So if you want to move to a different backend, you could replace Thin with a handcoded backend connected to that postgres db.

I might be wrong here but it just dissecting this two principles I can see few issues:

    All data is realtime and reflects the latest database state: Local state management is fundamentally hard as it's 
    dealing with distributed system problems. Best to avoid it alltogether.

Local state is hard because of state management available. MobX largely addresses the issue and it's not really related to distributed systems.

    All database operations go through a unified standard interface, IHP DataSync in our case.

Yikes. Absolutely do not want to replace an established, transparent, "boring" process with some Rube Goldberg machine that I'm held hostage to.

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't want to lock it down and be held hostage by a Rube Goldberg machine. For full stack developers, it really isn't too much of an effort to create backend API endpoints separately and hooking it up to your frontend either.

I invite you and others to share their points but just from the get go, perhaps I'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/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't quite understand what was happening underneath the hood so might be good to share more technological risks/debts that is implicit.

Do you think making it more open source would solve the issue?

Thin is mostly based on IHP DataSync. You can the source code here https://github.com/digitallyinduced/ihp/blob/master/IHP/Data... Thin itself is just a "thin" wrapper around IHP and IHP DataSync.

Additionally most of the system is just relying on postgres for doing it's work. So if you ever want to swap out Thin with another API, you could build a normal REST API, connect it to the database and switch it out.

> Do you think making it more open source would solve the issue?

No is not what I'm arguing for here but you highlighted my concerns here, I see two points of failures/blackboxes that I am now betting the house on vs the "problem" mentioned (having to create API/Redux layer).

As I said, this might be an issue for indie/small startups looking to create an MVP but more often than not, you would want to optimize for hireability and removing the implicit. It would be tougher to find an Haskell dev compared to "boring" full stack devs, and this is just the start of the problems.

Looks cool! How does this compare to something like Firebase/Supabase?

It solves the same problem as Firebase/Supabase.

In some ways Thin is designed a bit more opinionated. This allows us to e.g. support optimistic updates out of the box.

Supabase generally also exposes very low level APIs (basically just a REST Api via PostgREST), where we offer very high level APIs that sent over a WebSocket.

Supabase recently announced something in the "realtime" space https://supabase.com/blog/2022/04/01/supabase-realtime-with-...

Like to keep up-to-date on this stuff because we ended up building the realtime/multiplayer part of Kitemaker [0] from scratch on top of GraphQL so I'm always curious what's coming along to make things easier.

0: https://kitemaker.co

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

Love the website color scheme. Here's a tiny feedback.

On MacOS Safari using a large monitor, the line background in the back doesn't fit the entire width:

https://i.imgur.com/72xTlLp.png

Will look good if it fit the entire width.

Thanks for the feedback! :) We spent so many iterations on the color scheme and design, so I'm really glad to hear this.

Created an issue for that interally. We'll fix this soon!

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

Back now. Sorry, deploy issue :)

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?

Yes, Svelte is already supported https://thin.dev/docs/svelte

We also have an integration for ReScript https://thin.dev/docs/rescript

More to follow in the future

Cool, that makes it more interesting for me. (By the way, the video on that page (https://thin.dev/docs/svelte) still uses React, though the text does descripbe a setup with Svelte.)

Good point, just removed the video. Will be deployed soon.

From looking at it, the Svelte integration is actually the framework-agnostic integration. It relies on Svelte stores following the observable interface, which should be relatively easy to integrate with anything else.

Yep, exactly :)

There's a typo on the pricing page:

  Free
  
  For personal, "non-commerical" use

Thanks. Fix is deploying :)

it'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.

I'm not so much into web3, so maybe you can help me a little bit and point out where the web3 buzzwords are?

Reply on news.ycombinator.com