Explore how Kubernetes is becoming a new server for serverless architecture as we look at a few of its established enterprise patterns and buzzing use cases.
A geo-distributed messenger application development journey continues: my next challenge is forwarding application requests to the instance closest to the user.
What does it take to build an efficient and sound data model for Apache Cassandra and DataStax Astra DB? Where would one start? Are there any data modeling rules to follow?
A closer look at Java at Microsoft and Azure and what Microsoft can offer to modernize existing Java-based apps or bring new ones with the practice of IaC
KEDA is an event-driven autoscaler that horizontally scales a container by adding additional pods based on the number of events needing to be processed.
The article discusses the architectures currently popular for achieving this Serverless Architecture for Scale use cases and how and when we can use them.
In this second part, learn how to centralize IAM for multiple AWS accounts, create and use EC2 instance profiles, and implement just-in-time access with Vault.
Covering the basics of managing AWS IAM with Terraform and learn how to delete the Root/User Access key, enforce MFA, customize password policy, and more.
google cloud messaging (or gcm) sends two types of messages: collapsible, “send-to-sync” messages, where new messages replace older ones in the sending queue. (i.e. the older messages are “collapsed”). non-collapsible messages with payload, where every single message is delivere d. each payload in non-collapsible messages is a unique content that has to be delivered and can’t be just replaced with a more recent message in the server sending queue. on the other hand, a collapsible message can be a simple ping from the server to ask its mobile clients to sync their data. when to use messages with payload? instant messaging (im) applications come to mind. another use case is when we need to include data into our push notifications to save our clients a round-trip to the server. an example use case would be sending daily/monthy online game rankings of top players. instead of just notifying the android clients to go to the server to get the information ( send-to-sync ), the data is included in the multicast messages themselves so that they can be directly consumed by the clients. we can easily see why collapsible messaging wouldn’t make much sense here, since we want our users to receive every single ranking we send them at the end of every week/month. let’s now jump into coding. as suggested in the two previous article, these code examples are modifications of the gcm demo application available for download (client + server) and using the gcm helper library for java . server code creating a message with payload in server code is similar to the process for the collapsible type, except that we simply omit the collapse_key parameter. // in imports import com.google.android.gcm.server.message; // inside send method, construct a message with payload message message = new message.builder() .delaywhileidle(true) // wait for device to become active before sending. .adddata( "rankings", "top 5 high game scorers" ) .adddata( "1", "1. yankeedoodle (15 trophies)" ) .adddata( "2", "2. billy_the_kid (13 trophies)" ) .adddata( "3", "3. viper (10 trophies)" ) .adddata( "4", "4. silversurfer (9 trophies)" ) .adddata( "5", "5. gypsy (8 trophies)" ) .build(); client code the client just retrieves the data by its keys: // inside gcmintentservice @override protected void onmessage(context context, intent intent) { // message with payload string message = intent.getstringextra("rankings") + "\n" + intent.getstringextra("1")+ "\n" + intent.getstringextra("2")+ "\n" + intent.getstringextra("3")+ "\n" + intent.getstringextra("4")+ "\n" + intent.getstringextra("5"); displaymessage(context, message); // notifies user generatenotification(context, message); } this is how it looks like on an android device: these messages can contain a payload limit of 4k of data so they are not indicated for applications that need to send more than that, although it is theoretically possible to get around that limit with multiple messages and some assembly work on the receiving android client application. another aspect to consider would be performance and impact on the handset’s batteries, since messages with payload are not as lightweight as their collapsible cousins. regardless of the message type, all payload data must be string values . so if we need to send some other type, it is up to our application to properly encode/decode the content.