Starting April 1^st 2023 our prices will be changing. These changes enable us to reinvest back into the Engine Yard product ensuring that we provide our customers with best-in-class PaaS. It also takes into consideration inflation.

Support Pricing

These changes will be reflected in your invoice based on the date above, on the following billing cycle.

*Applies to Engine Yard Cloud base pricing. Additional charges for support on older stack versions remain.

Platinum pricing will not change in either offerings.

Account Charges

Engine Yard provides instances which require maintenance and monitoring irrespective of the level of resources customers use. In order to support this maintenance, we will need to add an Account Maintenance Fee that, up until now we have never charged.

**Applies to Engine Yard Cloud accounts.

Again, this will allow us to execute on our deliverables to our clients, both from a platform and support standpoint.

Cost Savings on Annual Term

Engine Yard is happy to announce a new agreement with AWS which is based on us working with them on an annual basis. As a thank you for being an Engine Yard customer, we would like to directly pass these savings on to you.

Therefore, we are offering the below discount on AWS IaaS instances moving forward:

In order to benefit from this discount please reach out to customersuccess@engineyard.com and they will be able to advise and update your invoice accordingly.

For any further information please reach out to customersuccess@engineyard.com.

We thank you for being a valued Engine Yard customer. We appreciate your business and look forward to continuing to help you be successful.

The Engine Yard Team

The post Engine Yard Cloud: Pricing Update appeared first on EngineYard.

The post Engine Yard stack v7 is now generally available appeared first on EngineYard.

Play Video

Recap of Engine Yard Innovation Event

Thank you for making the Engine Yard Innovation Event successful. It was a pleasure seeing many of our Engine Yard customers participate in the event. To recap, here are some exciting innovations we announced at the event:

1. Availability of CloudFix, AWS Cost Optimization platform, for Engine Yard customers
2. Support for Graviton processors across the platform
3. Updated Engine Yard v7 stack
4. General availability of DevSpaces cloud dev environments

CloudFix

CloudFix is the easiest way to save 10% to 20% on your AWS costs with few clicks. CloudFix finds and executes 100% safe, AWS-recommended fixes to save on your AWS spend. As a certified AWS partner, CloudFix saves you time and money with zero downtime and zero performance degradation.

CloudFix is available to Engine Yard customers to run on non-Engine Yard AWS accounts.

CloudFix is free for Engine Yard customers to run it on their non Engine Yard accounts. It is free up to an annual AWS spend (aggregate of all connected AWS accounts) that is 10x that of your Engine Yard spend. E.g. You spend $2,000/mo on Engine Yard. Your annual spend with Engine Yard is $2,000 * 12 = $24,000. CloudFix is free up to $24,000 * 10x = $240,000 of annual AWS spend.

Graviton

Graviton is an ARM based processor from AWS that delivers up to 40% price-performance over equivalent x86 processor. When AWS releases next version of Graviton processors (aka Graviton 3), the price-performance is expected to improve even more. 

Just like AWS, Engine Yard is making a big bet on ARM and investing in the technology to continue making AWS easier for you. Engine Yard now supports Graviton on both Engine Yard Cloud and on Engine Yard Kontainers. In addition, Engine Yard is committed to supporting Graviton 3 when it’s available.

Engine Yard v7 Stack

Engine Yard is releasing v7 stack in preview on both Engine Yard Cloud and on Engine Yard Kontainers.

v7 stack includes Ubuntu LTS 20.20, Chef 17, Ruby 2.7+, MySQL 5.7, 5.8 and PostgreSQL 10+. Stack v7 fully supports both x86 and ARM processors.

DevSpaces

DevSpaces offers cloud-based high-performance, clean, consistent dev environments that you can get up and running in seconds. With DevSpaces, you no longer need to spend hours setting up dev environments.

With DevSpaces, you get memory that can expand up to 100s of GB, unlimited hours & unlimited parallel workspaces. You can collaborate with live sharing and can code anywhere with browser based VS Code.

 

The post Engine Yard Innovation Event appeared first on EngineYard.

The post That’s Not a Memory Leak, It’s Bloat appeared first on EngineYard.

Evolution of Encrypted credentials

Encrypted secrets were introduced with Rails 5.1 in a view to bringing more security to the secrets handled. In this version, these were referred to as ‘secrets’ and were referenced by

The secrets.yml.enc file handles the secrets along with an encryption key.

Handling secrets before Rails 5.1

 Before this version of Rails, there were two methods to commit the secrets. 

• The first method was to store secrets onto the secrets.yml file, read secrets from environment variables, and commit the secrets.yml file to the repository. Though this method was easy to operate, it had a high-security risk as any gem used can dump environment variables. Since the data is open and not encrypted, this can be read by anyone accessing the repository.
• The second method was to store all secrets in the secrets.yml file and not commit them to the repository.

Handling secrets in Rails 5.1

By default, from this version of Rails, the secrets were passed as secrets.yml file along with an encryption key. Without this key, the secrets stored in the file will look like some junk characters. To initiate using secrets, the user needs to run:

This would create two files: config/secrets.yml.key and config/secrets.yml.enc. The key file will hold the secret key to decrypt data in the enc file.

Encrypted Credentials in Rails 5.2

An update to the older secret handling, this Rails version removed plain text secrets, and only encrypted credentials were allowed. Credentials were stored in config/credentials.yml.enc, and the key was stored on config/master.key. Thus users could deploy code and credentials together and store all credentials in one place.

Here, multi-environment credentials were handled by specifying explicitly, and the configuration was accessed by mentioning the access_key_id.

