Supabase

[jtkeyva]

Just came across this twice in one day. Someone said they are using this with Supabase. There is a huge opportunity with Supabase...there is no offline support and this could be the solution. Any info/tips resource appreciated.
Thanks!

[hortigado]

@jtkeyva it was me 😅, well I implemented them with appwrite but with supabase it's the same process through api rest. Soon I will upload a tutorial but read the documentation is not hard

[tshedor]

Hey @jtkeyva and @hortigado looking into this, Supabase has an offline upload client (based on the exponential backoff documentation) and they have an offline storage system (based on the use of Hive).

The docs aren't explicitly mentioning this offline capability, so I'm not completely guaranteeing this. But Supabase might do everything that Brick does minus SQLite out-of-the-box.

Was there a feature you were requesting specifically @jtkeyva to be supported by Brick?

[jtkeyva]

@jtkeyva it was me 😅, well I implemented them with appwrite but with supabase it's the same process through api rest. Soon I will upload a tutorial but read the documentation is not hard

@hortigado That would be awesome! I'm certain the Supabase community and prob even the Supaabase team would really appreciate how you pulled it off. I look forward to the tutorial, please post on /r/flutterdev and in the supabase forums and here so people can enjoy your work :)

[jtkeyva]

@tshedor
Just looking for a turn-key solution to offline support for Flutter & Supabase. There is a giant hole / opportunity to solve this universal problem.

Basically, not have the app go blank or give any errors while offline, the ability to queue database entries and file uploads and resume them if it goes offline.

Using brick, does that eliminate the need for flutter_cache_manager, chached network_image and cached_video_player?

What about for web, how does this work? I think Flutter web has a hard time if not impossible to cache?

[tshedor]

@jtkeyva do you know if Supabase's first-party offerings already support offline mode? Because reading the code I think they do.

Brick is strictly data persistence (for example, REST calls, GraphQL calls) - so it won't cache assets like files or network images or videos.

For web, Brick utilizes sqflite_common's APIs. So you bring your own SQLite integration - this allows for FFI bindings when running unit/widget tests or for using WASM SQLite support.

For example, when initializing your repository:

sqliteProvider: SqliteProvider(
  'myDb.sqlite',
  databaseFactory: kIsWeb ? databaseFactoryFfiWeb : Platform.isLinux ? databaseFactoryFfi : databaseFactory,
  modelDictionary: sqliteModelDictionary,
),

[tshedor]

Hey @jtkeyva I'm going to close this ticket next week unless I can answer more of your question.

[jtkeyva]

Hey @tshedor there is no Flutter solution and the discussion is getting some momentum. Perhaps Brick could be a (another) solution? This is a big opportunity the help a growing market as Supabase is getting very popular but still have some holes to fill aka offline mode.

https://github.com/orgs/supabase/discussions/357

I look forward to your thoughts.

Thanks

[tshedor]

@jtkeyva based on that thread, it looks like offline mode is being discussed for web-based clients (i.e. JavaScript). Are you absolutely sure that Supabase's own Flutter client does not support offline mode?

From this thread, I'm pretty sure that the Supabase team was concurrently adding a similar caching system at the time the comment was published.

Can you please verify within your own app that offline is not supported by Supabase's client?

[jtkeyva]

The store the auth info locally but that's it.

We have been asking for a very long time...not much has been done.

When i am offline and i try to add a record from my Flutter app i get this error:

