<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Hamid Wakili</title>
    <description>The latest articles on DEV Community by Hamid Wakili (@hamidwakili).</description>
    <link>https://dev.to/hamidwakili</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3934355%2F8bc19f93-1286-4dd3-87de-5f5d0c4f85ae.png</url>
      <title>DEV Community: Hamid Wakili</title>
      <link>https://dev.to/hamidwakili</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/hamidwakili"/>
    <language>en</language>
    <item>
      <title>How I built real-time Flutter notifications without Firebase</title>
      <dc:creator>Hamid Wakili</dc:creator>
      <pubDate>Sat, 16 May 2026 06:54:44 +0000</pubDate>
      <link>https://dev.to/hamidwakili/how-i-built-real-time-flutter-notifications-without-firebase-29ee</link>
      <guid>https://dev.to/hamidwakili/how-i-built-real-time-flutter-notifications-without-firebase-29ee</guid>
      <description>&lt;p&gt;I maintain another_flushbar on pub.dev — one of the more popular Flutter notification packages. After seeing how many developers were pulling in the full Firebase SDK just to show an in-app banner, I decided to build something simpler.&lt;/p&gt;

&lt;p&gt;The result is FlushKit: a remote in-app notification SDK for Flutter, powered by Server-Sent Events.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;The problem with Firebase for in-app notifications&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Firebase Cloud Messaging is excellent for push notifications when your app is closed. But if your app is open and you just want to show an announcement, an alert, or an onboarding tip — you're still carrying google-services.json, Firebase Auth dependencies, and a background service to do it.&lt;/p&gt;

&lt;p&gt;That felt like too much for the in-app case.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Why SSE instead of WebSockets&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;SSE (Server-Sent Events) is a persistent HTTP connection where the server pushes events to the client. One direction only — which is exactly what notifications need. No handshake overhead, no socket management, automatic reconnection built into the browser/HTTP spec.&lt;/p&gt;

&lt;p&gt;For Flutter, I built a persistent SSE client that reconnects on drop and replays missed notifications via a ?since= query parameter. If a user had the app closed, they get the notification on next open.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;What the integration looks like&lt;/strong&gt;&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight dart"&gt;&lt;code&gt;&lt;span class="c1"&gt;// Initialize once in your app&lt;/span&gt;
&lt;span class="n"&gt;FlushbarRemote&lt;/span&gt;&lt;span class="o"&gt;.&lt;/span&gt;&lt;span class="na"&gt;init&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="nl"&gt;apiKey:&lt;/span&gt; &lt;span class="s"&gt;'fk_live_••••••••'&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="nl"&gt;context:&lt;/span&gt; &lt;span class="n"&gt;context&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;

&lt;p&gt;&lt;br&gt;
`&lt;/p&gt;

&lt;p&gt;That's it. From that point, any notification you create in the FlushKit dashboard streams to every connected instance of your app in real time.&lt;/p&gt;

&lt;p&gt;The SDK handles reconnection, offline replay, action buttons, icons, and persistent mode — all built on another_flushbar under the hood.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;The backend&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Go/Gin with a SSE broadcast layer per app. Each connected Flutter instance holds an open HTTP connection. When you publish a notification, it fans out to all active connections immediately.&lt;/p&gt;

&lt;p&gt;The same SSE channel will carry Remote Config events next — one persistent connection, multiple message types.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Where it is today&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;FlushKit is live at flushkit.dev with a free tier. Early stage — I'm the solo founder. Feedback on the use case, the API design, or the pricing is genuinely welcome.&lt;/p&gt;

&lt;p&gt;If you're already using another_flushbar, FlushKit is the hosted layer on top of it.&lt;/p&gt;




&lt;p&gt;&lt;em&gt;FlushKit is built on &lt;a href="https://pub.dev/packages/another_flushbar" rel="noopener noreferrer"&gt;another_flushbar&lt;/a&gt;, &lt;br&gt;
which I also maintain. Free tier available at &lt;a href="https://flushkit.dev" rel="noopener noreferrer"&gt;flushkit.dev&lt;/a&gt;.&lt;/em&gt;&lt;/p&gt;

</description>
      <category>flutter</category>
      <category>dart</category>
      <category>showdev</category>
      <category>webdev</category>
    </item>
  </channel>
</rss>