Encrypted Multi-environment Credentials in Rails 6.1

The latest update made it to separate credential files for each environment. This built-in feature necessitates separate encryption keyfor each credential file, thus guaranteeing more security.

A global credential file is enough for multiple environments. And when the environment is passed, two files would be created:

Here’s an example of how it works:

If the environment file is missing or not created, the default credentials.yml.enc file will be used.

Also, the config/credential/prod.yml.enc file would be committed to the repository, whereas the config/credential/prod.key file would not.

Add-ons in Rails 6

• It is now possible to store the credentials in a location of your choice. This is explicitly mentioned by running:

config.credentials.content_path and 

config.credentials.key_path

Make sure to save the valid key and the credentials to avoid errors while running the code. 

• Handle local environment credentials using

config/credentials/environment.key and 

config/master.key

• The below command tells Rails to search the credentials file in path config/credentials/local.yml.enc instead of config/credentials/development.yml.enc

Our latest guide Rails encrypted credentials on 6.2offer an interesting peek into the Rails credentials.

Advantages of encrypted credentials

The main advantages of encrypted multi-environment credentials are as follows:

• Safety: The separate encryption key for each environment makes it safer
• Easy deployments: since the variables can be moved along with the code, deployments become easier
• A single upload of the key is enough
• The solution applies to any of the Ruby on Rails applications

Conclusion

Rails is constantly improving the efficiency and scalability of the framework. With the multi-environment credentials enabled, applications used in multiple platforms and POD find it easier to keep the codes simple and accessible.

Know how to use Engine Yard Kontainersto connect to your database, enabling the Rails credentials for improved security.

To learn more about the older versions of credentials, check out Encrypted Rails Secrets on Rails 5.1

The post Evolution of Encrypted Credentials in Rails 6.2 appeared first on EngineYard.

Having a better understanding of NGINXwill make it easier to follow this blog.

Return directive

Return is the easiest way to rewrite a URL declared in the server or local machine.

Return in Server:

Suppose your site is migrated to a new domain and all existing URLs are to be redirected here; run the below code to direct any new request to your site.

This directs all requests that hit www.previousdomain.com to www.currentdomain.com. The www.previousomain.com will send out a ‘301’ error as soon as the above code is run, and a new access request is generated. The two variables, $scheme, and $request_uri, get data from the input URL. ‘Listen 80′ indicates that the block applies to both HTTP and HTTPS requests.

Return in local

If you want to redirect pages in place of a complete domain, you can use the return directive under the location block.

Knowing how to create the Nginx rewriterules can save a lot of your effort and time.

Rewrite directive

Just like the return directive, the rewrite directive can also act in both server and local. Compared to the return directive, the rewrite directive can handle complex replacements of URLs. The following is the syntax of the rewrite:

The regex is a regular expression that matches against incoming URI.

The replacement_url is the string used to change the requested URI.

The value of the flag decides if any more redirection or processing is necessary.

Static page rewrite

Suppose you want to redirect the page https://example.com/tutorial to https://example.com/new_page. The directive will be:

The line location = /tutorial defines that any identification of the tutorial is to be replaced. The rewrite command says to replace the phrase within notations ^ and $ with ‘new_page.html’ and then break the command. The notation ‘?’ is termed as a non-greedy modifier, after which the pattern search is stopped.

Dynamic page rewrite

Consider rewriting the URL https://www.sample.com/user.php?id=11 to https://www.sample.com/user/11. Here, the user=11 is to be replaced. By using the static rewrite method, it would require writing the rewrite command 10 times. Instead, let’s do it in a single go.

The line location = /user.php asks Nginx to check for the prefix’/user’. As said earlier, the Nginx will search for phrases between the start and end notations as ^  and $ along with the non-greedy ‘?’ modifier. The phrase in our example is a range of users. It is mentioned inside the square brackets as [0-9]+. The back-reference in this expression is noted within the parenthesis and is referred to by the $1 symbol. So, for our example, the rewrite will happen for all users automatically. 

One special case under the dynamic reference is the multiple back-references. 

Now, we have discussed how to write the rewrite rules for simple and complex URLs.

Understand the detailed working of rewrite rules through some exampleshandling various scenarios.

Scale performance. Not price. Try Engine Yard today and enjoy our great support and huge scaling potential for 14 days.
Deploy your app for free with Engine Yard.

Directive Comparison

Let’s analyze both directives by comparing them and find out why the rewrite derivative is more powerful.

Return directive

• It is simple to use and understand. 
• It can be used in both server and location contexts. 
• It explicitly mentions the corrected or updated URL so that the client can use them in the future. 
• Return directives can include multiple error codes as well.
• For codes 301, 302, 303, and 307, the URL parameters define the redirect URL. 

return (301 | 302 | 303 | 307) url;

• For other codes, the text is to be explicitly mentioned by the user. 

return (1xx | 2xx | 4xx | 5xx) [‘text’];

For example: return 401 ‘Access denied because the token is expired or invalid’;

• This directive can be used in scenarios where the return URL is correct for both server and location block, and rewritten URL is built with Nginx variables.

Rewrite directive

• It can accommodate more complex URL modifications where capturing elements without Nginx variables or an update in the elements in the path is required.
• It can be used in both server and location contexts. 
• The rewrite directive can return only code 301 or 302. To accommodate other codes, explicitly add the return directive after the rewrite directive.
• It may not send the redirect details to the client.
• The Nginx request processing is not halted.

Conclusion