Exception has occurred.
_ClientSocketException (ClientException with SocketException: Failed host lookup: 'XXX.supabase.co' (OS Error: nodename nor servname provided, or not known, errno = 8), uri=https://XXX.supabase.co/rest/v1/message_test)

[tshedor]

@jtkeyva Ok, that's useful. Are you able to fetch data? For example, if you're on a screen that has previously loaded information from Supabase, does that information still appear when you navigate away from that screen, go offline, close the app, reopen the app, and then return to that screen?

[jtkeyva]

@tshedor No, I loaded a page, went offline, then went back to home and loaded again and it fails. I can assure you if I close the app it will fail too.

I think if I used Hydrated Bloc it might help on a single page?

[jtkeyva]

also, i tested uploading while offline and it didn't work when i came back online

[jtkeyva]

@tshedor anything else i can do to test or help to see if this is doable?
thanks

[tshedor]

Hey @jtkeyva I just started a new role and I don't have the time to integrate this right now. Maybe in the future, but I definitely won't be able to do it by the end of the year. I'm sorry.

[jtkeyva]

@tshedor Got it thanks for letting me know

[Tonku]

Any news on this.. I am happy to contribute to supabase caching ...

[tshedor]

Hey all, quick update that I've been looking at Supabase and just might be able to put a package together. I'll give a better update within the month

[jtkeyva]

sounds good thank you

[mike-abides]

Whoa! I recently stumbled on Brick after trying to solve the offline-first issue when Supabase is our backend. SUPER impressed so far, I'd been manually rolling my own implementation with bare Sqflite and it was a nightmare...

The way I'm solving this issue at the moment is by leveraging Supabase's REST api instead of the native Dart client (which is just a convenience wrapper around the REST api anyhow...). I treat Supabase as a plain old REST provider, pass the appropriate HTTP headers with every request and its all working like magic.

Unless I'm missing something, I'm not sure why we need a dedicated Supabase provider? Maybe people don't know there's a REST api under the hood?

[hortigado]

@mike-abides Correct, I also use it with appwrite and because I saw that supabase also provided api rest I said it was compatible. So I don't understand why in the end no one could use it.

[jtkeyva]

@hortigado @mike-abides
thanks guys! any chance you can share a snippet about how you are solving this? https package? dio? are you making your own dto?
thanks

[devj3ns]

Hey guys, I just created a PR which adds a minimal example on how to use Brick with Supabase using the PostgREST API. Feel free to check it out, ask questions and give feedback:

#392

I have been using Brick in combination with Supabase to build a local-first app, and I am very pleased with the results so far. What I really appreciate about Brick is its simplicity and modularity. It gives you full control over your data synchronization process, eliminating the need to rely on external (and often paid) sync services. I consider Brick to be a good foundational technology you can build up on when creating local first flutter apps.

[tshedor]

All, I'm finally diving into the Supabase integration. Significant updates will be on #401 along with progress updates in the checklist of the opening comment. The WIP branch is supabase-integration. I'll post another update here when it's ready for alpha testing and when it's ready.

In the meanwhile, if you're interested in helping out, I'd love help with test and doc writing. For the more courageous, the biggest whale will be writing the queue. Please feel free to jump in on that issue on unchecked tasks for each package.

@jtkeyva @devj3ns @hortigado @mike-abides @Tonku @luccasclezar

[devj3ns]

That's awesome @tshedor! 🎉🚀

I would like to help out as much as I can, as the app I am building over the last few months heavily relies on Brick. Even though my implementation using the REST provider works, I definitely see places that can be improved, especially with the queue and associations.

[tshedor]

@jtkeyva @devj3ns @hortigado @mike-abides @Tonku @luccasclezar I've got an alpha version of Supabase ready for you all to try and experiment. I want to stress this is not production ready. Things will break. It's not fully unit tested.

But I'd like to know what your headaches are. The repository recycle's Rest's offline queue, which makes setup a little less straightforward while giving it the reliability of a well-tested queue system.

You can add brick_offline_first_with_supabase: to your pubspec's dependencies and brick_offline_first_with_supabase_build: to your dev_dependencies to get started. The source code is still WIP on supabase-integration.

Please comment on #401 with any feedback, suggestions, or bugs. I hope to resolve quickly but will triage to separate issues when necessary.

[devj3ns]

Thanks for your work on this @tshedor!

I have Brick with Supabase (manually using PostgREST and Brick's REST Provider) running in production in the app I've been building for a local company for months.

I look forward to testing the new first-party integration in a separate branch and sharing my feedback.

[tshedor]

@jtkeyva @devj3ns @hortigado @mike-abides @Tonku @luccasclezar After extensive testing by @devj3ns , this has been merged into main and released as 1.0.0.

Please checkout the setup guide or the example package.

I'll write an announcement post soon. With the release, this issue can, at long last, be closed.

[jtkeyva]

Thanks! Exctied to try this but your example gave me an error:

════════ Exception caught by widgets library ═══════════════════════════════════
The following assertion was thrown building Builder:
_MyHomePageState.initState() returned a Future.
State.initState() must be a void method without an async keyword.
Rather than awaiting on asynchronous work directly inside of initState, call a separate method to do this work without awaiting it.

[jtkeyva]

also there is no pizza in your sql queries examples

[tshedor]

@jtkeyva I've updated main with seed information for pizzas and removed the Future. Please try it again, and if anything goes wrong, please open a separate issue. I'm trying to keep this one closed.