Show HN: Firebase2graphql – Migrate from Firebase to GraphQL on Postgres | Hacker News Reader

Show HN: Firebase2graphql – Migrate from Firebase to GraphQL on Postgres

github.com

114 pointswawhal11 comments

Hi HN! We wrote this CLI to explore migrating from Firebase to Postgres as easily as possible.

We use Hasura[1] to generate the realtime GraphQL API on Postgres automatically. The CLI tool's work then mostly boils down to 2 things, which we do in phases:

1. Phase I: We migrate firebase data nodes to Postgres tables in a fairly naive way. We setup automatic IDs and parent-child tables and set up relationships between the tables. This gives you a write-many type GraphQL API on postgres. Realtime GraphQL with subscriptions and live-queries replaces firebase realtime

2. Phase II: As an optional next step, we try to normalise data by detecting overlapping data between tables. We delete "subset" tables and set up relationships to the superset table.

I've written up a blogpost with more details here: https://blog.hasura.io/firebase2graphql-moving-from-firebase...

[1] https://github.com/hasura/graphql-engine , https://hasura.io

Do real-time subscriptions also work on sorted, filtered lists?

E.g. If a new item is added to the list, will it appear in the list in real-time? Also, if an item's property is changed so that its position in the list changes, will this update the list in real-time as well?

If so, how does it prevent over-fetching?

Yes they work with filters, ordering etc.

> ... prevent over-fetching

This is handled server side. Subscriptions are more like 'live queries'. The server sends the data to the client only when the result set for the given 'live-query' changes.

It sounds like the server has to keep track of all active live-queries. Does it need to re-fetch all of them on every update?

Is this Hasura GraphQL Engine open source? What's the business model? Are there any features missing if you don't pay anything?

How does it get notified by PostgreSQL when the result of a query changes, since AFAIK PostgreSQL has no such built-in functionality? (it works if other apps change the database, right?)

Hasura's homepage[0] links to their Github[1], so it's definitely open source. The "Enterprise" section of the website seems a bit lite and all the pricing information is on the "Support" tab, so the business model seems to be support-based. I only skimmed so I can't speak to what missing features there might be if you roll-your-own.

[0]: https://hasura.io/

[1]: https://github.com/hasura/graphql-engine

That's a great question. I've been considering Hasura for an upcoming app and have been prototyping things with great success. I hadn't really considered how it implements the subscriptions, and had assumed it worked only by observing mutations that came in through GraphQL. However that doesn't really explain how it works with subscriptions against a view.

I dug into the code a bit and think it all happens here: https://github.com/hasura/graphql-engine/blob/master/server/... Which if my fledgling Haskell is correct digs into the subscription to find the sources and then adds a trigger on them.

On a related note, I've been very impressed with the Hasura GraphQL server. In particular how the authentication works with a JWT token and it's access restrictions seem pretty well thought out and flexible.

I have not yet used it in production but :fingers-crossed: it performs as well there as it has in testing and development

> AFAIK PostgreSQL has no such built-in functionality

Postgres actually has basic pubsub via "LISTEN" and "NOTIFY". I was planning on trying out rethinkdb as a real-time database but found that approach instead described in this blog post:

http://blog.sagemath.com/2017/02/09/rethinkdb-vs-postgres.ht...

which also had a huge comment thread with related links(800+ upvotes):

https://news.ycombinator.com/item?id=13610146

How do you secure this data in Hasura? The article does not seem to mention security.

https://docs.hasura.io/1.0/graphql/manual/auth/index.html

We provide an access control layer as a part of the GraphQL engine.

We took inspiration from Postgres's RLS and basically implemented it at the API layer so that the permissions/access control system is driven by your application auth and not your database auth.

This allows Hasura to give you role-based column/row level security integrated with any authentication provider or even a JWT.

More at the docs here: https://docs.hasura.io/1.0/graphql/manual/auth/index.html

Reply on news.ycombinator.com