HNHacker News
TopNewBestAskShowJobs

_query

1,262 karma · joined March 7, 2014

Founder, digitally induced GmbH

https://www.digitallyinduced.com/

marc a t digitallyinduced com

submissionscomments
_query··on Learn Haskell by building a blog generator – a project-oriented Haskell book
Mysql support is not implemented at the moment. If there's someone paying for the development we could have it. You're of course also free to contribute it yourself to the open source version, then it wouldn't need to be part of the commercial version.

Some more background on why IHP has a paid variant can be found here: https://ihp.digitallyinduced.com/blog/6392ad84-e96a-46ce-9ab...

_query··on Learn Haskell by building a blog generator – a project-oriented Haskell book
If you want to do web development with Haskell beyond building a blog generator, a good starting point is IHP (https://ihp.digitallyinduced.com/ https://github.com/digitallyinduced/ihp). IHP is Haskell's version of Laravel/Rails/Django. It's really a superpower to have Haskell's type system combined with the rapid development approach of Rails :) (Disclaimer: I'm founder of the company that makes IHP)
_query··on GraphJin – GraphQL to SQL Compiler
We have a couple users recently that are switching from different GraphQL services, so I expect this to be relevant for people checking out GraphJin :)

Thin was on the Frontpage of HN around a month ago: https://news.ycombinator.com/item?id=31164799

