Javascript

How to deploy a NodeJS application using Fly.io

Published Dec 7, 2021

Updated Feb 13, 2023

4 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

I was astounded when I learned just how easy it is to deploy static web applications. Services like AWS Amplify, Netlify, GitHub Pages, etc, trivialize this process, allowing developers to focus less on deployment, and more on feature development.

I was equally astounded when I learned that it can be JUST AS EASY to deploy a web service! There are many options out there:

This guide is going to be focused on a solution that I have found to be incredibly developer-friendly platform, Fly.io.

What is Fly.io?

Deploy App Servers Close to Your Users

Run your full-stack apps (and databases!) all over the world. No ops required.

Fly.io claims to be able to run full-stack apps with no ops required. That's a bold statement. While I've committed to plenty of PR's, I haven't deployed a web service in a while. I was feeling the itch to deploy a service to play around with some different languages in the backend, so I was 100% in the market for a developer-friendly way to get this done, with quite literally no ops hopefully required.

Fly.io App Deployment Speed-run

The last time I personally deployed a brand new web service was months and months ago, on a DigitalOcean droplet. My usual go-to solution for web apps are static web apps, so I'm used to deploying static assets.

Fly.io has a particular portion of their documentation which immediately drew my attention: their Speedrun section.

Before deciding to write this blog, I figured, I'd at least try out their service, and if I enjoyed it, I'd write about it. Holy moly was I shocked just how easy Fly.io made deployment. After about 15 minutes from landing on their documentation, I was able to deploy a web service, complete with GitHub Actions CI/CD. And I didn't even need to touch a server!

Here is how you can do the same.

I created an incredibly terse ExpressJS app using TypeScript.

Install flyctl: The root URL for Fly.io has a one line command you can use to install flyctl, the command line tool which handles deployment for you. For detailed instructions though, check out this page.
Sign up / Log in: Sign up or Log in using the appropriate command, flyctl auth signup or flyctl auth login.
Run flyctl launch: This will prompt you to name your application, select a region to deploy to, and then deploy your app. This generates a fly.toml config file with the deployment configurations.

In those three steps, you too can launch a sample express app.

CI/CD

Adding CI/CD is as simple as adding a single file to the repo, along with retrieving and adding an API token to the repo.

Add the following to .github/workflows/main.yml

name: Fly Deploy
on: [push]
env:
  FLY_API_TOKEN: ${{ secrets.FLY_API_TOKEN }}
jobs:
  deploy:
    name: Deploy app
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: superfly/flyctl-actions@1.1
        with:
          args: "deploy"

Then run flyctl auth token to generate and print an API token, then add it to the repo as a new secret named FLY_API_TOKEN.

That is all you need to continuously deploy your NodeJS application on every commit!

Conclusion

Using Fly.io honestly felt like cheating. I remember being super proud of myself when I first deployed a full LAMP stack application on a VPS. I also clearly remember the pain of troubleshooting things like SSH, CertBot and LetsEncrypt, Nginx, etc.

Fly.io completely trivialized the entire process. I easily see myself using this going forward for all containerized applications since the service even includes the means for auto-scaling your apps and containers!!!

If you are a developer and you are not shy of the command-line, I highly recommend checking out Fly.io and spending 15 minutes of your time, just deploying a service. You'll be shocked at just how quick and easy it can be to go from 0 to CI/CD in mere moments.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Matthew Pagan
@mastapegs @mastapegs

Testing a Fastify app with the NodeJS test runner

