PACKAGES: Background processes and Notifications

[winwisely99]

why ?

Use case like Chat.

• Use does NOT have app open
• We DO NOT want to use the Google and Apple services to do a notification and hence deeplink into the app. We dont want to because of security reason.

When user has app open, then NATS will do the push over GRPC ( and GRPC-web).

Targets

On mobile we need to check if messages arrived and then make a local notification to wake up the GUI. https://github.com/transistorsoft/flutter_background_geolocation

• Seems to have solved it.
• needs testing

On Flutter Desktop also. But we can run a Golang service to do that.

• we use go-flutter BTW ( https://github.com/go-flutter-desktop/plugins)
• I think we can write a Desktop notifications plugin.
• Flow is like:
  • Service raises a OS level Notification
  • User clicks on OS Notification
  • Calls OS Url Scheme to open the flutter app.
  • Deep links to the right page.

On Web

• not needed
• But need a way to show notifications that feels like how it does on desktop or mobile.
• Or maybe browser support it these days and we can hook into it and it will show a Desktop OS notification and when the user clicks on it it will open the app.
• Sounds liek the PWA architecture. Like how you can install a PWA on android and ios these days.
• On Desktop browser maybe is hooks into the OS too ?

Code

https://github.com/transistorsoft/flutter_background_geolocation

• works on mobile apparently

https://github.com/appleboy/gorush

• Golang server for pushing notifications to the offical Google and Apple systems.
• even though we DONT want to do this, it makes sense to extend it to support OUR way of pushing notifications.
• NATS can call it.
• has K8 yaml (https://github.com/appleboy/gorush/tree/master/k8s)

[AKushWarrior]

The basic workflow of this section, as I understand it, is to check for new messages in the background and push a notification if there is any.

(I'm not a NATS/Golang expert, so I don't have much to say about checking for new messages. )

The main issues to solve here are:

1. Running a background process to check for messages.
2. Pushing a notification if there are any.

Each platform has a proposed solution.

Mobile

• No significant edits from me.
• The best plugin for background exec is https://pub.dev/packages/background_fetch
• The best plugin for notifications is https://pub.dev/packages/flutter_local_notifications
• For the future roadmap, a better IOS solution: this one only allows updates at 15+ min intervals.

Desktop

• Run a background golang service, and push notes.
• I'm not a go dev, so I don't know how easy or hard this is.

Web

• There is no plugin to simplify this for us.
• I don't know how the server architecture looks, so I don't have an exact plan here.
• To run our background thread, we can use service workers: https://pub.dev/packages/service_worker
• One method to push notifications is using JS integration:
  • While there's no native notification service for Flutter Web, we can use JS notification services and call them with https://pub.dev/packages/js
    • We could, for example, use Push.js
    • This works across most platforms (see caveat below)
  • One BIG caveat: Push.js (and other solutions) don't work on IOS or Android WebView. It looks like web pushing on mobile isn't even possible for IOS.
  • We could also try our hand at writing a push notification service in native dart for flutter web. However, JS interop is probably more time-effective.

[AKushWarrior]

Some basic workflows to encapsulate the proposals above:

Mobile: Once user logs in, start background_fetch, which will push notifications if message has been received.

Desktop: Install a golang service to run in the background along with the app. Run the service to fetch in background and push notifications.

Web: Ask user to subscribe to notifications upon login. If they say yes, start a service worker to do check for messages in background; if a message is found, push a notification using JS interop.

[AKushWarrior]

Some context on Service Workers (for non-JS devs) is available here. There are drawbacks, and in the future we might want to transition to the Push API. However, Safari does not currently support the Push API, so service workers are the most complete solution AFAIK.

[winwisely99]

I will connect you with the Dev bringup the golang push server !.

Great work.

Let's get busy

[winwisely99]

For now just fake it from s background isolate so we can see the 3 client types

[winwisely99]

I have an idea !

We can push message to mobiles using the standard google and apple push services but just say "you have messages". It means that that Apple etc dont see what the message is, and the user open the app and sees their messages in Flutter dedicated messages area.

• can have a messages pane in the app just like https://messages.google.com/web/conversations is
• this strategy of only using the OS Notifications to say "You have messages" can be used for desktop and web also, so we are using the message pane on Mobile, Desktop and Web in a consistent way. It also means we dont leak to the OS on any OS
• Also the Message Pane will allow use to keep a history of messages, which is useful for audit trails etc
• From the Message Pane, the we wont have to use Deep Linking, because the user is already inside the app, and so its really just normal routing. For example to open the Chat Module or the Documents Modules

We can get this working for mobile at V1, and then if we can get background channel for V2, drop using apple and google. The main thing is we have a lowest common denominator via V1 to get going.

The server to do it is there: https://github.com/appleboy/gorush k8 files: https://github.com/appleboy/gorush/tree/master/k8s

[winwisely99]

@Winwisly100 You can work up LiftBridge to work with this @AKushWarrior You can work up the Flutter Layer. Where to do the work ?

I think that a mod-messages folder in packages makes sense because we will have a dedicated Messages Pane now.

@winwisely112 You can get gorush going and onto k8. The k8s looks old but i think should be good.

https://github.com/appleboy/gorush#run-grpc-service has a GRPC API so we can call it from one MicroService to the gorush MicroService.

• this implies we need internal Network Discovery which we would need anyway.
• the PKI we use for this is mentioned in another Issue and is the same one that minio is using to do mTLS cert creation between Servers inside k8.
• Also gorush uses Redis for storage. We can use it for now and flip over to RedisTIKV with no API changes later. SO we get HA. See: https://github.com/siddontang/redis-tikv-example
  • this is the same thing the ion team are switching over to.

[AKushWarrior]

@winwisely99 Just confirming plan...

For mobile, go will push notification directly, so there's no need for a background service ATM.

For desktop, installed Go service will push the notification, so there's nothing there.

For web, we'll still have to roll a service worker or something to notify in the background, BUT it doesn't use the contents, it just says "new message available".

In the 'mod-messages' folder, what am I building with Flutter? Should I outline the messages pane's UI/UX? Or do the platform integrations? Or both?

[winwisely99]

@AKushWarrior Yep you got all your assertions correct :)

Yes in Packages/mod-message ( singular) your building the client

• Use standard material design
• Just like the google version look and feel (link above)
• worth making an example to show it working
  • and that it can open another route
• Add a button to fire a message so you can run without a golang server behind you i suggest
• Keep it raw for now. DOnt worry about how it looks for now

The golang stuff is not ready ( but i already made issues around it for us to work on )

• We can get gorush up pretty quick though.
  • Will need a golang CLI to fire them from dev workstation . EASY
  • We can get gorush running on google cloud pretty fast (@winwisely112 ), so the CLI will create a message and send it to the cloud gorush and so your Flutter client will get it.
• The Desktop service
  • This will listen to the gorush server
  • can get that going pretty fast

[AKushWarrior]

@winwisely99 Sorry, just one more thing. Am I using any methods to organize my code (Redux, MobX, BLoC, etc.) ?

[winwisely99]

We use hive :) it's pretty cool