The return and rewrite directives can be used to redirect URLs in both server and location contexts. Though the return directive is much simpler, the rewrite directive is widely used as it can also handle complex modifications/updates to the URLs.

The post Rewrite Rules in Nginx appeared first on EngineYard.

Let us see in detail how this is managed in our Rails applications.

1. Executor: Executors separate the framework and application codes by wrapping the application code.

The wrapping of code was more complex before Rails 5.0. To protect a code, either separate Rack middleware classes were used or direct wrapping was used. With recent updates in Rails, the executor handles the wrapping in a single step that is easier to understand.

Call the executor to wrap the application code as you invoke it.

For example:

One attractive feature of the executor is its reentrancy.

Two callbacks of the executor are ‘to run‘ and ‘to complete.’ This enables wrapping code in parts when it is not possible to wrap the code as blocks.

The current thread is moved to the ‘running’ mode, temporarily blocking the thread. So, the thread will not be accessible by any other request that tries to do so.

2. Reloader: The Reloader functions similarly to the Executor. The code that is to be protected is wrapped before another request is hit. This is used in scenarios where application code is invoked multiple times by any long-running process. Most often, in Rails, the web requests and Active Jobs are by default wrapped. So the Reloader is rarely used.

A Reloader is employed when there is a need to reload the application. When the requested condition asks for reloading, the Reloader delays the application reload until it is secure. And for scenarios where application reloads are mandated, the Reloader waits until the current block is executed and allows the reload. Thus, the code is protected from errors.

The ‘to_run‘ and ‘to_complete‘ callbacks are used by the Reloader also.

A class unload is involved in the Reloader process. Here, all of the auto-loaded classes are removed and set ready to be further loaded. The application reload is to happen only before or after the class unload, and so, the two additional callbacks of Reloader are ‘before_class_unload‘ and ‘after_class_unload‘.

Executor and Reloadersare used by the Rails framework components as well. ActionDispatch::Executor and ActionDispatch::Reloader are included in the default application stack. Whenever there is a code change, the Reloader serves a fresh copy of the application for an HTTP request. Active Job feature also utilizes Reloaders, whereas Action Cable uses Executor. Action Cable also uses the before_class_unload of Reloader to disconnect all the connections.

As discussed, code concurrency is handled by default with the threaded active jobs and action cables features of Rails codes. With recent Rails updates, Executors and Reloaders are also added to improve the code concurrency handling.

The post Code Concurrency and Two Easy Fixes appeared first on EngineYard.

User engagement is of the highest importance in today’s world, no matter what you sell or offer to your clients. And mobile phone notifications play the masterstroke in this aspect. By regular interactions with your clients through push notifications, it is possible to release timely updates and stay connected with them. So, let us discuss setting up an Apple push notification service (APN) with a Node.js application today.

In this blog, we will discuss in detail the APN services, enable and register for remote notifications, device token ids, and APN node package with the help of a sample iOS. Make sure to have a physical iOS device, as push notifications won’t work with the simulator. Also, an Apple Developer Program Membership account is a must for creating a Push Notifications Certificate.

Getting to know about the Remote Notification Service

Apple devices use a remote notification service to send and receive notifications in any of the iOS, tvOS, or macOS. The remote notification setup is to be configured in your Apple device with proper device tokens and certificates. Otherwise, there are possibilities that the notification services don’t work as expected. 

The main component of this remote notification setup is the Apple Push Notification service, also known as APNs. APN in actuality is a collection of services that allows the developer to send the notifications from their server to the targeted iOS devices. The APNs are robust and secure methods to establish a connection between the provider server and individual Apple devices. 

APN contains two components, the Gateway component, and the Feedback component, both of which are must-haves. 

Gateway component establishes the TLS connection from a provider side which enables the provider server to send messages to the Apple, which will be processed by Apple and then forwarded to the respective device. It is recommended to keep the connection in an ‘always-on’ mode. The Feedback Component is established only occasionally to identify and remove the devices which no longer receive notifications for specific applications. This is a mandatory component in any Apple device.

To receive and handle the remote notifications, the app you provide must have four components as basics. They are:

1. Remote connection enabled
2. A registered Apple Push Notification Service (APN) and device token
3. Sending device token to the notification provider
4. Establish support to handle incoming notifications in the device

Once the push notification setup is complete in your apps and the provider server-side, the providers can send notification requests to APNs. they convey the notification payloads to each targeted device. As the notification is received, the payload is delivered to the respective app and user communications are managed. It is great to note that the APNs hold the notifications if the device is powered off and waits till the device turns power on while trying multiple times to deliver the message to the appropriate app in the device. This makes it perfect for the user and the provider not to miss any important communication.

It is good to have a clear and strong understanding of the APNs, direct from Apple’s guides.

The provider is entitled to many responsibilities. Some of the major ones are below:

• Receive globally unique, app-specific device tokens and all relevant data pertaining to your app on user’s devices.
• Determine when the remote notifications are to be sent to each device.
• Building and sending notification requests to APNs.

Only with proper entitlements to talk to APNs, can the app handle the remote notifications. Without these entitlements, the apps are rejected by the App Store. Know the details of entitlements required for your app in the ‘Enable push notification’section of the Xcode Help page on Apple’s website. Once notification pushes are enabled, app registration is a must every time the app is launched. The process of app registering includes the below steps, for all Apple devices.

• Your app asks to be registered with APNs
• APNs sends app-specific device tokens
• The system delivers the device to your app by calling a method in your app delegate
• The device token is shared with the app’s associated provider 