_query··on GraphJin – GraphQL to SQL Compiler
This is basically the idea behind [Thin Backend](https://thin.dev/). Instead of exposing raw SQL strings we have a few high level functions to compose queries in a nice way and to do all kind of CRUD operations. These functions map 1:1 to SQL.

We use a WebSocket connection to keep all queries fast. Auth is solved with row level security.

It's even in the name: The backend layer is just a "thin" layer over the database. Most of the business logic is then implemented in a "rich" client/frontend.

_query··on GraphJin – GraphQL to SQL Compiler
If you're looking for something like GraphJin, PostGraphile or Hasura but with less boilerplate and complexity, more end-to-end typesafe approach and optimistic updates, check out Thin Backend https://thin.dev/ (https://github.com/digitallyinduced/thin-backend)

Thin Backend takes a bit more of a higher level approach to database operations than services like GraphJin, but solves fundamentally the same problem. Doing things in a more structured way also allows us to do things like optimistic updates by default that require manual work with GraphQL tools.

To see some code examples, here's a small example project done with thin-backend: https://github.com/digitallyinduced/thin-backend-todo-app It's running on Vercel here: https://thin-backend-todo-app.vercel.app/

If you're interested in how building a small demo app with Thin looks like, check this video https://youtu.be/-jj19fpkd2c

_query··on Ask HN: What tech stack do you use for real time apps?
Check out Thin Backend https://thin.dev/
_query··on Show HN: Open-source Firebase Alternative? It's here
Have you checked out thin.dev? We provide optimistc updates, local cache and realtime is the default for everything (offline persistence has not been the focus as we're not targeting mobile for now)
_query··on Show HN: Open-source Firebase Alternative? It's here
ihp-backend was the "old" name before it was called thin backend. You can find the source code here https://github.com/digitallyinduced/thin-backend and here https://github.com/digitallyinduced/ihp/tree/master/lib/IHP/... (Thin is based on IHP)
_query··on Show HN: Open-source Firebase Alternative? It's here
Yeah, initially we didn't have this. During beta our main servers were in europe, and while I was in SF I saw what a difference this made to the overall UX of our kind of realtime apps. Everything took like 200ms more :) With the optimistic updates it's now fast everywhere on the world.
_query··on Show HN: Open-source Firebase Alternative? It's here
If you're looking for something like Appwrite or Supabase but with a more end-to-end typesafety approach + optimistic updates, check out Thin Backend https://thin.dev/ (https://github.com/digitallyinduced/thin-backend) It takes a bit more of a higher level approach to database operations than appwrite, supabase or firebase, which allows us to do things like optimistic updates that are hard to do in other tools.

To see some code examples, here's a small example project done with thin-backend: https://github.com/digitallyinduced/thin-backend-todo-app/bl... It's running on Vercel here: https://thin-backend-todo-app.vercel.app/

_query··on Supabase (YC S20) raises $80M Series B
Update: It's now 1$ per 1M Api calls :) Thanks again for the feedback.
_query··on Supabase (YC S20) raises $80M Series B
Thanks for your feedback. It's very hard to even get to 1GB of data traffic via JSON. And the Pro plan includes 5 GB already.

We will update the pricing later today to make it more intuitive.

_query··on Supabase (YC S20) raises $80M Series B
Thanks, this is really good feedback! We will update the pricing today to use a different unit that is more intuitive.
_query··on Supabase (YC S20) raises $80M Series B
Thin also supports other JS frameworks. Svelte docs can be found here https://thin.dev/docs/svelte We're focussing the communication on react mostly to keep things simple. The core of thin is independent of react.
_query··on Supabase (YC S20) raises $80M Series B
Thin self-hosting is coming soon :) We already have this working on the technical side, we just need to add more documentation before we can push it out.
_query··on Supabase (YC S20) raises $80M Series B
Thanks for your feedback :) You have to send quite a few json messages to fill up 1GB. We think overall thin provides a lot of value and saves a lot of developer time (atleast for businesses), so we price it as that.
_query··on Supabase (YC S20) raises $80M Series B
Thin Backend (https://thin.dev/) is the newest of all of those. Compared to Hasura it offers a nicer schema designer. Compared to Supabase it offers better end-to-end typesafety and a more higher level API that offers optimistic updates. Prisma is more like an ORM, so it's designed to be used by a handwritten backend.
_query··on Supabase (YC S20) raises $80M Series B
> That's a similar approach to supabase. Why reinvent the wheel?

We've initially built the technology already for IHP DataSync (https://ihp.digitallyinduced.com/Guide/realtime-spas.html). So we used what we already had here :)

> Why websockets?

We also use the WebSockets to do write operations. This allows for lower latency than doing a HTTP call for any API call. Additionally we run all operations in parallel. With HTTP push we wouldn't be able to easily run all these operations in parallel.

_query··on Supabase (YC S20) raises $80M Series B
It's using Postgres pg_notify to subscribe to tables and using a WebSocket server to distribute the changes. The table watcher is written in Haskell and based on the IHP haskell framework. Using Haskell makes it very easy and efficient to deal with lot's of active sessions in parallel.

You can find the source code here https://github.com/digitallyinduced/ihp/blob/master/IHP/Data... if you're interested :)

_query··on Supabase (YC S20) raises $80M Series B
If you're looking for something like superbase but with a more end-to-end typesafety approach + optimistic updates, check out Thin Backend https://thin.dev/ It takes a bit more of a higher level approach to database operations than superbase, which allows us to do things like optimistic updates that are hard to do in other tools.
_query··on The realtime web: evolution of the user experience
If you're interested in building realtime web apps with Postgres and React, check out https://thin.dev/

Next to great user experience, building your application in a realtime way also allows to simplify the state management in certain parts.

A typical react app might use something like redux to store a subset of the application's database state locally. Now whenever you do any write operations to your data, you need to make an API call and also make sure the local redux state is kept in sync.

When you're embracing realtime everywhere, you avoid this, because any write operation automatically updates your realtime data, so you don't need to manually e.g. update your redux state. This allows you to skip a lot of the code that's needed for state management locally, so it saves a lot time and bugs (less code => less bugs).

_query··on Companies That Use Haskell in Production
Check out this video on how to use VSCode with IHP https://www.youtube.com/watch?v=_8_8XYO6rgY
_query··on Companies That Use Haskell in Production
Yes, check out https://twitter.com/haskellpreneur He's doing 12 startups in 12 months using Haskell. There's also https://twitter.com/tonialaribe building in public with Haskell :)
_query··on Companies That Use Haskell in Production
Haskell is famous for it's quite an academic nature. But the ecosystem has drastically improved in recent years, so that that image is really outdated by now.

E.g. with Haskell Language Server we have nice autocompletion. Recently dot-notation has been added, so you can now write `someValue.someField` as in other languages. And the documentation is improving as well.

If you're doing web development, a good starting point is IHP (https://ihp.digitallyinduced.com/ https://github.com/digitallyinduced/ihp). IHP is Haskell's version of Laravel/Rails/Django. It's really a superpower to have Haskell's type system combined with the rapid development approach of Rails :) (Disclaimer: I'm founder of the company that makes IHP)

_query··on Introduction to Haskell Typeclasses
If this post got you interested in learning more about Haskell and you want to see type classes in some real code, a great starting point for Haskell is IHP :)

IHP is a new Haskell framework with a focus on actual building applications. Imagine the productiveness of rails combined with the typesafety of Haskell.

It's now already the biggest Haskell web framework, we just hit 3200 GitHub stars. I belive Haskell can reach a lot more than it's currently doing if we get things easy to use.

If you want to build a web app with Haskell and play with type classes check it out: https://ihp.digitallyinduced.com/ GitHub: https://github.com/digitallyinduced/ihp

_query··on Show HN: thin.dev, back end for making realtime, typesafe React Apps
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.

_query··on Show HN: thin.dev, back end for making realtime, typesafe React Apps
Yep, exactly :)
_query··on Show HN: thin.dev, back end for making realtime, typesafe React Apps
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.
_query··on Show HN: thin.dev, back end for making realtime, typesafe React Apps
Good point, just removed the video. Will be deployed soon.
_query··on Show HN: thin.dev, back end for making realtime, typesafe React Apps
Back now. Sorry, deploy issue :)
← PreviousPage 2 of 6Next →