Introduction Node.js has shipped a built-in test runner for a couple of major versions. Since its release I haven’t heard much about it so I decided to try it out on a simple Fastify API server application that I was working on. It turns out, it’s pretty good! It’s also really nice to start testing a node application without dealing with the hassle of installing some additional dependencies and managing more configurations. Since it’s got my stamp of approval, why not write a post about it? In this post, we will hit the highlights of the testing API and write some basic but real-life tests for an API server. This server will be built with Fastify, a plugin-centric API framework. They have some good documentation on testing that should make this pretty easy. We’ll also add a SQL driver for the plugin we will test. Setup Let's set up our simple API server by creating a new project, adding our dependencies, and creating some files. Ensure you’re running node v20 or greater (Test runner is a stable API as of the 20 major releases) Overview * index.js - node entry that initializes our Fastify app and listens for incoming http requests on port 3001 * app.js - this file exports a function that creates and returns our Fastify application instance * sql-plugin.js - a Fastify plugin that sets up and connects to a SQL driver and makes it available on our app instance Application Code A simple first test For our first test we will just test our servers index route. If you recall from the app.js code above, our index route returns a 501 response for “not implemented”. In this test, we're using the createApp function to create a new instance of our Fastify app, and then using the inject method from the Fastify API to make a request to the / route. We import our test utilities directly from the node. Notice we can pass async functions to our test to use async/await. Node’s assert API has been around for a long time, this is what we are using to make our test assertions. To run this test, we can use the following command: By default the Node.js test runner uses the TAP reporter. You can configure it using other reporters or even create your own custom reporters for it to use. Testing our SQL plugin Next, let's take a look at how to test our Fastify Postgres plugin. This one is a bit more involved and gives us an opportunity to use more of the test runner features. In this example, we are using a feature called Subtests. This simply means when nested tests inside of a top-level test. In our top-level test call, we get a test parameter t that we call methods on in our nested test structure. In this example, we use t.beforeEach to create a new Fastify app instance for each test, and call the test method to register our nested tests. Along with beforeEach the other methods you might expect are also available: afterEach, before, after. Since we don’t want to connect to our Postgres database in our tests, we are using the available Mocking API to mock out the client. This was the API that I was most excited to see included in the Node Test Runner. After the basics, you almost always need to mock some functions, methods, or libraries in your tests. After trying this feature, it works easily and as expected, I was confident that I could get pretty far testing with the new Node.js core API’s. Since my plugin only uses the end method of the Postgres driver, it’s the only method I provide a mock function for. Our second test confirms that it gets called when our Fastify server is shutting down. Additional features A lot of other features that are common in other popular testing frameworks are also available. Test styles and methods Along with our basic test based tests we used for our Fastify plugins - test also includes skip, todo, and only methods. They are for what you would expect based on the names, skipping or only running certain tests, and work-in-progress tests. If you prefer, you also have the option of using the describe → it test syntax. They both come with the same methods as test and I think it really comes down to a matter of personal preference. Test coverage This might be the deal breaker for some since this feature is still experimental. As popular as test coverage reporting is, I expect this API to be finalized and become stable in an upcoming version. Since this isn’t something that’s being shipped for the end user though, I say go for it. What’s the worst that could happen really? Other CLI flags —watch - https://nodejs.org/dist/latest-v20.x/docs/api/cli.html#--watch —test-name-pattern - https://nodejs.org/dist/latest-v20.x/docs/api/cli.html#--test-name-pattern TypeScript support You can use a loader like you would for a regular node application to execute TypeScript files. Some popular examples are tsx and ts-node. In practice, I found that this currently doesn’t work well since the test runner only looks for JS file types. After digging in I found that they added support to locate your test files via a glob string but it won’t be available until the next major version release. Conclusion The built-in test runner is a lot more comprehensive than I expected it to be. I was able to easily write some real-world tests for my application. If you don’t mind some of the features like coverage reporting being experimental, you can get pretty far without installing any additional dependencies. The biggest deal breaker on many projects at this point, in my opinion, is the lack of straightforward TypeScript support. This is the test command that I ended up with in my application: I’ll be honest, I stole this from a GitHub issue thread and I don’t know exactly how it works (but it does). If TypeScript is a requirement, maybe stick with Jest or Vitest for now 🙂...

Nov 29, 2023

5 mins

NodeJSTypeScriptTesting

How to host a full-stack app with AWS CloudFront and Elastic Beanstalk

