Thursday, 7 June, 2018 UTC


Summary

Heroku, meet Fly. Fly, meet Heroku.
Heroku is a hosting platform that lets you build, deliver, monitor and scale apps... basically a cloud container to run your code from. Whereas Fly is a programmable CDN that makes your applications fast and gives developers powerful caching, content modification, and routing tools.
Ok, now that we're past introductions, lets understand how these two new friends can work together to deliver fast, scalable apps - all while monitoring performance and speed.
How did these two meet?
Heroku allows you to run applications written using a variety of frameworks and languages. The unique feature of Heroku that makes it dynamic and powerful is the concept of Buildpacks, which are little bits of logic + instruction that let you influence exactly how your app is compiled and built. Essentially, buildpacks give you the freedom to do whatever you want with Heroku's building blocks, such as coding in the languages and frameworks that work best for your app.
Basically, buildpacks are scripts that run when your app is deployed - building your app and assembling the runtime environment. They are used to install dependencies for your app and configure your environment. Some of the most common buildpacks include Ruby, Node.js, Python and Java. The neat thing about Heroku is that you can specify a custom buildpack for your app, which can be used to support a variety of languages or frameworks - enter Fly.
Fly Heroku Buildpack allows you to connect any Heroku app to the Fly.io network. You can set the buildpack of your application when you create it…
heroku create –-buildpack https://github.com/superfly/fly-heroku-buildpack
The problem with Heroku alone?
Heroku is location specific. You deploy code and it runs in Ashburn, Virginia. When users type your URL into their address bar, they stroll through the large and mighty world wide web trying to connect to your app. This leisurely stroll causes an unpleasant delay in response time.
Fly Edge Apps work to cache HTTP content. We have servers all over the world, we distribute your code to them and your users connect to whichever is closest to them.
Generally speaking, your app is hosted on Heroku and delivered by Fly's speedy delivery network. Why would we do this, you ask? Well, look at it this way. Heroku's central server acts as the hub for all communication and information storage. This leaves way for you to write JavaScript to enhance the delivery of your app by caching partials close to your users and optimizing content as it gets shipped to users.
How do Fly and Heroku work together to deliver an app?
In mostly English, this is how Fly and Heroku work together to deliver your app to your users...
Every time you push your app to Heroku, the slug compiler uses your buildpack to make a bunch of transformations to your app and compresses it into a slug, which is basically an archive that includes your app's code and all of its dependencies. The slug then gets downloaded, extracted into the corresponding dyno (which are really just virtual computers that can be powered up or down based on how big your application is) and started up.
Heroku also generates a Procfile, which lists all of the executable processes that your application uses. Once your app is set-up on Fly, you can stop the ingress traffic to your dyno by changing the process name in the Procfile from web to something else.
There are three events that take place when Heroku turns your application code into a slug using the Buildpack...

Stage 1: Detect

Heroku runs bin/detect from the buildpack, where the buildpack attempts to find out whether it can process the application. If you specified a buildpack during creation, that is the one that will be used.
git push heroku master 
Counting objects: 3, done. 
Delta compression using up to 4 threads. 
Compressing objects: 100% (3/3), done. 
Writing objects: 100% (3/3), 309 bytes | 309.00 KiB/s, done. 
Total 3 (delta 2), reused 0 (delta 0) 
remote: Compressing source files... done. 
remote: Building source: 
remote:  
remote: -----> Fly agent app detected 

Stage 2: Compile

Next, the slug compiler runs bin/compile, where the buildpack will download dependencies, launch tasks, and generally make everything needed to "compile" the application into a self-contained artifact. Buildpacks are cool because you can basically do whatever you what in the compile step.
remote: -----> Installing Fly Agent 
remote: -----> Writing .profile.d/fly.sh 
remote: -----> Discovering process types 
remote:        Procfile declares types -> (none) 
remote:  
remote: -----> Compressing... 
remote:        Done: 32.2M 
remote: -----> Launching... 

Stage 3: Release

After the compilation step is done, Heroku runs a script named bin/release, which is used to set environment variables and other things needed by the application to run.
remote:        Released v5 
remote:        https://best-friends-19630.herokuapp.com/ deployed to Heroku 
remote:  
remote: Verifying deploy... done. 
To https://git.heroku.com/best-friends-19630.git 
   9e6500c..a7edcf3  master -> master 
How to set up Fly Heroku Buildpack
Initialize git for your app, add the changes and perform a commit.
git init 
git add . 
git commit -m "first commit" 
Create a Heroku app specifying the fly-heroku-buildpack and push to Heroku.
heroku create --buildpack=https://github.com/superfly/fly-heroku-buildpack 
Creating app... done, ⬢ best-friends-19630 
Setting buildpack to https://github.com/superfly/fly-heroku-buildpack... done 
https://best-friends-19630.herokuapp.com/ | https://git.heroku.com/best-friends-19630.git 
Add a new back end https://fly.io/sites/new and configure it with your auth token https://fly.io/user/personal_access_tokens.
heroku config:set FLY_TOKEN=<TOKEN_FOR_YOUR_BACKEND> 
Setting FLY_TOKEN and restarting ⬢ best-friends-19630... done, v4 
FLY_TOKEN: <TOKEN_FOR_YOUR_BACKEND> 
Deploy your changes: git push heroku master .
If your Heroku app already exists, add Fly Heroku Buildpack like this:
heroku buildpacks:add https://github.com/superfly/fly-heroku-buildpack 
heroku config:set FLY_TOKEN=<TOKEN_FOR_YOUR_BACKEND> 
git push heroku master 
In summary, Heroku detected a Fly app, compiled it based on the set of instructions in /bin/compile and released. Aha! Your Fly back end should now be proxying traffic to your Heroku app and on your Heroku dashboard you will see the Framework is set to: Fly agent.
Why is this cool?
A large component of web usability is speed and page load time. While writing clean and efficient code is important, there are other improvements that can be made to your app to dramatically speed up page loads.
Using Fly in combination with Heroku makes it easy and fast to host an app and deliver it to your users. By using Fly's Application Delivery Network to deliver your Heroku app, your app is served with low latency and high transfer speeds.
Using an Application Delivery Network (ADN), such as Fly, to optimize the delivery of static assets on your site allows you to remove all requests for these static assets from your web dynos, which in turn will free those dynos to handle more requests for dynamic content... increasing delivery speeds and reliability.