[winwisely99]

Let's get liftbridge and gorush into CI. @winwisely112 Then golang coders can write code without needing it installed locally.. Run off the network repo. We use that for all network infrastructure.

Expose public. We don't care about layering of public / private yet. So it's a flat hierarchy for now

Liftbridge.ci.network.getcoyragenow.org Https

---

Do exactly the same for gorush rush.ci.network.getcouragenow.org

Concept is for liftbridge to fire messages into gorush. These messages will be caught by the flutter client so gorush is our transport for mobiles

The other aspect is to use liftbridge and allow grpc to be the transport and for flutter grpc to catch the events. So grpc is our transport for desktop and web.

---

@Winwisly100 Need a golang microservice to use it. Can run it locally for now Use packages/mod-messages older I think.

It will call Liftbridge. Liftbridge will then fire the same message into gorush and liftbridge grpc , this denting the same message to mobile , desktop and web.

Put your cli into Tools/messages

• one to do direct calls to liftbridge that is public .hard code URL for now so Devs have something to do fire messages into it
• one that talks to the microservice t by ATS running locally.

[winwisely99]

@AKushWarrior flutter web produces a service worker automatically these days I think.

For web you will get your messages via grpc liftbridge client pushed to you. So maybe service worker is redundant now.

You are going to have to write code to wrap the grpc dart client that liftbridge code generates for you. https://github.com/liftbridge-io/liftbridge-api

We maintain the forks in my repo ( winwisely99). So it should be there is @Winwisly100 has pushed it.

--

All: for linking from the getcourage repo to my winwisely99 repo I think the easiest way is to use git submodules !! That way in winwisely99 we can maintain all externally forked code. And getcourage can just update it's git submodules to link to the hash of the version in winwisely99. We can use this technique for golang and flutter. The reason is because we can keep getcouragenow repo clean and structured.