How to host a full-stack JavaScript app with AWS CloudFront and Elastic Beanstalk Let's imagine that you have finished building your app. You have a Single Page Application (SPA) with a NestJS back-end. You are ready to launch, but what if your app is a hit, and you need to be prepared to serve thousands of users? You might need to scale your API horizontally, which means that to serve traffic, you need to have more instances running behind a load balancer. Serving your front-end using a CDN will also be helpful. In this article, I am going to give you steps on how to set up a scalable distribution in AWS, using S3, CloudFront and Elastic Beanstalk. The NestJS API and the simple front-end are both inside an NX monorepo The sample application For the sake of this tutorial, we have put together a very simple HTML page that tries to reach an API endpoint and a very basic API written in NestJS. The UI The UI code is very simple. There is a "HELLO" button on the UI which when clicked, tries to reach out to the /api/hello endpoint. If there is a response with status code 2xx, it puts an h1 tag with the response contents into the div with the id result. If it errors out, it puts an error message into the same div. ` The API We bootstrap the NestJS app to have the api prefix before every endpoint call. ` We bootstrap it with the AppModule which only has the AppController in it. ` And the AppController sets up two very basic endpoints. We set up a health check on the /api route and our hello endpoint on the /api/hello route. ` Hosting the front-end with S3 and CloudFront To serve the front-end through a CMS, we should first create an S3 bucket. Go to S3 in your AWS account and create a new bucket. Name your new bucket to something meaningful. For example, if this is going to be your production deployment I recommend having -prod in the name so you will be able to see at a glance, that this bucket contains your production front-end and nothing should get deleted accidentally. We go with the defaults for this bucket setting it to the us-east-1 region. Let's set up the bucket to block all public access, because we are going to allow get requests through CloudFront to these files. We don't need bucket versioning enabled, because these files will be deleted every time a new front-end version will be uploaded to this bucket. If we were to enable bucket versioning, old front-end files would be marked as deleted and kept, increasing the storage costs in the long run. Let's use server-side encryption with Amazon S3-managed keys and create the bucket. When the bucket is created, upload the front-end files to the bucket and let's go to the CloudFront service and create a distribution. As the origin domain, choose your S3 bucket. Feel free to change the name for the origin. For Origin access, choose the Origin access control settings (recommended). Create a new Control setting with the defaults. I recommend adding a description to describe this control setting. At the Web Application Firewall (WAF) settings we would recommend enabling security protections, although it has cost implications. For this tutorial, we chose not to enable WAF for this CloudFront distribution. In the Settings section, please choose the Price class that best fits you. If you have a domain and an SSL certificate you can set those up for this distribution, but you can do that later as well. As the Default root object, please provide index.html and create the distribution. When you have created the distribution, you should see a warning at the top of the page. Copy the policy and go to your S3 bucket's Permissions tab. Edit the Bucket policy and paste the policy you just copied, then save it. If you have set up a domain with your CloudFront distribution, you can open that domain and you should be able to see our front-end deployed. If you didn't set up a domain the Details section of your CloudFront distribution contains your distribution domain name. If you click on the "Hello" button on your deployed front-end, it should not be able to reach the /api/hello endpoint and should display an error message on the page. Hosting the API in Elastic Beanstalk Elastic beanstalk prerequisites For our NestJS API to run in Elastic Beanstalk, we need some additional setup. Inside the apps/api/src folder, let's create a Procfile with the contents: web: node main.js. Then open the apps/api/project.json and under the build configuration, extend the production build setup with the following (I only ) ` The above settings will make sure that when we build the API with a production configuration, it will generate a package.json and a package-lock.json near the output file main.js. To have a production-ready API, we set up a script in the package.json file of the repository. Running this will create a dist/apps/api and a dist/apps/frontend folder with the necessary files. ` After running the script, zip the production-ready api folder so we can upload it to Elastic Beanstalk later. ` Creating the Elastic Beanstalk Environment Let's open the Elastic Beanstalk service in the AWS console. And create an application. An application is a logical grouping of several environments. We usually put our development, staging and production environments under the same application name. The first time you are going to create an application you will need to create an environment as well. We are creating a Web server environment. Provide your application's name in the Application information section. You could also provide some unique tags for your convenience. In the Environment information section please provide information on your environment. Leave the Domain field blank for an autogenerated value. When setting up the platform, we are going to use the Managed Node.js platform with version 18 and with the latest platform version. Let's upload our application code, and name the version to indicate that it was built locally. This version label will be displayed on the running environment and when we set up automatic deployments we can validate if the build was successful. As a Preset, let's choose Single instance (free tier eligible) On the next screen configure your service access. For this tutorial, we only create a new service-role. You must select the aws-elasticbeanstalk-ec2-role for the EC2 instance profile. If can't select this role, you should create it in AWS IAM with the AWSElasticBeanstalkWebTier, AWSElasticBeanstalkMulticontainerDocker and the AWSElasticBeanstalkRoleWorkerTier managed permissions. The next step is to set up the VPC. For this tutorial, I chose the default VPC that is already present with my AWS account, but you can create your own VPC and customise it. In the Instance settings section, we want our API to have a public IP address, so it can be reached from the internet, and we can route to it from CloudFront. Select all the instance subnets and availability zones you want to have for your APIs. For now, we are not going to set up a database. We can set it up later in AWS RDS but in this tutorial, we would like to focus on setting up the distribution. Let's move forward Let's configure the instance traffic and scaling. This is where we are going to set up the load balancer. In this tutorial, we are keeping to the defaults, therefore, we add the EC2 instances to the default security group. In the Capacity section we set the Environment type to Load balanced. This will bring up a load balancer for this environment. Let's set it up so that if the traffic is large, AWS can spin up two other instances for us. Please select your preferred tier in the instance types section, We only set this to t3.micro For this tutorial, but you might need to use larger tiers. Configure the Scaling triggers to your needs, we are going to leave them as defaults. Set the load balancer's visibility to the public and use the same subnets that you have used before. At the Load Balancer Type section, choose Application load balancer and select Dedicated for exactly this environment. Let's set up the listeners, to support HTTPS. Add a new listener for the 443 port and connect your SSL certificate that you have set up in CloudFront as well. For the SSL policy choose something that is over TLS 1.2 and connect this port to the default process. Now let's update the default process and set up the health check endpoint. We set up our API to have the health check endpoint at the /api route. Let's modify the default process accordingly and set its port to 8080. For this tutorial, we decided not to enable log file access, but if you need it, please set it up with a separate S3 bucket. At the last step of configuring your Elastic Beanstalk environment, please set up Monitoring, CloudWatch logs and Managed platform updates to your needs. For the sake of this tutorial, we have turned most of these options off. Set up e-mail notifications to your dedicated alert e-mail and select how you would like to do your application deployments. At the end, let's configure the Environment properties. We have set the default process to occupy port 8080, therefore, we need to set up the PORT environment variable to 8080. Review your configuration and then create your environment. It might take a few minutes to set everything up. After the environment's health transitions to OK you can go to AWS EC2 / Load balancers in your web console. If you select the freshly created load balancer, you can copy the DNS name and test if it works by appending /api/hello at the end of it. Connect CloudFront to the API endpoint Let's go back to our CloudFront distribution and select the Origins tab, then create a new origin. Copy your load balancer's URL into the Origin domain field and select HTTPS only protocol if you have set up your SSL certificate previously. If you don't have an SSL certificate set up, you might use HTTP only, but please know that it is not secure and it is especially not recommended in production. We also renamed this origin to API. Leave everything else as default and create a new origin. Under the Behaviors tab, create a new behavior. Set up the path pattern as /api/* and select your newly created API origin. At the Viewer protocol policy select Redirect HTTP to HTTPS and allow all HTTP methods (GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE). For this tutorial, we have left everything else as default, but please select the Cache Policy and Origin request policy that suits you the best. Now if you visit your deployment, when you click on the HELLO button, it should no longer attach an error message to the DOM. --- Now we have a distribution that serves the front-end static files through CloudFront, leveraging caching and CDN, and we have our API behind a load balancer that can scale. But how do we deploy our front-end and back-end automatically when a release is merged to our main branch? For that we are going to leverage AWS CodeBuild and CodePipeline, but in the next blog post. Stay tuned....

Sep 11, 2023

12 mins

NestJSAWSTypeScriptNodeJS

GraphQL Updates- October 2021

State of GraphQL State of GraphQL brings together core contributors, members of the GraphQL Foundation, and community leaders to talk about the future of GraphQL, and answer audience questions. Sponsors Shout-out to the sponsors of the event, StepZen and Moon Highway! - StepZen > One GraphQL API. All Your Data. Zero Infrastructure. StepZen is a GraphQL-as-a-Service provider, even including a FREE forever pricing tier with 300k calls/month included. - Moon Highway > The cutting edge JavaScript training for engineers of all skill levels Moon Highway is a training company that teaches a lot of courses centered around the JavaScript ecosystem. - JavaScript & Node - React - GraphQL Hosts - Tracy Lee, CEO, This Dot Labs - Eve Porcello, Co-founder & Instructor, Moon Highway Panelists - Uri Goldshtein, Founder, The Guild - Carlos Rufo, Engineering Lead, GraphCMS - Joey Nenni, Web Engineering Lead (GraphQL), PayPal - Janessa Garrow, Developer Experience Engineer, Apollo GraphQL - Tanmai Gopal, Founder, Hasura GraphQL Updates The first portion of the State of GraphQL covered updates from each panelist. The GraphQL Foundation One of the first topics covered by State of GraphQL was The GraphQL Foundation. > The GraphQL Foundation is a neutral foundation founded by global technology and application development companies. The GraphQL Foundation encourages contributions, stewardship, and a shared investment from a broad group in vendor-neutral events, documentation, tools, and support for GraphQL. > > GraphQL.org Uri opened up the conversation by emphasizing how open the foundation is. The GraphQL Foundation has always been open, but it's now easier than ever to become part of the community. The true "meat" of where the GraphQL action is though is in the GraphQL Working Group. There, topics such as changes to the GraphQL spec, ideas for new features, and more are discussed. Also, all the meetings are recorded and even summarized by text! Apollo Odyssey > Odyssey is Apollo's free interactive learning platform. Janessa from the Apollo team introduced us to Apollo Odyssey. Odyssey is Apollo's official learning platform. It was created to improve the developer experience of learning GraphQL. While some people may be able to learn effectively from docs, others may find different learning styles, like those offered by Odyssey, a more effective way of learning. Courses offered range from the basics, like what are queries and resolvers, to the more advanced subjects, such as Apollo Federation. Hasura Tanmai from Hasura spoke next about updates done within Hasura. One of the biggest new features is support for cross-database joins over GraphQL. This update allows the developer to retrieve data from any number of data stores with efficient queries. The next thing being worked on now is end-to-end streaming. PayPal Joey Nenni of PayPal spoke about PayPal's experience with adopting GraphQL. He mentioned that once PayPal supported developers with tooling and sample apps, GraphQL spread like wildfire. Seeing the potential to do more with GraphQL, especially with sharing components, PayPal looked into Apollo Federation about 9 months ago, and as of about 2 weeks ago, they are now live with millions of requests already going through their gateway. Joey also spoke about how GraphQL adoption is really about persistence. It's an iterative process. By making small steps, collecting small wins, and repeating that process, it becomes a lot easier to sell GraphQL. Joey coined the term "Guerilla Warfare" when it comes to finding successful implementations for GraphQL solutions. GraphCMS > GraphCMS gives you instant GraphQL Content APIs to create, enrich, unify, and deliver your content across platforms. GraphCMS recently hosted GraphQL Conf AND has recently raised $10 million in a Series A funding round. With all of this GraphQL focused momentum, GraphCMS is poising itself as a powerful solution for Headless CMS. > The ultimate content platform that enables you to deliver applications at scale. > > Carlos Rufo Defer and Stream One important piece of information that Uri brought to the groups' attention was that defer, stream, live queries, and other features in spec proposals, but not in the actual spec, CAN BE USED SAFELY. Uri noticed a patter in production settings: once people have been given the option to use these new features, like defer, they see how valuable those features can be. If you want to see more information involving these GraphQL directives, you can check out a blog post covering them here. Apollo Federation > Implement a single graph across multiple services > > Apollo Documentation One very popular subject that is commonly brought up in Apollo conversations is Apollo Federation, and the idea of having a unified Graph connecting many services. For PayPal, they spoke about the experiences encountered while transitioning some of their shared logic to a federated graph, while maintaining developer experience. Apollo itself had a very positive experience using Apollo Federation. They ran into the need to unite two services, one written in Kotlin, and one in TypeScript, and have them run under a single gateway. This was a very big win and prevented the need for developers to learn additional languages to support a larger graph. Tanmai had a balanced perspective on Apollo Federation: > Are we federating how the API comes together and presents itself? Or are we federating the execution itself? He shared his experiences with analyzing where exactly a federated graph could be a good fit. For Uri, he spoke about how the most important question is, "Are we actually making the product development faster?" Adopting Apollo Federation may give a different answer depending on the team and work being done. Conclusion GraphQL is still growing rapidly, and as shown in this State of GraphQL, there is a growing thriving community surrounding it. Continue the conversation, no matter your experience level, and check out the GraphQL Working Group. While this was a quick summary of the things spoken about during the State of GraphQL, you can catch the whole video on YouTube. Thank you for enjoying the State of GraphQL!...

Oct 20, 2021

5 mins

GraphQL

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Building a Stripe App: A Step-by-Step Guide to QR Code Generation Why Build a Stripe App? I recently participated in an audio space with the Stripe team, and something they said really stuck with me: the Stripe app store is a growing area that isn't overly saturated yet. There's a lot of potential for new apps, and companies can use this opportunity to grow. I work at a company called This Dot Labs, and we've created several Stripe apps and even own one. After looking at the data, I can confirm that the Stripe team was right! Creating a QR Code Generator App For this tutorial, we'll build a QR code app that can take a URL and generate a code for it. This is a good use case to help you understand the ins and outs of Stripe's developer tools. Why QR Codes? QR codes are useful tools that have become common in e-commerce, restaurants, and other industries. While Stripe already has a QR code tool, we'll make our own to familiarize ourselves with their syntax and problem-solving approaches. Project Structure Before we dive into the implementation, let's look at the structure of our Stripe App QR Code project: * .vscode: Contains settings for Visual Studio Code * source/views: Holds the main application views * .gitignore: Specifies files to ignore in version control * stripe-app.json: Defines the Stripe app configuration * ui-extensions.d.ts: TypeScript declaration file for UI extensions * .build: this is where the built Stripe app gets placed. Step-by-Step Implementation 1\. Install Stripe Locally First, you need to install Stripe on your local machine. The documentation provides great instructions for this: * For Mac users: Use Brew to install * For Windows users: Download the package and add it to your environment variables You can find the details here in the stripe docs to install the Stripe CLI https://docs.stripe.com/stripe-cli When using Windows, you must do stripe login from Powershell, NOT from Git bash or any other tool. After the server is up, then you can continue using git bash for everything else. After stripe login, you need to enter stripe apps start. Once you do that, the server is up and running and you can go back to using git bash or any other tool. 2\. Install Dependencies We'll be using an extra package for QR code generation. Install it using npm: ` 3\. Set Up the Main Component Let's look at the home.tsx file, where we'll use Stripe's UI components: ` These components are similar to other UI libraries like Bootstrap or Tailwind CSS. 4\. Create the UI Structure Our app will have: * An input field for the URL * Validation using a regex pattern * Error handling for invalid URLs * QR code generation and display Here is the Home.tsx file that is located in the src/views folder ` * ContextView` is at the top level of the app where we see the Title and the link to the Stripe Docs that we placed in our Context View. * Box is how you use Divs. * Banners can be used to show notification errors or any other item you wish to display. * Textfields are input fields. * Everything else is pretty self-explanatory. 5\. Handle Content Security Policy One problem I personally ran into was when I tried to redirect users, the Stripe policies would block it since I did not express that I knew what it was doing. I had to go into the stripe-app.json file and mention the specific security policies. For this particular exercise, I kept these as null. This is my stripe-app.json file. ` 6\. Configure App Views As you can see here, the stripe-app.json file shows the views for each file I have. The Home.tsx file and the Invoice.tsx are also included This is our way of saying that for each view we have, show the app functionality on that page. Our stripe-app.json file will show it but also, the manifest.js file in our .build folder will also show the same. Any view that doesn't have a file will not show the application's functionality. So, if I were to go to transactions, the app would not show the same logic as the home or invoices page. By following these steps, you'll have a fully functional QR code generator app for Stripe. This is just a simple example, but the potential for Stripe apps is massive, especially for businesses serving e-commerce customers. If you need help or get stuck, don't hesitate to reach out, danny.thompson@thisdot.co. The Stripe team is also very active in answering questions, so leverage them as a resource. Happy coding!...

Dec 18, 2024

4 mins

stripe

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

How to deploy a NodeJS application using Fly.io

What is Fly.io?

Fly.io App Deployment Speed-run

CI/CD

Conclusion

Matthew Pagan

You might also like

Testing a Fastify app with the NodeJS test runner

How to host a full-stack app with AWS CloudFront and Elastic Beanstalk

GraphQL Updates- October 2021

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Let's innovate together!

You might also like

Testing a Fastify app with the NodeJS test runner

How to host a full-stack app with AWS CloudFront and Elastic Beanstalk

GraphQL Updates- October 2021

Building a Stripe App: A Step-by-Step Guide to QR Code Generation