uniqush-push

repository·master·Indexed 23 days ago

https://github.com/uniqush/uniqush-push

A self-hosted, unified push notification service that abstracts GCM, FCM, APNS, and ADM mobile platform APIs into a single RESTful interface. It provides a language-agnostic abstraction layer for server-side notifications, requiring a Redis server with persistence enabled for user data storage.

Tokens
6K
Snippets
8
Records
35
Agent score
81%

What's inside uniqush-push

  1. Overview of Uniqush Push

    master

    Uniqush is an open-source system that provides a unified push service for server-side notifications to mobile devices. Instead of integrating multiple different push service APIs into your application, you run uniqush-push on your own server. It acts as an abstraction layer that communicates with various mobile platform push services via a single interface.

    Key Characteristics:

    • Self-hosted: Unlike SaaS solutions (e.g., Urban Airship), Uniqush is a system you run on your own infrastructure.
    • Language Agnostic: It provides RESTful APIs, meaning you can communicate with it using any language that has an HTTP client library.
    • Dependency-free: It is distributed as a binary; you do not need to install the Go compiler to run it.
  2. Configure Redis for Uniqush-push

    master

    Uniqush-push requires a Redis server to store user data.

    Critical Requirement: You must ensure that Redis persistence is enabled. This ensures that user data is saved correctly during shutdowns and can be backed up.

    To enable persistence, your redis.conf should be configured according to the Redis persistence documentation. Ensure the configuration includes settings similar to the **PERSISTENCE** section found in standard Redis configuration examples.

  3. How PushBackEnd handles errors and retries

    master

    The PushBackEnd implements an automated error handling and retry mechanism:

    1. Error Processing: An internal goroutine listens on errChan and processes various error types (e.g., RetryError, PushServiceProviderUpdate, InvalidRegistrationUpdate).
    2. Retry Logic: If a *push.RetryError is encountered, the backend will automatically retry the push. It uses an exponential backoff strategy, doubling the wait time after each failure, up to a maximum interval of 1 minute.
    3. Automatic Cleanup: Certain errors trigger automatic database updates. For example, InvalidRegistrationUpdate or UnsubscribeUpdate will automatically call Unsubscribe to remove the invalid delivery point from the database.
  4. Initialize and Run the RestAPI

    master

    To use the RestAPI in a Go application, construct it using NewRestAPI and start it with Run.

    // Example initialization
    api := NewRestAPI(psm, loggers, "1.0.0", backend)
    
    // Create a channel to handle graceful shutdown
    stopChan := make(chan bool)
    
    // Run the API on a specific address
    go api.Run(":8080", stopChan)
    func NewRestAPI(psm *push.PushServiceManager, loggers []log.Logger, version string, backend *PushBackEnd) *RestAPI {
    	ret := new(RestAPI)
    	ret.psm = psm
    	ret.loggers = loggers
    	ret.version = version
    	ret.backend = backend
    	ret.waitGroup = new(sync.WaitGroup)
    	return ret
    }
    
    // ...
    
    func (api *RestAPI) Run(addr string, stopChan chan<- bool) {
    	// ...
    	err := http.ListenAndServe(addr, nil)
    	if err != nil {
    		api.loggers[LoggerWeb].Fatalf("HTTPServerError \"%v\"", err)
    	}
    }
  5. Supported Push Platforms

    master

    Uniqush-push abstracts the following push services:

    • GCM (Google Cloud Messaging) for Android
    • FCM (Firebase Cloud Messaging) for Android
    • APNS (Apple Push Notification service) for iOS
    • ADM (Amazon Device Messaging) for Amazon Kindle tablets
  6. Load the REST API listening address

    master
    The LoadRestAddr function retrieves the address for the HTTP REST API from the [WebFrontend] section using the addr key. If the key is missing or empty, it defaults to localhost:9898 (which only accepts local connections). To listen on all interfaces, use 0.0.0.0:9898.
  7. Load system loggers

    master

    The LoadLoggers function initializes an array of log.Logger instances for different system categories.

    It first looks for a logfile key in the [default] section. If a valid file path is provided, logs are written there; otherwise, they default to os.Stderr.

    Each logger is configured via its own section in the config file using the following mapping:

    • LoggerWeb $\rightarrow$ [WebFrontend]
    • LoggerAddPSP $\rightarrow$ [AddPushServiceProvider]
    • LoggerRemovePSP $\rightarrow$ [RemovePushServiceProvider]
    • LoggerPSPs $\rightarrow$ [PSPs]
    • LoggerSub $\rightarrow$ [Subscribe]
    • LoggerUnsub $\rightarrow$ [Unsubscribe]
    • LoggerPush $\rightarrow$ [Push]
    • LoggerSubscriptions $\rightarrow$ [Subscriptions]
    • LoggerServices $\rightarrow$ [Services]
    • LoggerPreview $\rightarrow$ [Preview]

    Within these sections, you can control logging behavior using:

    • log: A boolean to enable/disable logging for that category.
    • loglevel: The verbosity level. Supported values are alert, error, warn/warning, standard/verbose/info, and debug.
  8. Initialize a PushBackEnd instance

    master
    To use the push backend, initialize it using NewPushBackEnd. This function sets up the PushServiceManager, connects the provided PushDatabase, configures loggers, and starts an internal error processing loop. It also wires the PushServiceManager to report errors back to the backend via a channel.