A method registerForRemoteNotificationsis called at the launch time by your app. This initiates the app object to contact APN for app-specific device tokens. Below code shows how to fetch your device token:

Swift:

Know more about the Remote and Local notificationson Apple’s page.

Thus, the system establishes an encrypted and persistent IP connection between the app and APNS, whenever the app starts on a device. This connection setups and enables the device to receive notifications, thus requires configuration on the Apple development account and necessary certificate creation.

For our servers to communicate with the APNs, a lot of connections and configurations are to be done in Node.js. It is easier to opt for the apn packages with preset code to establish error-free connections. This ready-to-use package is one good choice for the production environment. The package is based on HTTP/2 API and is capable of maximizing the processing and notification delivery. It also collects the not-sent notifications when an error has occurred. The official repository of the apn packagewill gives a better understanding of this topic.

Creating Certificates

One main step in setting up the notification services is the certificate creation, specific to your app and device. This certificate tells the APN that our server has legal permissions to send and receive notifications of our app. That means the SSL certificate establishes a secure connection with the APNs. The certificate for our is created by us and is specific to our app alone.

Proceed with the below steps to create a certificate:

1. Open the project from Xcode, and select the Capabilities tab from Target.
2. Enable Push Notification switch and wait for automatic configuration to be completed.
3. In the developer center, search for our app in our developer account. Tap Edit.
4. Open the Push Notification section on this screen.
5. Open ‘Create Certificate’ in the Development SSL Certificate tab
6. Follow the procedure in the upcoming steps on the screen to create a certificate. The certificate will be ready for download once created successfully.
7. Download the certificate aps_development.cer.
8. Select the certificate and private key from the list and export a p12 file. Type in the password and note to remember the newly created password as it will be needed by Apple to send push notifications.

Obtaining device token

In the above section, we saw the general code to fetch device tokens. Let us consider a scenario-specific code that we can further use for Node.js script creation.

Our sample app is titled SimplRTApp. We need to identify the device tokens to push notifications from the sample app. So, to get the device token, add the following methods on our AppDelegate.swift.

View the raw code for the below snippets in the github library.

Also, check the final app code for SimpleRTAppfor further details.

The Node.js Script Creation

We now have a p12 file to establish a secure connection with the APNs and a device token to send push notifications to this device from our SimpleRTApp. All we need now is to create our program on Node.js and test the push notifications.

To create the Node.js script:

1. Open the terminal app.
2. Need to install the module that handles APN connections. For that, type npm install apn. 
3. Copy or save the p12 file to the folder same as that of our Node.js script.
4. Create the below script(available from Github).

In the script, the <device-token> and <p12-password> are replaced by the values specific to our app. The above script does the following to set up a real-time push notification when triggered.

• Establish the connection
• Instate the provider object
• Create Notification and send with the send() method
• Finish execution when there is a response for either success or error scenario

With the above script, the push notification setup is complete. Now is the time to test the script. For testing, type node send_push.js in the terminal and wait for the notification to arrive in the mentioned Apple device.

Complete script for the push notification service in check in the GitHub and is available for your reference. 

It is a good practice to include a custom action with the notifications. It allows the user to communicate quickly with a proper preset response. Examples for custom actions include the ‘Reply’ or ‘Mark as read’ button in a message notification, ‘Install’ or ‘Snooze’ options in an OS update notification, etc. in our case, one easy and simple custom action would be ‘Retweet’.

Simple edits on the Node.js code shared above will enable these custom actions. Let’s see how to proceed.

While setting the notification object, include below:

Also, to let the iOS app know it is an allowed action with the below code:

Thus, for our AppDelegate.swift, the script would be as follows:

Conclusion

As we come to the end of this blog, we have discussed all the below points in detail 

• The remote notifications
• APNs
• Certificate creation
• Fetching Device tokens
• Node.js code for delivering push notification

The post Sending iOS Push Notifications via APNs appeared first on EngineYard.

User engagement is of the highest importance in today’s world, no matter what you sell or offer to your clients. And mobile phone notifications play the masterstroke in this aspect. By regular interactions with your clients through push notifications, it is possible to release timely updates and stay connected with them. So, let us discuss setting up an Apple push notification service (APN) with a Node.js application today.

In this blog, we will discuss in detail the APN services, enable and register for remote notifications, device token ids, and APN node package with the help of a sample iOS. Make sure to have a physical iOS device, as push notifications won’t work with the simulator. Also, an Apple Developer Program Membership account is a must for creating a Push Notifications Certificate.

Getting to know about the Remote Notification Service

Apple devices use a remote notification service to send and receive notifications in any of the iOS, tvOS, or macOS. The remote notification setup is to be configured in your Apple device with proper device tokens and certificates. Otherwise, there are possibilities that the notification services don’t work as expected. 

The main component of this remote notification setup is the Apple Push Notification service, also known as APNs. APN in actuality is a collection of services that allows the developer to send the notifications from their server to the targeted iOS devices. The APNs are robust and secure methods to establish a connection between the provider server and individual Apple devices. 

APN contains two components, the Gateway component, and the Feedback component, both of which are must-haves. 

Gateway component establishes the TLS connection from a provider side which enables the provider server to send messages to the Apple, which will be processed by Apple and then forwarded to the respective device. It is recommended to keep the connection in an ‘always-on’ mode. The Feedback Component is established only occasionally to identify and remove the devices which no longer receive notifications for specific applications. This is a mandatory component in any Apple device.

To receive and handle the remote notifications, the app you provide must have four components as basics. They are:

1. Remote connection enabled
2. A registered Apple Push Notification Service (APN) and device token
3. Sending device token to the notification provider
4. Establish support to handle incoming notifications in the device

Once the push notification setup is complete in your apps and the provider server-side, the providers can send notification requests to APNs. they convey the notification payloads to each targeted device. As the notification is received, the payload is delivered to the respective app and user communications are managed. It is great to note that the APNs hold the notifications if the device is powered off and waits till the device turns power on while trying multiple times to deliver the message to the appropriate app in the device. This makes it perfect for the user and the provider not to miss any important communication.

It is good to have a clear and strong understanding of the APNs, direct from Apple’s guides.

The provider is entitled to many responsibilities. Some of the major ones are below:

• Receive globally unique, app-specific device tokens and all relevant data pertaining to your app on user’s devices.
• Determine when the remote notifications are to be sent to each device.
• Building and sending notification requests to APNs.

Only with proper entitlements to talk to APNs, can the app handle the remote notifications. Without these entitlements, the apps are rejected by the App Store. Know the details of entitlements required for your app in the ‘Enable push notification’section of the Xcode Help page on Apple’s website. Once notification pushes are enabled, app registration is a must every time the app is launched. The process of app registering includes the below steps, for all Apple devices.

• Your app asks to be registered with APNs
• APNs sends app-specific device tokens
• The system delivers the device to your app by calling a method in your app delegate
• The device token is shared with the app’s associated provider 

A method registerForRemoteNotificationsis called at the launch time by your app. This initiates the app object to contact APN for app-specific device tokens. Below code shows how to fetch your device token:

Swift:

Know more about the Remote and Local notificationson Apple’s page.

Thus, the system establishes an encrypted and persistent IP connection between the app and APNS, whenever the app starts on a device. This connection setups and enables the device to receive notifications, thus requires configuration on the Apple development account and necessary certificate creation.

For our servers to communicate with the APNs, a lot of connections and configurations are to be done in Node.js. It is easier to opt for the apn packages with preset code to establish error-free connections. This ready-to-use package is one good choice for the production environment. The package is based on HTTP/2 API and is capable of maximizing the processing and notification delivery. It also collects the not-sent notifications when an error has occurred. The official repository of the apn packagewill gives a better understanding of this topic.

Creating Certificates

One main step in setting up the notification services is the certificate creation, specific to your app and device. This certificate tells the APN that our server has legal permissions to send and receive notifications of our app. That means the SSL certificate establishes a secure connection with the APNs. The certificate for our is created by us and is specific to our app alone.

Proceed with the below steps to create a certificate:

1. Open the project from Xcode, and select the Capabilities tab from Target.
2. Enable Push Notification switch and wait for automatic configuration to be completed.
3. In the developer center, search for our app in our developer account. Tap Edit.
4. Open the Push Notification section on this screen.
5. Open ‘Create Certificate’ in the Development SSL Certificate tab
6. Follow the procedure in the upcoming steps on the screen to create a certificate. The certificate will be ready for download once created successfully.
7. Download the certificate aps_development.cer.
8. Select the certificate and private key from the list and export a p12 file. Type in the password and note to remember the newly created password as it will be needed by Apple to send push notifications.

Obtaining device token

In the above section, we saw the general code to fetch device tokens. Let us consider a scenario-specific code that we can further use for Node.js script creation.

Our sample app is titled SimplRTApp. We need to identify the device tokens to push notifications from the sample app. So, to get the device token, add the following methods on our AppDelegate.swift.

View the raw code for the below snippets in the github library.

Also, check the final app code for SimpleRTAppfor further details.

The Node.js Script Creation

We now have a p12 file to establish a secure connection with the APNs and a device token to send push notifications to this device from our SimpleRTApp. All we need now is to create our program on Node.js and test the push notifications.

To create the Node.js script:

1. Open the terminal app.
2. Need to install the module that handles APN connections. For that, type npm install apn. 
3. Copy or save the p12 file to the folder same as that of our Node.js script.
4. Create the below script(available from Github).

In the script, the <device-token> and <p12-password> are replaced by the values specific to our app. The above script does the following to set up a real-time push notification when triggered.

• Establish the connection
• Instate the provider object
• Create Notification and send with the send() method
• Finish execution when there is a response for either success or error scenario

With the above script, the push notification setup is complete. Now is the time to test the script. For testing, type node send_push.js in the terminal and wait for the notification to arrive in the mentioned Apple device.

Complete script for the push notification service in check in the GitHub and is available for your reference. 

It is a good practice to include a custom action with the notifications. It allows the user to communicate quickly with a proper preset response. Examples for custom actions include the ‘Reply’ or ‘Mark as read’ button in a message notification, ‘Install’ or ‘Snooze’ options in an OS update notification, etc. in our case, one easy and simple custom action would be ‘Retweet’.

Simple edits on the Node.js code shared above will enable these custom actions. Let’s see how to proceed.

While setting the notification object, include below:

Also, to let the iOS app know it is an allowed action with the below code:

Thus, for our AppDelegate.swift, the script would be as follows:

Conclusion

As we come to the end of this blog, we have discussed all the below points in detail 

• The remote notifications
• APNs
• Certificate creation
• Fetching Device tokens
• Node.js code for delivering push notification

The post Sending iOS Push Notifications via APNs appeared first on EngineYard.

Ruby on Rails (RoR) is open-source, well-documented, fiercely maintained, and constantly extended with new Gems — community-created open-source libraries, serving as “shortcuts” for standardized configuration and distribution of Ruby code.

