Comparison with Supabase

[klavinski]

Supabase is another bridge between Postgres and the front-end. How does Thin compare with Supabase? This is the main question preventing me from choosing Thin, as Supabase is more mature, popular, and has many features.

[mpscholten]

Thin is a bit higher level in certain aspects. E.g. thin has a few simple database operations (createRecord, updateRecord, deleteRecord, query).

This higher-level layer e.g. allows us to support optimistic updates. Optimistic updates make the UX a lot better as we never need to wait for the server response.

Thin also focusses much more on the realtime aspects as this allows us simplify the state management a lot (e.g. a thin app typically doesn't need a redux store for storing database entities locally).

Then there's also small things: Thin transforms under_score column names to camelCase identifiers when a database record is sent to the client. In Supabase you have to deal with under_score identifiers a lot, which feels a bit dirty in JS land :)

Thin delivers really great autocompletion and end to end type safety.

TL;DR:

• higher level API / more idiomatic
• optimistic updates
• more realtime
• uses camel case for JS identifiers
• end-to-end type safety

Maybe give both tools a try for a little example app and let me know what you like better

[klavinski]

Thank you for the thorough answer! Supabase has announced offline support without progress for two years. What are Thin's plans for offline support?

[mpscholten]

We might add offline support in the future, but it's not being worked on right now 👍

[klavinski]

I tried Thin, and did not find a way to build joins in queries (Supabase allows it, as it is a wrapper over PostgREST). How to do it?

[mpscholten]

Joins are not supported yet, but will definitely be added in the near future.

[gukii]

Can you comment on how Thin does data caching?

[mpscholten]

Mostly Thin doesn't do any kind of caching. It fetches the initial data, and then watches for changes on the result set.

For better UX when going forwards and backwards between pages, the useQuery hook caches the results of a query. Before the initial data is received from the server, the useQuery hook then might show some of the previously cached data. This only applies if the query is exactly the same as a previous query and is only visible for around 30 - 100ms (then typically the server data has arrived). And the main goal of that cache is to avoid loading spinners when going back between pages in an app.