Has anyone used Brick (offline first architecture) in production

Help Backend & Database Integration
1

I found this package pure gold Brick Docs and the creator is someone from the google/ firebase team so I’m confident the technical standar should be great. But the documentation even extended, is hard to follow (at least for me even I’m not new to flutter) and there is not too much info about this besides their doc. Should someone has use it in production?

1 Like
2

Firstly welcome to the community!

Secondly, I made a note of this blog post where someone describes using Brick with Supabase as I’m currently considering adopting it for my app

Hopefully this gives you a bit of more of an insight :crossed_fingers:

It’d be great if someone from the community here has used it and can share their thoughts

3

Really amazed what big packages are out there that I never have heard about

2 Likes
4

I tried to use it, but is way too complicated (more complicated than PowerSync).

Brick is intended to be used when you have to deal with RPC or REST.

I prefer to listen to changes in my local database (so, for instance, when a record is changed in my SQLite, any widget that are using that row automatically rebuilds with the new version, so I don’t need to deal with complicated state management, caches, etc.).

Since PowerSync works transparently over SQLite (and it is compatible with Drift), it’s a far superior choice, especially because you can filter your local data easily with SQL (something brick will not allow - it only caches what you already read sometime ago).

5

Thank you for your reply. Actually that supabase post was the first place where I heard about brick.

I’m considering to migrate a production app (for the moment using firebase and hive but queries are complex, with a lot of duplicated values to keep relation and hive is no longer maintained) so I’m evaluating also moving to supabase and drift.

I probably be using powesync instead of my own implementation (I already did that with hive and is not hard but a lot of work).

Would be cool to see how we both implement the offline-first arch

6

Thanks, for the reply, will give a try to powersync

7

Lot of hidden gems in pub.dev. A shame that the search functionality is not really useful…

1 Like
8

Hopefully this forum will help make it easier to discover those hidden gems :crossed_fingers:

1 Like
9

A blast from my past. Brick was primarily written by an ex-coworker (and friend) of mine at a job I had long before I worked at Google. I was a small contributor because it was being built for our needs at that job.

Looking on Github, the same person continues to maintain it. FWIW, he is infinitely smarter than I am, and I have full confidence that it’s technically sound.

I haven’t had a reason to use it since that job (which I left in 2020), so I can’t speak to it more than that. I feel inspired to dig into it though.

10

Tried it yesterday, but it didn’t work as expected. The generator only created some file, but not all. @Sbrobow did you use Powerync with Supabase? If yes, how did you set up the sync rules in combination with RLS?

11

Yes. I use PowerSync, but I use it with Hasura. I find Hasura easier to deal with, especially on row level security, and Supabase doesn’t have functions if you install it on docker, so it is a deal breaker for me.

Since PowerSync is related to POSTGRES, not Supabase/Hasura, it will not know anything about RLS on those plaforms, so, basically, I deal with that twice (one time on Hasura, one time on PowerSync).

It’s kinda hard to do that because PowerSync doesn’t support joins on sync rules (I would love if they could do that, it would be sooooo much easy), so, sometimes, you must be creative.

RLS is the same: sometimes, it is impossible to have a setting for insert (or I could not see how to do it).

For instance, I have a table that holds device information (ID, screen size, OS version, etc.). Then, another table that links devices with users (many-to-many relationship). Then, a table with users. Since devices does not have direct relation with users, I could not get the insert to work (because for me to get to the user_id, I would need to insert users_devices first, but since this is a M-M table, it requires devices to be there first). I could denormalize this M-M association with an array, but that bite me in the SQLite area, so, no RLS for insert for devices table =\

Since sync rules are only for SELECT, they are easier, except that they don’t have support for JOIN, so, again, you can’t get devices directly (so you’ll end up with extra buckets for data that don’t have direct relationship to users):

bucket_definitions:
  #global:
  #data:
  #- SELECT * FROM lists
  #- SELECT * FROM todos
  user_data:
    parameters:
      - SELECT token_parameters.user_id as user_id
    data:
      - SELECT * FROM users_devices WHERE user_id = bucket.user_id
      - SELECT * FROM user_settings WHERE user_id = bucket.user_id
      - SELECT * FROM users WHERE id = bucket.user_id
  device_data:
    parameters:
      - SELECT device_id FROM users_devices WHERE user_id = token_parameters.user_id
    data:
      - SELECT * FROM devices WHERE id = bucket.device_id

TD;DR: It’s a bit tricker to sync SELECT RLS with PS SyncRules because one supports relationships, the other doesn’t.

1 Like