Rails is arguably the biggest RoR gem of them all — a full-stack server-side web application framework that is easy to customize and scale.

What is Rails? A Quick Refresher

Rails was built on the premises of Model-View-Controller (MVC) architecture.

This means each Rails app has three interconnected layers, accountable for a respective set of actions:

1. Model: A data layer, housing the business logic of the app
2. Controller: The “brain center”, handling application functions
3. View: Defines graphical user interfaces (GUIs) and UI performance

In essence, the model layer establishes the required data structure and contains codes needed to process the incoming data in HTML, PDF, XML, RSS, and other formats. The model layer then communicates updates to the View, which updates the GUI. The controller, in turn, interacts both with models and views. For instance, when receiving an update from a view, it notifies the model on how to process it. At the same time, it can update the view too on how to display the result for the user.

(Basic Rails app architecture. Image source: Medium)

The underlying MVC architecture lends several important advantages to Rails:

• Parallel development capabilities — one developer can work on View, while others handle the model subsystem. The above also makes Ruby on Rails a popular choice for rapid application development (RAD) methodology.
• Reusable code components — controllers, views, and models can be packaged to share and reuse across several features with relative ease. When done right, this results in cleaner, more readable code, as well as faster development timelines. Also, Ruby on Rails is built on the DRY principle (don’t repeat yourself), prompting more frequent code reuse for monotonous functions.
• Top security — the framework has a host of built-in security-centric features such as protection against SQL injections and XSS attacks, among others. Moreover, there’s plenty of community-shipped gems addressing an array of common and emerging cybersecurity threats.
• Strong scalability potential — there’s a good reason why jumbo-sized web apps such as GitHub, Twitch, and Fiverr are built on Rails. Because it scales well when the overall app architecture and deployment strategy are done right. In fact, one of the oldest Rails apps, Shopify, scales to processing millions of requests per minute (RPM).

In spite of this, many Rails guides still make the arbitrary claim that Rails apps are hard to scale.  Are these true? Not entirely, as this post will showcase.

3 Common Problems With Scaling Rails Apps

The legacy lore once told that scaling Rails apps is like passing a camel through the eye of a needle — exasperating and exhausting.

To better understand where these concerns are coming from, let’s first recap what scalability is for web apps.

Scalability indicates the application’s architectural capability to handle more user requests per minute (RPM) in the future.

The keyword here is “architecture”, as your choices of infrastructure configuration, connectivity, and overall layout are determinants to the entire system’s ability to scale. The framework(s) or programming languages you use will only have a marginal (if any) impact on the scalability.

In the case of RoR, developers, in fact, get a slight advantage as the framework promotes clean, modular code that is easy to integrate with more database management systems. Moreover, adding load balancers for processing a higher number of requests is relatively easy too.

Yet, the above doesn’t fully eradicate scaling issues on Rails. Let’s keep it real: any app is hard to scale when the underlying infrastructure is subpar.

Specifically, Ruby scaling issues often pop up due to:

• Poor database querying
• Inefficient indexing
• Lack of logging and monitoring
• Subpar database engine selection
• Sluggish caching
• Overly complex and spaghetti code

Over-Engineered App Architecture

RoR supports multi-threading. This means the Rails framework can handle concurrent processing of different parts of code.

On the one hand, multi-threading is an advance since it enables you to use CPU time wiser and ship high-performance apps.

At the same time, however, the cost of context switching between different threads in highly complex apps can get high. Respectively, performance starts lagging at some point.

How to Cope

By default, Ruby on Rails prioritizes clean, reusable code. Making your Rails app architecture overly complex (think too custom) indeed can lead to performance and scalability issues.

This was the case with Twitter circa 2007.

The team developed a Twitter UI prototype on Rails and then decided to further code the back-end on Rails too. And they decided to build a fully custom, novel back-end from scratch rather than modifying some tested components. Unsurprisingly, their product behaved weirdly and times and scaling it was challenging, as the team admitted in a presentation. They ended up with a ton of issues when partitioning databases because their code was overly complex and bloated.

Image Source: SlideShare

Interestingly, at the same time, another high-traffic Rails web app called Penny Arcade was doing just fine. Why? Because it had no funky overly-custom code, had clearly mapped dependencies, and hailed well with connected databases.

Remember: Ruby supports multi-processing within apps. In some cases, multi-process apps can perform better than multi-thread ones. But the trick with processes is that they consume more memory and have more complex dependencies. If you inadvertently kill a parent process, children processes will not get informed about the termination and thus, turn into sluggish “zombie” processes. This means they’ll keep running and consume resources. So watch out for those!

Suboptimal Database Setup

In the early days, Twitter had intensive write workloads and poorly organized read patterns, which were non-compatible with database sharding.

At present, a lot of Rails developers are still skimming on coding proper database indexes and triple-checking all queries for redundant requests. Slow database queries, lack of caching, and tangled database indexes can throw any good Rails app off the rails (pun intended).

Sometimes, complex database design is also part of deliberate decisions, as was the case with one of our clients, PennyPop. To store app data, the team set up an API request to the Rails application. The app itself then stores the data inside DynamoDB and sends a response back to the app. Instead of ActiveRecord, the team created their own data storage layer to enable communication between the app and DynamoDB.

But the issue they ran into is that DynamoDB has limits on how much information can be stored in one key. This was a technical deal-breaker, but the dev team came up with an interesting workaround — compressing the value of the key to a payload of base64 encoded data. Doing so has allowed the team to exchange bigger records between the app and the database without compromising the user experience or app performance.

Sure, the above operation requires more CPU. But since they are using Engine Yard to help manage and optimize other infrastructure, these costs remain manageable.

How to Cope

Granted, there are many approaches to improving Rails database performance. Deliberate caching and database partitioning (sharding) is one of the common routes as your app grows more complex.

What’s even better is that you have a ton of great solutions for resolving RoR database issues, such as:

• Redis — an open-source in-memory data structure store for Rails apps.
• ActiveRecord — a database querying tool standardizing access to popular databases with built-in caching capabilities.
• Memcached — distributed memory caching system for Ruby on Rails.

The above three tools can help you sufficiently shape up your databases to tolerate extra-high loads.

Moreover, you can:

• Switch to UUIDs over standard IDs for principle keys as your databases grow more complex.
• Try other ORM alternatives to ActiveRecord when your DBs get extra-large. Some good ones include Sequel, DataMapper, and ORM Adapter.
• Use database profiling gems to diagnose and detect speed and performance issues early on. Popular ones are rack-mini-profiler, bullet, rails_panel, etc.

Insufficient Server Bandwidth

The last problem is basic but still pervasive. You can’t accelerate your Rails apps to millions of RPMs if you lack resources.

Granted, with cloud computing, provisioning extra instances is a matter of several clicks. Yet, you still need to understand and account for:

• Specific apps/subsystems requirements for extra resources
• Cloud computing costs (aka the monetary tradeoff for speed)

Ideally, you need tools to constantly scan your systems and identify cases of slow performance, resources under (and over)-provisioning, as well as overall performance benchmarks for different apps.

Not having such is like driving without a speedometer: You rely on a hunch to determine if you are going too slow or deadly fast.

How to Cope

One of the lessons we learned when building and scaling Engine Yard on Kubernetes was that the container platform sets no default resource limits for hosted containers. Respectively, your apps can consume unlimited CPU and memory, which can create “noisy neighbor” situations, where some apps rack up too many resources and drag down the performance of others.
The solution: Orchestrate your containers from the get-go. Use Kubernetes Scheduler to right-size nodes for the pods, limit maximum resource allocation, plus define pod preemption behavior.

Moreover, if you are running containers, always set up your own logging and monitoring since there are no out-of-the-box solutions available. Adding Log Aggregation to Kubernetes provides extra visibility into your apps’ behavior.

In our case, we use:

• Fluent Bit for distributed log collection
• Kibana + Elasticsearch for log analysis
• Prometheus + Grafana for metrics alerting and visualization

To sum up: The key to ensuring scalability is weeding out the lagging modules and optimizing different infrastructure and architecture elements individually for a greater cumulative good.

Scaling Rails Apps: Two Main Approaches

Similar to others, Rails apps scale in two ways — vertically and horizontally.

Both approaches have their merit in respective cases.

Vertical Scaling

Vertical scaling, i.e., provisioning more server resources to an app, can increase the number of RPMs. The baseline premises are the same as for other frameworks. You add extra processors, RAM, etc., until it is technically feasible and makes financial sense. Understandably, vertical scaling is a temp “patch” solution.

Scaling Rails apps vertically makes sense to accommodate linear or predictable growth since cost control will be easy too. Also, vertical scaling is a good option for upgrading database servers. After all, slow databases can be majorly accelerated when placed on better hardware.

Hardware is the obvious limitation to vertical scaling. But even if you are using cloud resources, still scaling Rails apps vertically can be challenging.

For example, if you plan to implement Vertical Pod Autoscaling (VPA) on Kubernetes, it accounts for several limitations.

During our experiments with scaling Ruby apps, we found that:

• VPA is a rather disruptive method since it busts the original pod and then recreates its vertically scaled version. This can cause much havoc.
• You cannot pair VPA with Horizontal Pod Autoscaling.

So it’s best to prioritize horizontal scaling whenever you can.

Horizontal Scaling

Horizontal scaling, i.e., redistributing your workloads across multiple servers, is a more future-proof approach to scaling Rails apps.

In essence, you convert your apps in a three-tier architecture featuring:

• Web server and load balancer for connected apps
• Rails app instances (on-premises or in the cloud)
• Database instances (also local or cloud-based)

The main idea is to distribute loads across different machines to obtain optimal performance equitably.

To effectively reroute Rails processes across server instances, you must select the optimal web server and load balancing solution. Then right-size instances to the newly decoupled workloads.

Load balancing 

Load balancers are the key structural element for scale-out architecture. Essentially, they perform a routing function and help optimally distribute incoming traffic across connected instances.

Most cloud computing services come with native software load balancing solutions (think Elastic Load Balancing on AWS). Such solutions also support dynamic host port mapping. This helps establish a seamless pairing between registered web balancers and container instances.

When it comes to Rails apps, the two most common options are using a combo of web servers and app servers (or a fusion service) to ensure optimal performance.

• Web servers transfer the user request to your website and then pass it to a Rails app (if applicable). Essentially, they filter out unnecessary requests for CSS, SSL, or JavaScript components (which the server can handle itself), thus reducing the number of requests to the Rails app to bare essentials.

– Examples of Rails web servers: Ngnix and Apache.

• App servers are programs that maintain your app in memory. So that when an incoming request from a web server apps appears, it gets routed straight to the app for handling. Then the response is bounced back to the web server and, subsequently, the user. When paired with a web server in production, such a setup lets you render requests to multiple apps faster.

– Examples of app servers for Rails: Unicorn, Puma, Thin, Rainbows.

Finally, there are also “fusion” services such as Passenger App (Phusion Passenger). This service integrates with popular web servers (Ngnix and Apache) and brings in an app server layer — available for standalone and combo use with web servers.

Image Source: Phusion Passenger

Passenger is an excellent choice if you want to roll out unified app server settings for a bunch of apps in one go without fiddling with a separate app server setup for each.

In a nutshell, the main idea behind using web and app servers is to span different rails processes optimally across different instances.

Pro tip: What we found when building our product is that AWS Elastic Load Balancer often doesn’t suffice. A major drawback is that ELB can’t handle multiple vhosts.

In our case, we went on with configuring an NGINX-based load balancer and configured auto-scaling on it to support ELB. As an alternative, you can also try HAProxy.

App Instances 

The next step of scale-out architecture is configuring communication between different app instances, where your Rails workloads will be allocated.

App servers (Unicorn, Puma, etc.) help ensure proper communication between web servers and subsequently increase the throughput of requests processed per second. On Rails, you can allocate an app server to handle multiple app instances, which in turn can have separate “worker” processes or threads (depending on which type of app server service you are using).

It’s important, however, to ensure that different app servers can communicate well with the webserver. Rack interface comes in handy here as it helps homogenize communication standards between standalone app servers.

When it comes to configuring the right instances for containers, keep in mind the following:

1. You have four variables to min/max CPU and min/max memory to regulate pod size
2. Limit the resources using [minimum requirement + 20%] formula
3. Use average CPU utilization and average memory utilization as scaling metrics
4. Mind the timing. Pods and clusters take 4 to 12 minutes to scale up on Kubernetes.

P.S. If you don’t want to do the above guesswork every time you are building a new pod/cluster, Engine Yard comes with a predictive cluster scaling feature, which helps you scale your infrastructure just-in-time without ballooning the costs.

Database Scaling

Transferring databases to a separate server, used by all app instances, is one of the sleekest moves you can do to scale Rails apps.

First of all, this can be a nice exercise in segregating your data and implementing database replication for improving business continuity. Secondly, doing so can reduce the querying time since the request will not have to travel through multiple database instances where different bits of data are stored. Instead, it will go straight to a consolidated repository.

Thus, consider setting up a dedicated MySQL or PostgreSQL server for your relational databases. Then scrub them clean and ensure optimal instance size to save costs.

For example, AWS RDC lets you select among 18 types of database instances and codify fine-grain provisioning. Choosing to host your data in a cheaper cloud region can drive substantial cost savings (up to 40% at times!).

Here’s how on-demand hourly costs differ across AWS regions:

US East (Ohio)

• db.t3.small — $0.034 per hour
• db.t3.xlarge — $0.272 per hour
• db.t3.2xlarge — $0.544 per hour

US West (LA)

• db.t3.small — $0.0408 per hour
• db.t3.xlarge —$0.3264 per hour
• db.t3.2xlarge — $0.6528 per hour

Europe (Frankfurt)

• db.t3.small — $0.04 per hour
• db.t3.large — $0.16 per hour
• db.t3.2xlarge — $0.64 per hour

Asia Pacific (Seoul)

• db.t3.small —$0.052 per hour
• db.t3.large — $0.208 per hour
• db.t3.2xlarge — $0.832 per hour

Another pro tip: opt for reserved instances over on-demand when you can to further slash the hourly costs.

Caching

Database caching implementation is another core step to accelerating your Rails apps, especially when it comes to database performance. Given the fact that RoR comes with a native query caching feature that caches the result set returned by each query, it’s a shame not to profit from this!

Caching can help you speed up those slow queries. But prior to implementing, investigate! Once you’ve found the “offenders”, consider trying out different strategies such as:

• Low-level caching — works best for any type of caching to retrieve database queries.
• Redis cache store — lets you store keys and value pairs up to 512 MB in memory, plus provides native data replication.
• Memcache store — another easy-to-implement in-memory datastore with values limited at 1 MB. Supports multi-thread architecture, unlike Redis.

Ultimately, caching improves data availability and, by proxy, your application’s querying speed and performance.

Database sharding

Lastly, at some point in your database scaling journey, you’ll inevitably face the decision to shard your relational databases.

Data sharding means slicing your DB records horizontally or vertically into smaller chunks (shards) and storing them on a cluster of database nodes. The definitive advantage is that querying should now happen faster since a large database gets split in two and has twice more memory, I/O, and CPU to run.

The tradeoff, however, is that sharding can significantly affect your app’s logic. The scope of each query is now limited to either DB 1 or DB 2 — there’s no commingling. Respectively, when adding new app functions, you need to carefully consider how to access data across shards, how sharing relates to the infrastructure, and what’s the best way to scale out the supporting infrastructure without affecting the app’s logic.

To Conclude: Is There An Easier Solution to Scaling Rails Apps?

Scaling Rails apps is a careful balancing act of ensuring optimal instance allocation, timely resource, provisioning, and careful container orchestration. Keeping tabs on all the relevant metrics across a portfolio of apps and sub-services isn’t an easy task when done manually. And it shouldn’t be.

You can try Engine Yard Kontainers (EYK) — our NoOps PaaS autoscaling services for containerized apps. In essence, we act as your invisible DevOps team. You code your apps and deploy them to EYK, and we take over auto-scaling implementation, container orchestration, and other infrastructure right-sizing tasks from there.

Learn more about Engine Yard.

The post The Developers Guide To Scaling Rails Apps appeared first on EngineYard.