DEV Community: Livecycle

How to collaborate better with your team on Localhost

Pradumna Saraf — Wed, 07 Feb 2024 07:38:48 +0000

Collaborating on localhost sounds unusual, doesn't it?

Yes, it's not conventional because it's nearly impossible to collaborate with others when you're running something locally on localhost and they are not sitting next to you. By "collaborate" here, I mean that the other person may be able to check your work, visualize your changes, check the logs of the running app, access the terminal, execute commands, debug together, etc.

And yes, we have tools and other methods, which do some of the things I mentioned above, like test environments, branching strategies, etc., for sharing our work with other teammates, but it takes time to go through these typical processes and can be a blocker when you need instant help and feedback. Also, many times replication of errors and bugs becomes quite difficult. Of course, it leads to a slower SDLC and review cycle. Also, it costs both time and money (the cost of running CI and deployment).

We at Livecycle are trying to solve this broken "Review Cycle". Every company and team face this issue, but no one is solving it and providing an end-to-end solution without creating any friction in the existing development cycle. This is why we built the Livecycle Docker Extension to achieve all the collaboration (and more) mentioned in the opening paragraph. The only thing you need before starting to use the extension is to have your application Dockerized and make your application compose-ready. Almost every team uses compose to dev, and in case you don't have it already, you can use docker init. The reason for using Docker Compose under the hood for all these tunnelling and sharing is to ensure replication and, most importantly, not impact your actual application code or dependencies. This way, there's no need to modify your application to leverage this tool.

Let's see how you use this:

Installing the extension: Navigate to this link or search for "Livecycle" in the Docker Desktop Extensions Marketplace. Click the "Install" button to install the extension.

Setting up a Livecycle account: Once you have installed the extension and opened it, you will be greeted with a login screen. You can choose to log in with your GitHub account or Google account. If you previously used Livecycle and created an organization, you can log in with your Livecycle account.

Getting shareable URLs As soon as you log in, you will be able to see a list of running docker compose applications and all the services that are running in them. To get a public shareable URL for every service, click on the "Share" button below the service name.

You can choose between Local and Cloud. The local option will create a tunnel to your local machine, and the cloud option will put your application into the cloud and create a tunnel to it. You can choose depending on your use case. For example, if you want the environment to stay for a small amount of time (this one is a good option for quick feedback), you can choose the local option. If you want the environment to stay for a longer time, and the team can access it over a few days, you can choose the cloud option.

After that, you can choose public access, you will get a public URL that you can share with anyone. If you choose private access, you will get a private URL that requires authentication and can only be used by your organization members. Then click on the "Share" button to get the shareable URL.

Accessing the shared URL: URLs created by the extension are consistent, shareable, and can be used by a browser or any other HTTP client. Using these URLs, your team members will be able to see and interact with your local version of the app as long as the tunnel is open and your workstation is running. Private environments require adding team members to your organization, and upon access, your team members will be prompted to authenticate.

Accessing Livecycle dashboard: You can also access the Livecycle dashboard to see the logs and debug your application. Click on the "Open Link" button to open the Livecycle dashboard. On the dashboard, you can see all the running applications and services. The Livecycle dashboard requires authentication and organization membership, similar to private environments/services

Debugging, inspecting, and logging: Once you have opened the Livecycle dashboard, you can see all the environments/apps that are running. Click on the environment name for which you want to see the logs, terminal, etc. You can view the logs, terminal, and container inspection for each service. Soon we will support on-screen comments for improve the feedback cycle.

That's it! You have successfully installed the Livecycle Docker Extension and shared your local development environment with your team. Now you can easily share your work with anyone in the world with a single click of a button and

And if you want to go through the cloud route, you can check out this blog:

feat: Deploy To Cloud - Livecycle Docker Extension

Pradumna Saraf for Livecycle ・ Jan 25 '24

#docker #cloud #development #devops

Also, you can check out the video below for a step-by-step guide on how to get started with it.

We also have detailed documentation and an FAQ section to clear all your doubts. In case you need any help or just want to have fun chat join our Livecycle community.

feat: Deploy To Cloud - Livecycle Docker Extension

Pradumna Saraf — Thu, 25 Jan 2024 13:11:12 +0000

In our recent blog post, "In-Flight Collaboration With The Livecycle Docker Extension," we introduced Livecycle's newest tool, the Livecycle Docker Extension. This extension allows developers to instantly share local development environments, facilitating early collaboration and feedback in the software development lifecycle.

It complements Livecycle's existing tools, offering multiple entry points into the development workflow. The key feature is enabling in-flight UI reviews and debugging, addressing challenges of delayed feedback. You can check out that blog

In-Flight Collaboration With The Livecycle Docker Extension

Pradumna Saraf for Livecycle ・ Oct 4 '23

#docker #productivity #development #collaboration

In the past, when you shared your work using Livecycle Docker Extension, everything ran locally—your application, tunnel, and more. This meant that as long as your system was up and running, the people you shared the URL with could access your work. It was great for short-term reviews.

Now, we're taking it to the next level. With our latest update "Deploy to Cloud", you can deploy your applications on the cloud—be it AWS, GCP, Azure, or Kubernetes. This means the sharing process isn't limited to your local setup anymore; you can have an environment running for longer with more stability for long-term review and feedback, all happening in the cloud.

Let's see how you can use this amazing feature!

Installing the extension

Navigate to this link or search for "Livecycle" in the Docker Desktop Extensions Marketplace. Click the "Install" button to install the extension.

Setting up a Livecycle account

Once you have installed the extension and opened it, you will be greeted with a login screen. You can choose to log in with your GitHub account or Google account. If you previously used Livecycle and created an organization, you can log in with your Livecycle account.

Share to Cloud

We can either deploy a fresh new environment directly to the cloud or deploy the existing local shared one to the cloud.

Deploy a new shareable environment to the cloud

As soon as you log in, you will see a list of running Docker Compose applications. Click on the "Share" button below the app name. Choose the cloud option. After that, you will be prompted to choose a cloud provider. You can choose between AWS, GCP, and Azure, or use Kubernetes if you have a Kubernetes cluster. Make sure you have the credentials for the chosen cloud provider setup in your local system, for Kubernetes, the kubeconfig file.

I will choose AWS as my cloud provider. As you can see, it asks for region, bundle ID, etc. You can leave the region as default or choose the region you want. Also, some columns are optional, so you can leave them blank. After that, click on the "Share" button to get the shareable URL. It will take some time to deploy and generate those URLs.

Now you can see the environment is deployed to AWS, and you can access it using the shareable URL. You can also see the environment in the Livecycle dashboard. To access it click on the "Open Link" button to open the dashboard. On the dashboard, you can see all the running applications and services. The Livecycle dashboard requires authentication and organization membership, similar to private environments/services

Deploy an existing locally shared environment to the cloud

You can also deploy an existing local environment to the cloud. To do that, simply click on the three dots next to the environment name and click on the "Deploy" option. After that, you will be prompted to choose the cloud provider or if you don't get the prompt to choose the cloud provider, it will deploy to the provider you chose previously for the environment. In my case, I chose AWS previously, so it will deploy to AWS.

After that, a new environment will be created with the same name as the local environment. So, now you have two environments, one local and one cloud. To ensure the environment is deployed to the cloud, you can see the cloud icon next to the environment name. You can also see the environment in the Livecycle dashboard like we did above

Certainly! Here's the corrected version:

If you are experiencing any issues or wish to provide feedback, feel free to join the Livecycle Community on Slack. Additionally, please visit livecycle.io to learn more about Livecycle and find more details.

👀 Under the Hood at DevHunt 🚀

Zevi Reinitz — Tue, 26 Dec 2023 07:36:33 +0000

The Challenge of Launching DevTools

One of the unique challenges for any DevTools company is finding the right platforms for launching the product.

There are many places to launch products in general, but DevTools by definition have a unique audience and that renders many of the standard launch platforms less relevant and less effective.

That's why I was pleasantly surprised when I discovered DevHunt - a product launch platform built by developers for developers, focused solely on launching DevTools to a relevant audience.

Launching Livecycle on DevHunt

In my experience, the best way to learn about a new platform is to use it myself. And the second best way is to speak to the founders directly about what motivated them to build it in the first place.

So this week, I'm checking both of these boxes at the same time:

Livecycle is Live on DevHunt this week (🚀🚀Shameless plug... please upvote Livecycle on DevHunt!!🚀🚀)
I reached out to DevHunt founder John Rush to learn more about his career and his motivation for building a dev-centric product launch platform.

This is the first installment of a launch-in-public diary that I'll be sharing so that other dev tools companies can (hopefully) learn and benefit from our experience.

My Conversation with DevHunt Founder John Rush

How did you get started as a developer?

I was building electronics since I was 5 years old and started coding when I was 12. I also studied computer science so I’m a typical coder who did it since he remembers himself.

You clearly have a lot of product ideas and you’ve built a bunch of them… How do you decide when an idea is good enough to actually build?

I only build stuff I really wanna use myself, but can’t find anything on the market that suits my needs 100%.

What does your early go-to-market process look like? How do you start promoting the product to developers and get those first 100 users?

I use X a lot. Trying to make a viral tweet that’s not a promotion, but indirect promotion. I post on Hacker News, Hackernoon, Devto, Product Hunt, Dev Hunt and 100 more directories.

Why did you decide to build DevHunt? What makes it unique?

Product Hunt is a closed company. They have no dialog with the maker community. This is unacceptable for such a platform. Everyone complains, including me. This leads to issues, often we see products cheating there. The last drop for me was when I got the #2 spot of the day because the top product was cheating with fake upvotes, it seemed obvious based on indirect metrics (such as upvote speed). That day I decided to make Dev Hunt and make it 100% open and transparent. The community loves it. We won PH product of the day and we have grown every week since the launch.

Can you give some tips on how developers can get the most out of a DevHunt product launch?

Promote it on social media, direct messages to friends, blog posts and add the Dev Hunt banner on your site. If all 15 tools do that, it means we merge all audiences and actually cross-promote these products. On top of that, the generic Devhunt audience checks all the tools. So in total, these actions create great traffic.

Beyond the initial launch, winning on DevHunt means you stay on the home page for years. This is so valuable for a brand and traffic, I can’t even describe it. Your tool is among the best tools in a short list visible all year long, every day to every visitor of DevHunt.

Can you share an epic failure you experienced as a developer? What did you learn from it?

Every time I put too much effort and time into coding a product, it fails. There is one product we spent almost a year building and when we launched, we got 0 users, because users didn’t really need it. We closed down that company later.

Building and testing so many products requires a lot of positivity and optimism. How do you maintain a positive perspective even when things seem to be going wrong?

I’m an optimist by nature. I think founders must be optimistic. If not, I’d rather not start a business, because almost everything I do fails, and almost every decision I make is wrong, but sometimes I’m right and sometimes my products are useful, these moments make me happy enough to go grind further forever.

Tell us about a new project you're excited about or something new you're learning

My goal for 2024 is to have 100 projects launched in total. I am at 20 now. So I need to launch 80 more. The one I’m working on right now is a tool to make websites/directories/CVs/roadmaps out of Google Sheet or Notion. Super simple. No advanced cms. Also I’m launching indexgoogle.com this week and listingbott.com next week.

What is the best piece of advice you’ve ever received?

Kill your EGO

More About John Rush

Bio:
16 years in the startup world. 25 failures. 4 successes in VC funded startups. Pivoted into the bootstrapped indie world in 2023.

20+ projects:
Marsx.dev, Unicornplatform.com website builder, Devhunt.org Open Source PH alternative for dev tools, SeoBotAI.com SEO on 100% autopilot, zero actions needed), Listingbott.com lists a tool on up to 1000 directories with 1 click for traffic/backlinks, AllGPTs.co most popular custom GPT directory in the world, filmgrail.com cinema SaaS platform - powers cinemas on all continents, processing over $50M in ticket sales a year, lorem.space image placeholder api, marketsy.ai **e-commerce and marketplaces powered by AI, **uigenerator.org generate UI mockups for your website, cofondr.com cofounder as a service for busy solo makers, indexgoogle.com index your new pages really fast, in just hours, saasemailer.com dead simple emailers/CRM for solo makers, nextjsstarter.com directory of all NextJS starters and boilerplates, startupstools.com startup tools used by famous makers, osssoftware.org vetted OSS alternatives for the tool you pay for, My newsletter >>> 100xfounder.beehiiv.com

How to Get Preview Environments for Every Pull Request

Pradumna Saraf — Wed, 13 Dec 2023 08:34:45 +0000

TL;DR

In this article you’ll learn:

What preview environments are and how they can help you
How to easily set up preview environments
How to add this capability to your CI pipeline and get automatically produced environments for every pull request

What is an ephemeral preview environment?

Ephemeral preview environments are production-like environments that are created per commit so that the branch in question can be easily reviewed and tested before it gets merged.

Preview environments enable dev teams to shift the review process to “pre-merge” where it’s easier to identify bugs and avoid the single staging-server roadblock. They give you the ability to “preview” the code changes present in a pull request BEFORE you merge it to master, which is why it’s called “preview environment” or “deploy preview”. Some people prefer to call it an “ephemeral environment” because unlike production environments, it is ephemeral and temporary by design.

You can think of a preview environment as a feature-specific version of the staging or production environment, giving teams the ability to see changes in “live” mode before merging to production. This is a powerful capability that carries many potential benefits.

And with the right tooling, preview environments can be set up to be generated automatically for every pull request, so review cycles can gt started automatically without DevOps backlogs and other human delays.

Sound too good to be true?

It’s not.

And in this article, we’ll show you how you can use Livecycle’s open source tool “Preevy” to easily add preview environments to your workflow.

An easy way to create preview environments

Preevy is a CLI Tool built by Livecycle that is designed to easily provision, manage, and expose ephemeral environments for containerized applications in the cloud.

These environments are inexpensive, easy to integrate, customizable, and accessible for both technical and non-technical users.

It’s simple, flexible, and doesn’t require deep DevOps knowledge, making it ideal for adding preview environments to your “pull/merge request” flows.

Let’s walk through the steps of using Preevy to adding preview environments to your “pull/merge request” workflows.

Prerequisites

Preevy is designed to be easily run in CI/CD workflows, such as GH Actions, Circle CI and others.

The most common use-case for a CI job that runs Preevy is to have a live preview environment for every Pull Request as part of the review process. This allows for more collaborative and inclusive review workflows

Walkthrough: Running Preevy in your GitHub actions CI

In this example, we'll use GitHub Actions CI and AWS Lightsail as a cloud provider.

For GitHub Actions with Google Cloud, see a complete recipe at the livecycle/preevy-gha-gce-demo repo.

1. Install Preevy and create a profile

The Preevy profile provides a mechanism for storing and sharing configuration and state between different machines.
This allows sharing of environments between different CI jobs, or different developers.
Using the same profile between different CI runs ensures a consistent configuration and allows for stable URLs for your preview environments.

Preevy includes built-in support for saving profiles on AWS S3 and Google Cloud Storage.
You can also store the profile on the local filesystem and copy it manually before running Preevy - we won't show this method here.

To create the Preevy profile, first install the Preevy CLI locally:

# npm:
npm install -g preevy
# yarn:
yarn add -g preevy
# or use npx to run the CLI without installing it:
npx preevy ...

Then, set up a Preevy profile:

preevy init [profile-name]

When asked to choose a cloud provider, choose either AWS Lightsail.

You will be asked for the default AWS region in which to create AWS resources.

Next, choose where to store your profile.

The profile needs to be stored in the cloud where it can be accessed by your CI machines.

When asked where to store the profile, choose AWS S3.
The URL displayed in your terminal should look something like s3://preevy-12345678-my-profile?region=eu-west-1

Note the URL displayed in your terminal - this is the Preevy profile URL which we'll use in the actions below.

2. Make sure GitHub Actions workflows have AWS permissions

In this example, we'll be using the aws-actions/configure-aws-credentials action with GitHub's OIDC provider.
Make sure the configured role has the required permissions.

3. Create your GitHub Actions workflows

We'll create two workflows:

The Deploy Preevy environment workflow will create the preview environments when a PR is opened or updated.

The Teardown Preevy environment workflow will bring down the running preview environments when the PR is closed.

For the Deploy Preevy environment workflow, create the file preevy-up.yaml in the .github/workflows directory of your repo:

name: Deploy Preevy environment
on:
  pull_request:
    types:
      - opened
      - reopened
      - synchronize

permissions:
  id-token: write
  contents: read

  # Needed to write a PR comment with the environment URLs
  pull-requests: write

jobs:
  deploy:
    timeout-minutes: 15

    # allow a single job to run per PR
    concurrency: preevy-${{ github.event.number }}

    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::12345678:role/my-role
          aws-region: eu-west-1

      - uses: actions/checkout@v3

      - uses: livecycle/preevy-up-action@v2.0.0
        id: preevy
        with:
          profile-url: "${{ vars.PREEVY_PROFILE_URL }}"
          docker-compose-yaml-paths: "./docker/docker-compose.yaml"

      # Change `frontend` and `3000` in this step to your main service and port
      # This will appear as the GH environment URL
      - id: store_url
        name: Store URL of frontend
        run: |
          echo url=$(jq -r '.[] | select(.service=="frontend" and .port==3000).url' "${{ steps.preevy_up.outputs.urls-file }}") >> "$GITHUB_OUTPUT"

For the Teardown Preevy environment workflow, create the file preevy-down.yaml in the .github/workflows directory of your repo:

name: Teardown Preevy environment
on:
  pull_request:
    types:
      - closed
permissions:
  id-token: write
  contents: read

  # needed to update the PR comment with the environment URLs
  pull-requests: write
jobs:
  teardown:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::12345678:role/my-role
          aws-region: eu-west-1

      - uses: actions/checkout@v3
      - uses: livecycle/preevy-down-action@v1.1.0
        id: preevy
        with:
          profile-url: "${{ vars.PREEVY_PROFILE_URL }}"
          docker-compose-yaml-paths: "./docker/docker-compose.yaml"

Add a GitHub action configuration variable named PREEVY_PROFILE_URL and set the value to the URL printed at the preevy init output.

4. Get Automatic GitHub Notifications

You're all set! When you open a PR, Preevy will now build preview environments.

The Preevy Github Plugin will automatically detect the GitHub context and post a comment on your PR with the links to each of the relevant services when they are available for review.
Teammates can simply click these links and preview your latest changes in their browser.

Learn more about Livecycle here.

Feel free to star the Preevy repo here.

Good luck!

Speed Up Hackathon Collaboration 🏃🤝

Zevi Reinitz — Sun, 12 Nov 2023 12:11:21 +0000

The 2023 Docker AI/ML Hackathon

Docker recently completed their AI/ML Hackathon. Participants were encouraged to build solutions that are innovative, applicable in real life, use Docker technology, and have an impact on developer productivity.

Eligible submissions could also include non-code proof-of-concepts, extensions that improve Docker workflows, or integrations to improve existing AI/ML solutions.

All submissions were AI/ML projects or models built using Docker technology and distributed through DockerHub, AI/ML integrations into Docker products that improve the developer experience, or extensions of Docker products that make working with AI/ML more productive.

Optimizing Hackathon Speed and Productivity

Most hackathons begin and end with a simple directive - participants build something and submit it before the deadline.

But in this year's AI/ML Hackathon, Docker took things a step further. Participants were treated to a wide range of sessions focusing on helping participants build higher-quality products.

And in this context, we were thrilled that Docker asked us to present our Livecycle Docker Extension as a tool that Hackathon participants can use to achieve a blazing-fast collaborative experience. Instead of getting held back by staging servers and CI builds, the Livecycle extension lets teams share the latest changes with one another instantly, while code is still sitting on your local development environment. And with the built-in collaboration tools, Hackathon Squads can save tons of time building great products with the Livecycle extension.

Check out the complete session (given by our CTO @yshayy) on how to use the Livecycle extension for Hackathon collaboration:

And check out the Livecycle Extension here.

Anti-FAQs: Use localhost for collaboration?? Seriously?!

Zevi Reinitz — Wed, 25 Oct 2023 09:43:13 +0000

What exactly are “Anti-FAQs”?

Regular FAQs are everywhere.

As the name suggests, it’s a convenient format for answering some of the standard questions asked regarding any product or service. The assumption behind these questions is that the questioner is actually interested in the product (or at least the product premise), and they are just trying to clarify some details before deciding to move forward with it.

In this regard, “Anti-FAQs” are the complete opposite.

This is what I like to call the cynical, skeptical questions that people ask (often rhetorically) to justify why they’re NOT interested in using the product.

I like to focus on the Anti-FAQs because they are usually the juicer, more interesting discussion points. And ironically, once these items are actually clarified, the skeptics can be converted to become raving fans of the product they now better understand and appreciate.

The Anti-FAQs of localhost sharing

We’ve currently been thinking about several Anti-FAQs regarding a new Docker Extension we just launched.

The extension enables developers to to instantly share local containers with anyone, without the need for staging environments or CI builds. And we’ve included built-in collaboration tools that give technical teammates access for remote debugging and less-technical teammates the ability to leave review feedback in context, while the code is still hot off the press, on the developer’s machine.

It’s an amazing way for developers to continue to “shift-left” and bring critical review cycles to earlier stages of the development workflow, saving everyone time, headache, and money.

It’s a cause that Docker themselves are championing as recently as this year’s DockerCon, rolling out a series of native tools and features that expand the boundaries of developer collaboration.

But, pushing boundaries brings healthy skepticism. So we wanted to take the opportunity to address some of those “Anti-FAQs” you might be asking yourself about the prospect of sharing your localhost and using it to collaborate with your team.

Isn’t Ngrok already doing the same thing?

Not really. Ngrok (and others like it) are great ingress-as-a-service platforms, but the Livecycle extension takes localhost sharing even further.

Here are some important points to keep in mind:

First and foremost - the Livecycle Docker Extension is integrated with Docker, and provides a smoother experience for Docker users. Consistent URLs, private environments, organizations and Google/Github authentication are supported out of the box.

Furthermore, in order to facilitate the collaborative workflows that developers need, it’s not enough to just share the local environment. A complete workflow solution also needs to get the team’s feedback back to the developer in an effective way. Sharing work without facilitating feedback doesn’t really help get the job done.

That’s why our shared environments include built-in collaboration tools that enable technical teammates access for remote debugging, and less-technical teammates the ability to leave review feedback in context, while the code is still sitting on the developer’s machine.

The Livecycle dashboard provides debugging capabilities that include log inspection, shell access, and container inspection.

This ability to both share and collaborate is a powerful differentiator that sets Livecycle apart from other infrastructure-focused solutions.

Here are two common use cases to illustrate this:

In-progress UI Reviews

One of the most common use cases for the Livecycle extension is enabling collaboration between developers and non-technical stakeholders early in the workflow. Using the Livecycle extension, you can get instant feedback on the latest front-end changes you’re working on your machine.

By simply opening a tunnel and creating a shareable URL, you enable anyone on the team to use a browser to securely access the relevant services.

So designers, QA, marketing and management can all see the application and use built-in commenting and collaboration tools to leave clear, actionable feedback. And since everything is in context, you’ll be able to communicate quickly and fix issues MUCH earlier in the development lifecycle.

In-progress debugging

Another common use case is enabling developers to work together to review and debug code changes as soon as possible.

With the Livecycle extension, you can instantly share any front end or back end service running on your machine.

By simply opening a tunnel and creating a shareable URL, you enable your team to use their browsers to securely access these services.

Your teammates can now see real-time logging, catch errors and execute commands in a terminal, so you can collaboratively fix issues MUCH earlier in the development lifecycle.

Self-hosted ephemeral environments

And in addition to all this, Livecycle doesn’t stop with just sharing localhost. Developers can also provision self-hosted ephemeral environments in the cloud provider of their choice to maintain the current state for longer review sessions that continue even when the developers local computer is offline.

We’ll talk more about this in the following question.

At some point, that developer needs to close their computer. What happens then??

It’s true. Developers are people too. And sometimes even they need to close the computer and go home for the evening.

Thankfully, using Livecycle, this doesn’t need to mean the end of the review cycle.

Because in addition to securely sharing localhost, developers can use Livecycle to provision self-hosted ephemeral environments in the cloud provider of their choice to maintain the current state for longer review sessions that continue even when the developer's local computer is offline.

This is done using “Preevy” - our open source tool for quickly provisioning preview environments to any cloud or Kubernetes cluster. It works seamlessly with the Docker Extension to publish shareable environments on demand, or as an automated part of your CI workflow, per PR or commit.

To learn more about how to use Preevy, just check out the docs site.

Come on. There’s no way this kind of thing is secure.

Sorry to disappoint you. But you’re wrong.

The Livecycle Docker Extension uses a secure SSH tunnel to expose your local development environment using Livecycle's tunnel server, which is only accessible using HTTPS.

Furthermore, you can use the settings to enable private URLs to further control and restrict access to your environments.

So security is not something you’ll need to worry about.

Great. But this probably has limited support for the frameworks and languages I’m working with.

Not so fast buddy… you’ll be happy to know that Livecycle is language and framework-agnostic. It works with anything that runs in a Docker container. And if you’re using Preevy to provision preview environments to the cloud, you can use any cloud back end or Kubernetes cluster to do so.

What if I run into a problem? I’m sick of wasting my time talking to AI chatbots.

Good news - we’re 100% human. We’re a team of experienced developers building tools that are impacting the way dev teams collaborate with each other. Join our Slack channel to get updates, or get in touch with our team at any time and with any questions.

We'd be thrilled to have you join the community and try our Docker Extension today.

Docker’s Recent Product Announcement is Bigger than You Realize

Zevi Reinitz — Thu, 05 Oct 2023 14:04:09 +0000

TL;DR

This post is part our ongoing series of Docker insights, announcements and launches in celebration of DockerCon 2023 and in appreciation for everything that Docker has done for the developer community at large.

Docker's Recent Product Announcements

Docker has already made a few announcements at this week’s DockerCon 2023. Most notably, the launch of 3 new products that harness the power of local and cloud development environments, allowing developers to quickly, and securely build, share, and run any app, anywhere.

And while this is newsworthy by any measure - it’s easy to overlook just how big of a deal this is for developers everywhere.

First let’s appreciate the 3 new products that were announced during the conferences keynote address:

Docker Scout - Today, the tools, processes, and people involved in the software supply chain require too much context switching for developers. Feedback is often late and unclear, leaving developers to wonder how they can improve software quality. Complementing Docker’s existing trusted content, build automation and SBOM tools, Docker Scout adds relevant insights, policy evaluation, and contextual remediation, all while meeting developers where they are via integrations with Sysdig, JFrog Artifactory, AWS ECR, BastionZero, GitHub, GitLab, CircleCI, and Jenkins.
Docker Build - Dev teams can waste as much as an hour per day per team member (!) waiting for their image builds to finish. To address this, next-generation Docker Build speeds up builds by as much as 39 times (!) by automatically taking advantage of large, on-demand cloud-based servers and team-wide build caching.
Docker Debug - Developers spend as much as 60% of their time debugging their applications. But much of that time is spent sorting and configuring tools and set-up instead of actual debugging. Docker Debug provides a language-independent, integrated toolbox for debugging local and remote containerized apps, enabling developers to find and solve problems faster.

Improving the “here and now” developer experience

With these products, Docker is clearly making “shift-left” the new standard in developer experience. Each of these new tools aims to achieve a singular goal for developers everywhere: combine the responsiveness and convenience of local development with the on-demand resources, connectedness, and collaboration possibilities of the cloud. This combination enables developers to do their best work much earlier in the SDLC than they ever imagined possible.

Not surprisingly, Docker CEO Scott Johnston said it best: “The cloud offers many potential benefits for development teams, but most ‘inner-loop’ solutions require a complete change in tools and workflows — and very few developers want to ship their entire laptop to the cloud. The new products we announced today meet development teams where they are with ‘just enough cloud,’ seamlessly blurring the boundaries between local and remote development. In doing so, we’re enabling these teams to accelerate their delivery of secure applications critical to their businesses.”

// Detect dark theme var iframe = document.getElementById('tweet-1709599547058532800-377'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1709599547058532800&theme=dark" }

Frederic Lardinois from TechCrunch further quoted Johnston that in the early days of the container revolution, apps typically didn’t consist of more than a handful of containers. Now, those apps are often made up of 20 or 30 containers and that puts a lot of pressure on your typical developer laptop. “Moreover, when they’re working on an app locally, it’s hard to share a running app with your colleagues,” Johnston added. “And if that app you’re working on locally is dependent on some remote service, like a database as a service in the cloud or an AI service, it’s kind of hard, especially with security and such up your grill if you’re working in a large environment.”

Some companies have tried to get around this by moving the entire development process into the cloud by offering developers cloud-based IDEs, for example. But Johnston argues that this isn’t something that every company is going to be comfortable with. He also said that what Docker is hearing from its customers is that this breaks existing workflows. “Because of where we are on the local laptop, where Docker Desktop sits, we see a unique opportunity to not make it either/or — not local or cloud — but local and cloud and bring the best of both worlds together.”

Put simply, Docker’s new tools are built to combine the power of local and cloud to make the ‘here and now’ developer experience as effective and efficient as possible.

But Wait… There’s More…

Perhaps the most amazing thing about Docker’s announcement is the part that they didn’t say explicitly.

Docker users around the world are quickly realizing that these products were not launched in a vacuum. They represent an extension to the existing suite of Docker products, such as Docker Desktop, Private Repos, and Docker Hub - a marketplace for discovering and distributing trusted dev-centric content and tools.

Docker is launching these new products as the newest additions to their already robust platform. And this platform, in turn, enables other developers and devtools companies throughout the ecosystem to join Dockers Shift-Left call to action and extend these capabilities even further with complementary tools and contributions of their own.

Livecycle + Docker = Extended Dev Collaboration

A perfect example of Docker’s platform in action is what’s currently happening here at Livecycle. Like Docker, our mission is to enable developer collaboration by bringing other stakeholders into the developers’ immediate context in an effective an unintrusive way.

We have built tools that allow developers to share their work at any point in the workflow and get clear, actionable feedback in context so it can be addressed easily.

Historically, many developers have preferred to facilitate this type of collaboration with ephemeral preview environments that are triggered with every PR or commit. And indeed, we have built robust solutions like “Preevy” to facilitate the creation of these environments for dockerized applications on any cloud or Kubernetes cluster.

The magic of these environments is not just in the creation and sharing of the preview itself, but also in our built-in collaboration tools that enable all stakeholders to join the review process immediately and leave feedback in a shared context that is dev-centric and dev-friendly.

And now, in line with Docker’s strategic vision, we’ve extended this capability left-wards with the launch of our new Docker Extension.

We’ve leveraged the power of the Docker Extensions Marketplace to build a tool that enables developers to instantly share local containers with anyone, without the need for staging environments or CI builds.

And our built-in collaboration tools enable technical teammates access for remote debugging and less technical teammates the ability to leave review feedback in context, while the code is still sitting on the developer’s machine.

These local ENVs can also be provisioned to the cloud as self-hosted preview environments, giving developers the local + cloud flexibility and accessibility they have been so clearly asking for.

‘Docker Collaborate’ with Livecycle

You could argue that Livecycle’s collaboration layer can also be called “Docker Collaborate” - a fourth contribution to the wider Docker community that is rolling out this week.

Docker’s three native products focus on empowering the developers themselves, and Livecycle’s tools extend this to also empower the rest of the team to create a truly collaborative development experience.

Focusing on both the developer's developer experience and the ability to include other stakeholders early in the process is the two-way street that is needed to deliver optimal development efficiency and productivity.

In-Flight UI Reviews

One of the most common use cases for the new Livecycle extension is enabling collaboration between developers and non-technical stakeholders early in the workflow. Using the Livecycle extension, you can get instant feedback on the latest front-end changes you’re working on your machine.

By simply opening a tunnel and creating a shareable URL, you enable anyone on the team to use a browser to securely access the relevant services.

In-Flight Debugging

Another common use case is enabling developers to work together to review and debug code changes as soon as possible.

With the Livecycle extension, you can instantly share any front end or back end service running on your machine.

By simply opening a tunnel and creating a shareable URL, you enable your team to use their browsers to securely access these services.

Your teammates can now see real-time logging, catch errors and execute commands in a terminal, so you can collaboratively fix issues MUCH earlier in the development lifecycle.

Conclusion

We'll conclude with the words of Larry Carvalho, Principal Consultant at RobustCloud who said this about Docker's latest product initiatives: "Enhancing developer productivity has been the holy grail of the software industry for years, but many efforts to do so have severely underdelivered. By combining the power of the cloud with local development environments, these new offerings from Docker can potentially solve the festering pain points of software engineers. Delivering productivity improvements across the ‘inner loop’ accelerates the development lifecycle of next-generation innovative solutions.”

We’re excited about the work that Docker is doing, and we're excited about how this mission dovetails with our mission at Livecycle to enable optimal developer productivity and a "shift-left" developer experience for the entire team.

We invite you to try the Livecycle Extension, and join our Slack community!

In-Flight Collaboration With The Livecycle Docker Extension

Pradumna Saraf — Wed, 04 Oct 2023 12:05:33 +0000

TL;DR

We've launched our new Docker Extension! Developers use it to share local dev environments and get feedback MUCH earlier in the SDLC. We invite you to use it and benefit from it.
We're also inviting everyone to join our Slack community focused on developer collaboration, developer experience and anything needed to get started with Livecycle.

Software developers hate context switching

For software developers, context switching is a buzzkill. And context switching into past tasks is even worse. Getting A DM from your PM that starts with “So, about the feature you worked on two weeks ago…” is never good news.

It means not only pulling your head out of the code, and out of the flow - but also out of the present and into your past self - the person who designed “that feature”, built it, tested it and fixed it, and knew all about its countless, beautiful, intricate details.

But that past self has been gone for two weeks now. So to deal with this issue, you’re going to have to find a way to conjure them up. And you can expect this to bring you extra work, because it’s becoming rapidly apparent that your two-weeks ago past self was a moron who couldn’t code properly, and couldn’t document to save their life, and they built embarrassingly broken stuff which the “present-you” has to fix right now.

There's gotta be a better way

But what if I told you there’s a way to ensure that you get that message about the feature from two weeks ago… two weeks ago?

What if your your past could get the feedback they need while they were still in context. This would allow your present self could keep their head in the code and in the current flow.

Well, if this resonates with you, then you’ve come to the right place. Because here at Livecycle this is what we do best.

We cut the feedback loop short by allowing you to share your work while you’re still in context. Using Livecycle, developers can share their work with whomever they want at any point in the SDLC and get instant feedback in context. This ensures that issues are raised, understood and addressed ASAP and not two weeks later.

Livecycle's multiple workflow entry points

Livecycle supports multiple entry points into your development workflow:

Our OSS CLI tool, Preevy provisions preview environments on your cloud provider or Kubernetes cluster
Preevy also integrates into your CI pipeline to convert your pull requests into easily shareable ephemeral environments
And now, our new Docker Desktop Extension allows you to do the same for your local development environment

Share local dev environments instantly with the Docker Extension

With the launch of the Livecycle Docker Extension, teams working on dockerized applications can shift the review process much farther left than ever before. Changes, bug fixes and new features can get reviewed instantly without the hassle of staging environments or CI builds.

The ability to share local dev environments instantly has many useful applications. Here are a few to illustrate the value it can bring to you and your team:

In-Flight UI Reviews

One of the most common use cases is enabling collaboration between developers and non-technical stakeholders early in the workflow. Using the Livecycle extension, you can get instant feedback on the latest front-end changes you’re working on your machine.

By simply opening a tunnel and creating a shareable URL, you enable anyone on the team to use a browser to securely access the relevant services.

In-Flight Debugging

Another common use case is enabling developers to work together to review and debug code changes as soon as possible.

With the Livecycle extension, you can instantly share any front-end or back-end service running on your machine.
By simply opening a tunnel and creating a shareable URL, you enable your team to use their browsers to securely access these services.

Your teammates can now see real-time logging, catch errors and execute commands in a terminal, so you can collaboratively fix issues MUCH earlier in the development lifecycle.

These are just two of the many ways in which the extension can bring you fewer headaches and a better developer experience. So be sure to try the Livecycle Extension today! Also, now we have the docs as well.

Getting started with Livecycle Extension video:

And, you're also invited to join our Slack community focused on developer collaboration, developer experience and anything needed to get started with Livecycle.

The (Detailed & Creative) Playbook for Getting More GitHub Stars

Zevi Reinitz — Mon, 14 Aug 2023 12:53:40 +0000

TL;DR

My team and I recently launched an open source tool for developers
This was my first time promoting an open source tool. It was hard to find meaningful early-tage growth advice, so I had to get creative.
We've quickly grown to more than 1.5k stars in a short time. I've compiled a detailed list of growth tactics that worked to bring us traffic and stars
I’m sharing it all here so that others can apply these tactics and grow their own projects

Launching an open source project for the first time

Anyone involved in marketing knows that no two days are the same. You are constantly facing new challenges and unique situations.

And so it was a few months back when I was tasked with promoting a new open source project that we built, called Preevy.

I’ve spent years leading go to market efforts at various companies for dozens of products, but this was my first time doing so for an open source developer tool. Don't get me wrong - the devs on my team are seasoned OSS pros. But as the head of marketing, I was the open source newbie facing a learning curve.

I looked at my lack of open source marketing experience as both an advantage and a disadvantage.

On the one hand, I had a lot of catching up to do in a short period of time. On the other hand, it's always good when you can eliminate any preconceived notions of to how things "should" be done. I was free to research, question and develop a creative strategy with an open mind.

Writing the post I wish I found 6 months ago

Google quickly dampened my initial wave of enthusiasm. I looked for good advice to accelerate my learning, but most of the early-stage, open source growth content was shallow at best. I read articles promising to show me “How to get your first 1k Github stars” but was repeatedly left without the clear, tactical direction I was looking for.

The next couple of months became a whirlwind of research and experimentation to figure out what works and what doesn't.

And today, 12 weeks after launching Preevy, the project has 1.5k GitHub stars, and we’re seeing a week-over-week increase in repository traffic, forks and contributions.

There are several repeatable actions that have been effective in growing our traffic and our star count. In retrospect, some of them were buried in those generic "How to" articles, but most of them were not. Many of the creative steps we took (and continue to take) are lessons we learned the old-fashioned way.

So in the spirit of true open source, I've outlined some of our most effective tactics in one place. It’s the kind of resource I wish I had found 6 months ago, and hopefully you will find this outline helpful as you launch and growing your own open source projects.

Focusing specifically on traffic GitHub stars

To be clear - my specific focus is to show you how I got traffic and GitHub stars for my project.

I won’t be focusing on other (important) aspects of open source growth such as: converting visitors to active users, encouraging contributions to the project, best practices for repo maintenance, building a community around your project, or deciding what to build in the first place.

These are all worthy topics, but for another time.

For now, I only care about stars.

Why are GitHub stars so important?

The underlying assumption here is that GitHub stars have value. But what exactly are they valuable for?

Increasing your star count has several benefits clear and present benefits:

It focuses the team's efforts and motivates everyone to rally around a single cause and a single metric that is constantly increasing
Stars = credibility and trustworthiness in the eyes of potential users and contributors
Your pool of stargazers can teach you a lot about your target audience
Stars can help you reach GitHub trending status and a TON of visibility. (there are several factors that go into trending, but stars is an important one).

So if you’re trying to promote your GitHub library, you should be thinking about how you can get more people to star it, especially in the first couple of months after you go live.

So without further ado, let's take a deep dive into the key growth levers that worked for me and my team.

Prerequisites: Basic repo health

The first thing I focused on was making sure our repository was set up for success.

Those generic articles spend a lot of time on this, and like with any good cliche - there's a lot of truth to it. So we established a baseline for repo health that included:

A clear description of what the tool does
A Readme that is both informative and aesthetically pleasing (screenshot/GIF at the top, clearly structured, use of some emojis to mix it up a bit). I also upgraded the social card that appeared when the repo is linked on social.
A dedicated docs site with relevant technical information and how-to guides for people who want to use it

I don't have a lot of wisdom to add here. Just make a best effort at communicating clearly in your documentation (without any fluff) and don't be afraid to iterate as needed.

Once we covered the basics for Preevy, we set our sights on brining attention to the tool we had built.

From a bird's eye view, our GTM strategy had two "phases":

Get our first 100 stars artificially
Maintain natural growth from 100 stars and beyond

The first 100 stars - artificial growth

We wanted to get our first 100 stars quickly, so we started close to home. I assumed that between all of us on the team, we could find 100 relevant, first-degree connections willing to click a button and congratulate us on launching a new project.

Here are the main actions that worked for us in this phase:

Kick-off message to friends and family

We started simple. I composed a message announcing that we’ve just launched our first open source project, and asking people please check it out and show us support by leaving us a star. The message was simple and friendly, but also direct.

Don't just reply with a thumbs up. Go to GitHub and give me a star (please).

Each team member sent it out to people in their network: Relevant friends and family members, via email, Whatsapp, LinkedIn and Twitter DMs.

Ask the neighbors in our shared office space

Our company office is in a shared workspace. Which means there are dozens of other startups and active GitHub accounts within a few meters of my desk.

So I swallowed my pride, printed a QR code (to make it easy for others to open our repo on their device) and made a few causal rounds around the floor asking people if they could do us a quick favor and show us some GitHub-love. The vast majority of people were happy to help.

My non-scientific assessment is that early morning had the best conversion rates, while people were still small-talking over coffee and before they got focused on their more serious daily tasks.

Show it off (for free) at conferences

It just so happened that I attended a local tech conference shortly after Preevy launched. So I adapted the shared office space strategy to the conference showroom floor. I walked around and tried to use my smalltalk opportunities to get a few more stars from the developers walking around.

First launch announcements on social media

Once we had a few dozen stars, I posted about our launch on our social channels.

I wanted new visitors to the repository to see that at least a few dozen people had already been there and liked what we are doing.

Pretty soon, we celebrated our first 100 stars milestone, and we were ready to move into phase 2.

Beyond the first 100

I probably could have used the above tactics alone to get us to 500 stars or more, but it would have been inefficient, and regardless - I wasn’t interested in this approach. My phase 1 focus was only on the 100-star threshold so as to establish the minimal credibility needed to convert future traffic.

Our first 100 stars were decidedly artificial. And I wanted all the rest to be authentic and organic.

Organic stargazers tell you a lot about who is interested in your tool. Analyzing a growing list of stargazers gives you product and marketing insights that you need to move forward effectively. So it was important to me that our list of stargazers grow naturally, as soon as possible.

Here’s what worked for us as we moved into growth phase 2:

Content creation

Content creation and distribution was a big part of our strategy (and this continues to be the case). This topic alone deserves a dedicated blog post or two, but we’ll summarize the key elements here.

As far as content creation, we set out to create an ongoing flow of blog posts. These posts fell into one of four categories:

Present the tool directly - We wrote a number of posts that talk about Preevy directly. What it is, why we built it, who we think can benefit from it. These can be very effective when they are written in an authentic, human way
Present the tool indirectly as part of a larger project - We wrote a number of “How-to” posts that show how to build a cool project, including Preevy as part of the stack
Listicles - We put together a few list-based articles that had an open source angle to them. “5 Projects that will help you learn [some framework]” or “10 new open source repositories you need to know about in 2023” or something similar. We included Preevy in the list when relevant, but not every time.
Building in public - Open source is about sharing with others. So we wrote several posts explaining how we solved an interesting problem or how we achieved a relevant milestone (like this post, for example)

Each post had clear section headings. We added a TL;DR at the top and emojis/GIFs to keep it friendly and fun to read. We mentioned explicitly that we are building Preevy and we’d appreciate it if people could check it out and star the repository. We phrased this in-line request in different ways (sometimes more directly than others), but we always found a way to put it in the body of the article as a clear call to action.

Content distribution

Writing content is great, but it won't help you if you don’t have a good plan for distributing it to the relevant people. Here’s how we distributed our Preevy content:

Dev-centric blogging platforms - We published our content on dev-centric blogging platforms like Dev.to, Hashnode, Hackernoon, and Medium. These are the main platforms we’ve been using, but there are others you might consider as well. When doing this, be mindful of any platform-specific tags you can use to better position your content (for example, DevTo has a #showdev tag that can help show your new tool off to other developers). Also note that on platforms like Dev.to, you can create a company blog with a fixed call to action that appears on the right side of any article you publish there. This helps to get more people clicking through from your content to your GitHub repository.

Here's one of our posts trending on Dev.to:

Reddit and social media - Once the content was published on the above platforms, we promoted it on social media and in relevant subreddits. We did not drive traffic to our company blog (we’ll get to that in a minute). Rather, we intentionally directed people to the articles hosted on these outside blogging platforms. We did this because each of these blogging platforms has a built-in trending algorithm that boosts high-performing posts. By driving traffic to these links, we got the platform algorithms to work for us and get our posts many more views in a short period of time.
Our company blog - Don’t worry. We didn’t forget about our own site. We also published all content on our company blog. After all, SEO is still a thing, and so it’s good to have all that relevant content hosted on the company domain. As extra credit, we also managed to get our blog approved as a content source by dev-centric content aggregators like daily.dev. This helps us to distribute the content posted on our company’s blog, in addition to the content published on those external blogging sites.

Github Lists and Topics

There are tons of great lists on GitHub (often called “Awesome Lists”) where maintainers aggregate tools, projects and resources with a particular focus. We found several lists relevant to our tool, and opened a pull request to suggest Preevy as an addition.

Note that in some cases, you’ll need to make minor adjustments to your project or documentation to meet the list membership requirements. But this could be worth it if it's a popular list that has a lot of visitors.

In addition to “Lists” which are privately maintained, GitHub also maintains “Topics”. Open source projects can be submitted for inclusion under a relevant topic, but only by someone who is not connected to the project in an official way. So if you have friends or early adopters of your tool who love what you’re doing, you might consider asking them for a favor and having them submit your project to a few of these GitHub "Topics".

We’ve used both Lists and Topics to promote Preevy.

Other Sites and Newsletters

We found a number of sites and newsletters focused on promoting open source tools. We used these resources to promote Preevy. Here are two examples that were effective for us:

GitHub20K - Add your library here for free (maintained by @nevodavid )
Console.dev - Submit your tool for free, or pay to sponsor a newsletter

Relevant communities and dark social

We joined a bunch of communities. We wanted to be a part of relevant conversations, and promote our tool and our content in a more natural way. These communities exist on platforms such as: Slack, Discord, Reddit, Whatsapp, LinkedIn and Facebook. To find communities relevant to you, just spend a few minutes searching, or ask others in your industry to guide you towards the communities that are worth joining.

We noticed that each community has its own rules, nuances and opportunities. For example, on a particular Slack or Discord server, there might be a channel dedicated to showing off new tools or promoting new content you’ve written. Similarly, many subreddits have one day per week where you can self-promote something you’ve built and get feedback. Once you've found some communities, make friends and play by the rules.

Paid ads campaigns

Once we generated a decent amount of organic traffic, we ran some small, paid ad campaigns. We used three advertising platforms:

Ethical Ads (a dev-focused advertising platform)
Reddit (with a focus on specific, technical subreddits)
Twitter (with a focus on specific, relevant keywords)

These campaigns brought us traffic, and they also allowed us to test our messaging and learn more about what attracted people to our repository. We used these results to further optimize our content and our future ad campaigns.

Influencers

Influencer marketing can be very effective in any industry, and open source/developer tools is no different. The trick is to the right people with the right audience.

We actively searched for those people in our industry, developed relationships and ran some collaborative experiments. The majority of them were successful (a few were not, which was expected).

Each influencer knows their audience and their style. Be clear about your campaign objectives and work with them to create the content and campaigns that work best (co-created posts, product reviews, shout-outs on social or whatever else you all have in mind).

Podcasts and promotions

I’ll keep this one brief because it’s pretty self-explanatory. If you can find other people to promote you on their podcasts, webinars, conferences, or by allowing you to publish a guest blog to their site, it can help you get a lot of traffic quickly.

We were able to do this a couple of times for Preevy so far, and we’re already working on more of these opportunities.

Use cases and testimonials

Because I’m active on dev-centric blogging platforms, I kept an eye out for dev bloggers who were experienced and well-versed in our space. I looked for high-performing articles and reached out to the authors to ask them if they wanted to try Preevy and write about it.

Some wanted to be paid (rightfully so), and some (surprisingly) did not.

Some wanted to ghostwrite for us (without using their name) and some wanted to publish content in their own name on their own pages.

It took us some time to find the right people, but once we did, all of the above arrangements worked for us.

Hackernews

We used Hackernews to promote Preevy in two ways:

Post the GitHub repository under the “Show HN” tag - Hackernews can be a great place to share your new project with other technical folks. It helps to get others to upvote and comment soon after posting (just don’t share the direct link to your post!). We added a first comment where our CTO explained what we built and inviting others to try it. I don’t know if this comment helped, but I saw a lot of other open source projects doing the same. And while I can’t say for sure, it seems like HN is friendlier to GitHub repository links as opposed to some branded URL. So with a bit of coordination, HN could give you a potent dose of traffic.

Post content - We’ve tried posting some of our content on HN. Success is hit or miss, and HN will not even accept posts from some external blogging platforms. But it’s free to try and the potential upside is huge.

Social media retargeting

From the moment we formally announced the Preevy launch, we had organic social media activity running in the background. We'll save the detailed social media strategy for another post, but suffice it to say that the account was active and the content was varied.

As more people engaged with the content, I began retargeting as many of them as possible by inviting them to try/star Preevy for themselves.

I had Twitter DM template that I would send them, thanking them for linking our recent post and asking if they’d be willing to star the Preevy repo.

It took time, but lots of people were happy to help.

Shamelessly promote other people and projects

When I outlined my approach to “content creation” above, I mentioned that one types of content we’ve produced are listicles of other relevant projects or tools. One of the reasons this content is so effective is that is enables us to shamelessly promote other people.

Open source is not a zero-sum game. There’s enough traffic and enough GitHub stars to go around. And by genuinely promoting other people, companies and projects, you can get them to promote you in return. it’s almost like a “forced” collaboration and it’s often a win-win.

So for example, when we wrote listicles that included other open source projects, we tagged these companies/maintainers on Twitter when we promoted the article. Many time, they would like and retweet, adding a lot more reach to our content. This approach can be applied in many different ways, but it’s potent enough to deserve a dedicated mention in our list of open source GTM actions.

My (crazy) Github retargeting experiment

Once we reached a few hundred stargazers, I analyzed the modest audience I had built. I developed an experimental, multi-part playbook for promoting Preevy in a more targeted way to people who were more likely to be interested in it. Here’s a quick summary of what I came up with:

I used tools (such at this one and this one) to see what other repos our stargazers were starring most frequently. The stargazers of these "other" commonly starred repos became an expanded pool of potential stargazers for Preevy
I looked through the stargazers in these other repos and identified people who had publicly exposed email addresses in their GitHub profiles. To me, this was a clue that they didn’t mind being contacted via email
I further identified the people who I thought were most relevant and followed them on GitHub
Then, I reached out to these folks via email, told them I had just followed them and introduced myself and my project in case they were interested to check it out.

The last two steps were just my personal spin. You can probably do without them. The main idea is to use your pool of authentic stargazers to point you in the direction of a wider pool of similar users who might be interested in what you have to offer.

As a bonus, you can also look at what those most commonly starred repositories are doing to market their tools, and try some of it yourself.

Celebrate milestones!

We took every opportunity to celebrate a milestone in our Preevy growth journey. Every hundred star milestone got a celebratory GIF and a set of posts to drive as much positive attention to the repository as possible.

And when we missed celebrating 700, we celebrated 735 instead (because it’s good to be different sometimes).

// Detect dark theme var iframe = document.getElementById('tweet-1681648754909216769-830'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1681648754909216769&theme=dark" }

And when we hit the 1k star milestone, we kicked off a celebratory giveaway (which is actually still open until the end of this week). To enter, people need to star the repo, follow us on Twitter and retweet/tag 3 friends.

// Detect dark theme var iframe = document.getElementById('tweet-1689539582730096642-144'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1689539582730096642&theme=dark" }

Other ideas to consider

These are the ideas that worked best for us to far, that can easily be applied to other projects. We had tons of other ideas that didn't work as well, or that worked but were very specific to what we were building.

We have a bunch of experiments still to consider and in the spirit of open source, I'll share a couple of them here for your consideration:

- Translate the readme into multiple languages - At the moment, the Preevy readme is in English. But I’ve noticed that in the GitHub trending lists, you can filter by spoken language. I wonder if translating our readme into other languages will create a larger surface area for the repository to hit those trending lists with more frequency
- Product Hunt - We’ll soon be launching Preevy on Product Hunt. It’s a great place to launch new products and tools and we’re looking forward to leveraging it’s reach to bring a lot more attention to what we’re building.

In conclusion

I hope our experience in starting to grow Preevy can help you grow your own project - by borrowing some of these ideas or by thinking of new ideas on your own.

I'd be thrilled to get additional open source growth suggestions in the comments!

And if you've made it this far, and are willing to leave Preevy a star I'd really appreciate it! https://github.com/livecycle/preevy 🙏 🙏

The Magic of Ephemeral Preview Environments

Zevi Reinitz — Thu, 27 Jul 2023 09:55:06 +0000

The magic of ephemeral preview environments

---

This article was originally written by Kunal Kushwaha and published here, on the We Make Devs blog.

---

In traditional monolithic systems, reviewing code was a relatively simple process. As the entire application is bundled as just one single component, building the entire project either locally, or in an online coding environment such as Replit or GitHub codespaces is all you needed to do to view the changes and see how they would work.

However, the story changes as we move to a microservice-based architecture. In a microservice architecture, the entire application is broken down into many small components which are designed to be their own self-contained applications. This means that these small components can run without depending on the other components in the architecture. Perhaps you can already see the problems that arise while reviewing changes to such codebases.

Since every application is a self-contained app, in order to review some code changes and see the impact of the change across the entire application i.e. when all the microservices are running and working together, you would need to build each and every microservice. While this type of architecture has benefits in a production system, it does make it difficult to review code and see the impact of changes across the entire application. This is where we can leverage the power of preview environments.

Why do we have so many environments?

Before the look at preview environments, let's try to understand why we have multiple different environments. By understanding this, we will be able to appreciate the benefits of preview environments even more.

In a system that runs on Kubernetes, i.e. an application or multiple applications that use a microservice architecture, we have many different environments. These environments all have different functions and use cases. Some of the common environments include a production environment, a staging environment, a QA environment, a local development environment, etc. Each of these environments has a different use case.

For example, the main use case for a local development environment would be to write code for the application. We talked about the complexities of building a microservice application earlier. You would need to build up many individual services and connect them to see the full extent of the code changes. In a local environment, this can be done either by using a docker-compose service or a local Kubernetes cluster such as Kind or Minikube.

The QA environment would be concerned with making sure that all the components are working correctly or not. The staging environment would be used to test the features before they are added to production. As you can see, there are tons of different environments for applications. There might be even more environments depending on the needs of the applications.

As such, it can be difficult to efficiently manage so many different environments. The environments might not all be the same either, which can lead to some problems. For example, a local development environment runs at a much smaller scale than a production environment. While the production environment might be using 100 microservices due to scaling, a local environment would have only a fraction of that number. As such, it can be difficult to anticipate problems that might arise in the production environment.

Why consider using preview environments?

We already talked about so many different kinds of environments. Now let us talk about one more environment called preview, or ephemeral environments. These are temporary environments that live for a short period of time before getting destroyed. Why would we want to have these kinds of environments? Let's first try and understand the entire workflow without using preview environments.

The first step in the entire process to add a new feature or existing one would be to write the code for the application. This would be done by a developer, someone who understands how to read and write code. After doing a bit of local testing, they will push the code to their git repository, whether it's GitHub or GitLab, and then open a PR/MR to merge the code for the new feature to the upstream repository.

Assuming that the best practices for git workflows are being followed, this feature would be opened in a new branch in the upstream repository. This is where other developers will be able to review the code for this new feature, point out bugs and suggest some improvements. However, the main point to note, is that the code review is being done by other developers, who also understand how to read and write code. Product teams, designers or other stakeholders will not be able to make sense of this code.

Once other developers review the code, it would get merged into the new branch, and this new branch would be visible in one of your test environments such as the staging environment. At this stage, the product managers, designers and other non-technical teams would be able to view all the changes to the application, use it and make sure all the functionality works as expected, etc.

Now let's say that the designer finds something that is wrong with the design, or the product manager finds that certain functionality isn't working as expected. Now it is back to the developers to update the code to make sure the problems are fixed. However, developers will need to do the entire process all over again. They will need to make a new branch, open a new PR, get it reviewed once more, and then push it to staging again.

This is quite a tedious process and wastes a lot of time as well as resources. It can also be an expensive process as your preview environments which are running in Kubernetes would use up more resources. Imagine the benefit if the product and other non-technical teams were able to preview the application in the PR itself before it gets pushed to staging. This not only can save time and energy but can also save money in the long run.

This is the entire idea behind a preview environment. These environments are automatically created when you open a PR and get destroyed once your code is merged into the main branch. Thanks to these preview environments, other stakeholders of the product are able to view the changes and provide feedback, just as developers would provide code reviews.

Preview environments are not beneficial only to non-technical teams. Oftentimes, when developers are asked to provide code reviews, they might be working on some other features. In order to provide a review, they would need to clone the changed code, and run it locally, which would disrupt their own development tasks. With the help of preview environments, they wouldn't need to go through the additional steps of cloning, and building the project. They can simply use the same preview environment to see the changes, and the code at the same time and make live changes as required.

What are some preview environments that can be used?

One of the most simple use cases for preview environments is for previewing front-end applications. This is easy to do by using services such as Netlify and Vercel. These services let you preview your code changes even before you push the code into your branch. This lets you create changes to the front end and view it in real time.

However, a front end is just a monolith. The process of creating these preview environments gets difficult as the application gets distributed between multiple microservices. It might even be distributed over 100s of microservers which makes it increasingly difficult to create preview environments for them.

The problem of creating a preview environment is theoretically solved for a local computer. On your local system, you can very easily create a docker-compose file, and use docker-compose to deploy all the components of the application locally. However, this is limited to your local environment, which means you are the only one who is able to preview the application. A proper solution would be if these local implementations can somehow be used on the cloud.

This is exactly what Preevy by Livecycle does in order to create some preview environments. Preevy is able to take your Docker Compose files, and instead of running it on a local system, it runs it in a VM on the cloud. Preevy can also create its own HTTPS links which allows anyone from your team to access the preview website after authenticating. If your Docker Composer environment is configured correctly in a local environment, using Preevy is as simple as running a simple preevy up command instead of running docker-compose up as you would for a local environment. Preevy can also run on your Kubernetes cluster and create environments inside your cluster itself.

Some challenges with setting up preview environments

The main problem with adopting preview environments in your entire development workflow would just be to solve the same issues that you face while setting up local environments.

While creating a local docker-compose environment, there are a few challenges you might run into. These challenges can range from incorrect container build instructions to configuration issues or even an issue with how the containers talk with each other. Another challenge lies in working with data. As we know, containers are ephemeral, which means they don't work very well for storing data. This can lead to a few challenges while working with databases and applications that rely on data.

In a nutshell, the only challenges that you will face while setting up a preview environment, are the same ones you face while setting up a local environment. If your docker compose environment works without any issues, then your preview environment which is created by Preevy will work in the exact same way.

Another challenge with preview environments arises if your microservices are in different repositories. Let's say that your front end exists in one repository, and your back end is in another repository. This poses a challenge while connecting the two separate environments. This is a little easier to solve if all the different microservices exist within the same repository.

You also need to make sure that your preview environments are performant, while also not increasing costs. Since the preview environments use VMs, it's easy to potentially create 100s of preview environments which might increase the costs exponentially. In this case, it is important to create and destroy these preview environments quickly and not let them live for too long.

Conclusion

In order to optimize your development workflows, and allow other stakeholders to review changes to the application before pushing your code to a staging environment, it's important to use preview environments. They help reduce the time and effort needed to make a change, and changes can be made instantly within the PR itself.

Instead of pushing the changes to a staging environment and then getting the changes reviewed, you can simply review them inside the PR itself. This saves both time and energy and if done right, can save costs as well.

Try setting up some staging environments for your repositories using Preevy.

You can also check out the documentation to help you get started.

Why Developers Should Use Preview Environments

Zevi Reinitz — Thu, 27 Jul 2023 07:52:00 +0000

Check out the latest episode in the Open Source Cafe podcast, where Assaf Krintza (@assafkr - Co-founder & VP Engineering at Livecycle) sits down with Kunal Kushwaha to explore the world of preview environments.

Some of the topics covered in this episode:

An overview view of the various types of environments that developers encounter
What are preview environments and how can developers benefit from using them in their development process
About “Preevy” - an open source tool that simplifies the creation of preview environments
Some of the the pain points and challenges faced by developers that Preevy addresses
Preevy’s support for AWS, Azure, Google Cloud and K8s
Common misconceptions and myths surrounding preview environments
Several other gems

Watch this podcast episode here:

How to build and deploy a modern-day Next.js application

Andrew Baisden — Wed, 19 Jul 2023 14:41:17 +0000

Introduction

Making websites is not what it used to be. Over the past ten years, it has changed from being a very straightforward area controlled by HTML, CSS, and JavaScript to a vast ecosystem of tools and frameworks, each with its own distinct features and capabilities. You need to have a solid understanding of several cutting-edge technologies if you want to become an expert in modern web development. The complexity of today's development environment necessitates an agile mind and a strong commitment to lifelong learning, from data fetching to authentication, rendering to backend, and containerisation.

This article is for people who are ready to step up their game and genuinely understand the practices of a modern JavaScript developer. Next.js, Auth.js, Databases, GraphQL, Docker, and Preevy will all be covered in this guide. We'll look at the server-side rendering and static site creation with Next.js. Auth.js will assist us in unravelling the secrets of robust and secure user authentication. We'll reimagine how we interact with APIs and handle data via the perspective of GraphQL. Docker will show us the tremendous containerisation options, and Preevy will provide us with the ability to provision a preview environment for our application. Finally, we will do a production deployment on Vercel, and Netlify so that we can experience what it's like to have an application up and running on different platforms.

Are you ready to push the boundaries, test your knowledge, and possibly even redefine your perception of what current web development involves? Then strap in for a detailed review of understanding contemporary web programming. We will start by going over an introduction of each technology and then we will build an app to reinforce what we have learned.

The main aim of this article will be to create a simple application and then demonstrate the relationship between the tools. With this knowledge, you will be able to see how straightforward it is to deploy your Next.js applications online regardless of how basic or complex the codebase is.

In the upcoming sections, we will go through these topics related to building modern Next.js applications:

Using Next.js for web app development
Adding authentication with Auth.js
Databases for persisting state and storing data
GraphQL the modern alternative to REST APIs
Having a Docker development environment
Setting up Preevy to provision preview environments
Building and deploying our application

Using Next.js for web app development

Next.js is a framework for building server-side rendered React apps, making it suitable for generating quick and dynamic web applications. It's significant for web app development because it helps with things like page routing, server-side rendering, and quick loading times, which are critical for generating a great user experience. Additionally, it is simple to use and has a growing community of developers who are always striving to improve it. It has already replaced Create React App as the number one React build tool.

Building a web application is just one stage of the development process we also have to think about making our applications secure using authentication. Let's now learn about Auth.js, a new modern way to add an authentication layer to our applications.

Adding authentication with Auth.js

Auth.js is created by Vercel and is an open-source community project. It was originally called NextAuth.js until they rebranded and it is designed to be an authentication layer for the web. Auth.js helps developers to configure an authentication flow for their online projects. It is compatible with an extensive list of authentication providers along with additional choices. With Auth.js we can integrate many different providers into our applications, giving us the power to use them to log in and out. Some of the most well-known provider options include Google, GitHub, Facebook, Instagram and many more.

It currently supports frameworks like Next.js, Svelte.js and Solid.js with many more on the way. Let's now dive into databases and see why they are a good storage option for our data.

Databases for persisting state and storing data

When it comes to storing information, many people choose databases. Databases have become a crucial aspect of most applications, whether you want to store user data or keep track of the state. They assist you in organising your data and ensuring that it is secure and accessible when needed. Databases can be used for a variety of purposes, ranging from analytics to powering websites and apps. As a result, they have become an indispensable tool for developers and businesses.

Several databases are available, each with unique features that can either be or might not prove suitable for our needs. The most common is RDBMS (relational database management systems), which stores data in tables with various columns that can be connected together. NoSQL databases, on the other hand, provide more scalability and flexibility and additional possibilities for customising how your data is stored.

Whatever choice you use, databases are an essential resource for preserving state and storing data. Their ability to simplify and automate activities makes them worthwhile to consider when developing apps or services. And their dependability assures that your data will be protected and accessible for a long time.

Now that we have an introduction to databases, let's move on to learning about GraphQL and why it's the perfect modern alternative to REST APIs.

GraphQL the modern alternative to REST APIs

GraphQL is increasingly replacing conventional REST APIs as the preferred protocol. Instead of dealing with a vast and often burdensome payload of data, this powerful tool allows developers to request only what they need from an API. GraphQL also allows developers to query several resources at the same time via nesting, which can result in quicker and more efficient development. It also offers good documentation support, making it simple to understand and use, which makes GraphQL an appealing alternative for modern development.

Utilising GraphQL ensures that your technical stack is robust and up to date with current trends. With GraphQL, it is possible for it to be used on both the client and server sides. This means that you can choose to create a backend which will fetch the data from the API or you could have it running on the frontend so that you can skip creating a backend altogether. In this tutorial, we will use it on the front so there will be no need to create an Express.js backend server.

Another essential part of modern developer technical stacks is Docker. Let's keep reading and see how Docker can help us with our projects.

Having a Docker development environment

Docker development involves more than just setting up a single development environment. It is about ensuring that your whole development process can be efficiently replicated, reused, and automated. With the proper configuration, you'll be able to swiftly and consistently build various settings, eventually saving time and money in the long run.

Docker allows developers to bundle their apps into "containers" that contain all of the essential code and dependencies for running them in production. You no longer need to wonder whether it works locally and will also work when it goes live. These containers are lightweight and easy to move across servers, allowing you to test new features without affecting old ones. Everything is carefully wrapped up together.

The last section we will cover before we start building our app will be Preevy. Let's learn how this new tool can help us to provision our preview environments.

Setting up Preevy to provision preview environments

Preevy is created by LiveCycle and is used to assist development teams in improving their code-review operations by offering a simple and affordable approach to building temporary environments for each branch. These are also referred to as Preview Environments. Before merging changes on a branch, we can use preview environments to test, check, and see changes.

With Preevy, the difficulty of installing preview environments is decreased considerably, allowing all developers with a basic understanding of Docker to use it. We can create a development version via a URL which is typically appended to each pull/merge request. With this setup, we will have a version which is only for development and not production to play around with.

We will need to create an account with Amazon AWS so that we can use AWS Lightsail for the deployment. When using the aws-lightsail driver, Preevy can deploy virtual machines on AWS Lightsail. AWS Lightsail is Amazon's low-cost option for cloud-based virtual machines. AWS lightsail deployment time for a VM is typically under 2 minutes, and its monthly cost can be as cheap as $3.50, making them perfect for large-scale preview settings.

We now have a much greater understanding of what makes up a modern JavaScript full-stack application. It's time for us to start building our app so let's get to it!

Building and deploying our application

The app that we are going to build is an e-commerce website like Amazon. It will be a basic example with a few page routes, two of which will require GitHub or Google authenticated sign-in before you can see the data on the pages.

We will be using hard code data in place of a database layer just to make things easier in this project. If this was a production-level application then we would set up a real database layer. There is no CRUD functionality this app has page routing and the logic for logging in and out of authenticated routes. It is easy enough to create your own more advanced applications once you understand these fundamentals.

In addition, we are also going to be using the most up-to-date and latest App Router feature in Next.js which replaces the older Pages Router setup. So we get a feel for using the latest syntax and codebase Next.js has available to us. Vercel will get priority in the code because they are the creators of Auth.js although we will cover Netlify deployments later.

Firstly ensure that you are aware of the prerequisites and that you have your developer environment set up.

Prerequisites

Node.js
Next.js
Auth.js
Apollo GraphQL
Docker
Amazon Web Services (AWS) for AWS Lightsail deployments with Preevy
AWS CLI
Preevy
GitHub and Google account for setting up authentication
Vercel
Netlify

With the prerequisites out of the way let us now start building our app in the upcoming section.

Building the app

Firstly navigate to a directory on your computer like on the desktop so that we have a location to use for creating our project. Now run these commands to set up our project using Next.js.

mkdir store-project
cd store-project
npx create-next-app my-app

These are the settings I used:

✔ Would you like to use TypeScript with this project? … No / Yes
✔ Would you like to use ESLint with this project? … No / Yes
✔ Would you like to use Tailwind CSS with this project? … No / Yes
✔ Would you like to use src/ directory with this project? … No / Yes
✔ Use App Router (recommended)? … No / Yes
✔ Would you like to customize the default import alias? … No / Yes

Now we are going to create the files and folders that we will be using for this project run the following commands:

touch .dockerignore .env .gitignore docker-compose.yml
cd my-app
touch .env.local Dockerfile
cd src/app
mkdir account account/account account/rewards
mkdir api api/auth api/auth/"[...nextauth]"
mkdir components delivery graphql queries utils
touch account/account/page.js account/account/page.module.css
touch account/rewards/page.js account/rewards/page.module.css
touch api/auth/"[...nextauth]"/route.js
touch components/MainMenu.js components/mainmenu.module.css components/Provider.js
touch delivery/page.js delivery/page.module.css
touch graphql/route.js
touch queries/clientQueries.js
touch utils/cors.js utils/withApollo.js
touch not-found.js page.module.css
cd ../../

We should now be in the root folder for my-app so now we will install some packages for the project so run these commands here.

npm i @apollo/client @apollo/server @as-integrations/next graphql graphql-tag next-auth

With our basic setup done for our project, we can now focus on adding the code to our files which we will do now. This step can be tedious but we will be almost done afterwards this is the longest step. We will save the .env and .env.local files until last because they require some extra steps to be done first.

Open the store-project folder in your code editor and add this code to the .dockerignore file and the .gitignore file in the root folder:

# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.



# dependencies

/node_modules

/.pnp

.pnp.js



# testing

/coverage



# next.js

/.next/

/out/



# production

/build



# misc

.DS_Store

*.pem



# debug

npm-debug.log*

yarn-debug.log*

yarn-error.log*



# local env files

.env*.local



# vercel

.vercel



# typescript

*.tsbuildinfo

next-env.d.ts

Next, add this code to the docker-compose.yml file:

version: '3'

services:
  my-app:
    container_name: my-app
    build:
      context: ./my-app
      dockerfile: Dockerfile
    environment:
      NEXTAUTH_URL: ${NEXTAUTH_URL}
      NEXTAUTH_SECRET: ${NEXTAUTH_SECRET}
      GITHUB_ID: ${GITHUB_ID}
      GITHUB_SECRET: ${GITHUB_SECRET}
      GOOGLE_ID: ${GOOGLE_ID}
      GOOGLE_SECRET: ${GOOGLE_SECRET}
    volumes:
      - ./my-app/src:/app/src
      - ./my-app/public:/app/public
    restart: always
    ports:
      - 3000:3000

Put this code in the Dockerfile :

FROM node:18-alpine

WORKDIR /app

# Install dependencies based on the preferred package manager
COPY package.json yarn.lock* package-lock.json* pnpm-lock.yaml* ./
RUN \
  if [ -f yarn.lock ]; then yarn --frozen-lockfile; \
  elif [ -f package-lock.json ]; then npm ci; \
  elif [ -f pnpm-lock.yaml ]; then yarn global add pnpm && pnpm i; \
  # Allow install without lockfile, so example works even without Node.js installed locally
  else echo "Warning: Lockfile not found. It is recommended to commit lockfiles to version control." && yarn install; \
  fi

COPY src ./src
COPY public ./public
COPY next.config.js .

# Next.js collects completely anonymous telemetry data about general usage. Learn more here: https://nextjs.org/telemetry
# Uncomment the following line to disable telemetry at run time
# ENV NEXT_TELEMETRY_DISABLED 1

# Note: Don't expose ports here, Compose will handle that for us

# Start Next.js in development mode based on the preferred package manager
CMD \
  if [ -f yarn.lock ]; then yarn dev; \
  elif [ -f package-lock.json ]; then npm run dev; \
  elif [ -f pnpm-lock.yaml ]; then pnpm dev; \
  else yarn dev; \
  fi

Now we will replace the code inside of next.config.js with this so the app router feature is configured:

/** @type {import('next').NextConfig} */

const nextConfig = {
  output: 'standalone',
};

module.exports = {
  nextConfig,

  experimental: {
    appDir: true,
  },
};

module.exports = nextConfig;

Moving on let's do the files inside of the src/app directory now. Add this to account/account/page.js:

'use client';

import { useSession, signIn, signOut } from 'next-auth/react';

import { useQuery } from '@apollo/client';

import { GET_ACCOUNT } from '../../queries/clientQueries';

import withApollo from '../../utils/withApollo';

import MainMenu from '../../components/MainMenu';

import styles from './page.module.css';

const Account = () => {
  const { loading, error, data } = useQuery(GET_ACCOUNT);

  const { data: session, status } = useSession();

  const userEmail = session?.user?.email;

  if (loading)
    return (
      <>
        <MainMenu />

        <div className="container">
          <h1>Loading...</h1>
        </div>
      </>
    );

  if (error)
    return (
      <>
        <MainMenu />

        <div className="container">
          <h1>Oh no there is an error :(</h1>
        </div>
      </>
    );

  if (status === 'loading') {
    return <div>Please wait...</div>;
  }

  if (status === 'authenticated') {
    return (
      <>
        <MainMenu />

        <div className="container">
          <div className={styles.signinflow}>
            <p>Signed in as {userEmail}</p>

            <button onClick={() => signOut()} className={styles.signinflowbtn}>
              Sign out
            </button>
          </div>

          {!loading && !error && (
            <div>
              {data.account.map((account) => (
                <div key={account.id}>
                  <h1>{account.name}</h1>

                  <p>User ID: {account.id}</p>

                  <p>Country: {account.country}</p>

                  <p>Giftcard ID: {account.giftCardId}</p>

                  <p>Address: {account.address}</p>
                </div>
              ))}
            </div>
          )}
        </div>
      </>
    );
  }

  return (
    <>
      <MainMenu />

      <div className="container">
        <div className={styles.signinflow}>
          <button onClick={() => signIn('')} className={styles.signinflowbtn}>
            Sign in
          </button>

          <p>
            You are not currently signed in. Sign in here to view your profile.
          </p>
        </div>
      </div>
    </>
  );
};

export default withApollo(Account);

Put this in account/account/page.module.css:

.signinflow {
  background-color: #131921;

  padding: 0.5rem;

  color: #ffffff;
}

.signinflowbtn {
  border: none;

  padding: 0.5rem;

  background: #febd69;

  font-weight: bold;

  cursor: pointer;

  margin: 1rem;
}

For the rewards page add this to account/rewards/page.js:

'use client';

import { useSession, signIn, signOut } from 'next-auth/react';

import { useQuery } from '@apollo/client';

import { GET_REWARDS } from '../../queries/clientQueries';

import withApollo from '../../utils/withApollo';

import MainMenu from '../../components/MainMenu';

import styles from './page.module.css';

const Rewards = () => {
  const { loading, error, data } = useQuery(GET_REWARDS);

  const { data: session, status } = useSession();

  const userEmail = session?.user?.email;

  if (loading)
    return (
      <>
        <MainMenu />

        <div className="container">
          <h1>Loading...</h1>
        </div>
      </>
    );

  if (error)
    return (
      <>
        <MainMenu />

        <div className="container">
          <h1>Oh no there is an error :(</h1>
        </div>
      </>
    );

  if (status === 'loading') {
    return <div>Please wait...</div>;
  }

  if (status === 'authenticated') {
    return (
      <>
        <MainMenu />

        <div className="container">
          <div className={styles.signinflow}>
            <p>Signed in as {userEmail}</p>

            <button onClick={() => signOut()} className={styles.signinflowbtn}>
              Sign out
            </button>
          </div>

          {!loading && !error && (
            <div className={styles.vouchercontainer}>
              {data.rewards.map((vouchers) => (
                <div key={vouchers.id} className={styles.voucher}>
                  <div>
                    <div>
                      <p>Type: {vouchers.savingType}</p>

                      <p className={styles.voucherdescription}>
                        {vouchers.description}
                      </p>
                    </div>
                  </div>

                  <div>
                    <div>
                      {vouchers.info.map((data) => (
                        <div>
                          <p>Expiration Date: {data.valid}</p>

                          <p>
                            Code:{' '}
                            <span className={styles.vouchercode}>
                              {data.code}
                            </span>
                          </p>
                        </div>
                      ))}
                    </div>
                  </div>
                </div>
              ))}
            </div>
          )}
        </div>
      </>
    );
  }

  return (
    <>
      <MainMenu />

      <div className="container">
        <div className={styles.signinflow}>
          <button onClick={() => signIn('')} className={styles.signinflowbtn}>
            Sign in
          </button>

          <p>
            You are not currently signed in. Sign in here to view your rewards.
          </p>
        </div>
      </div>
    </>
  );
};

export default withApollo(Rewards);

This goes in account/rewards/page.module.css:

.signinflow {
  background-color: #131921;

  padding: 0.5rem;

  color: #ffffff;
}

.signinflowbtn {
  border: none;

  padding: 0.5rem;

  background: #febd69;

  font-weight: bold;

  cursor: pointer;

  margin: 1rem;
}

.vouchercontainer {
  display: flex;

  flex-flow: row nowrap;

  justify-content: center;

  margin-top: 2rem;
}

.voucher {
  background: #ffffff;

  border: 1px solid black;

  padding: 1rem;

  width: 100%;
}

.voucherdescription {
  color: rgb(59, 191, 26);

  font-weight: bold;
}

.vouchercode {
  color: rgb(191, 26, 26);

  font-weight: bold;
}

@media screen and (max-width: 1500px) {
  .vouchercontainer {
    flex-flow: row wrap;
  }
}

We will add this code to api/auth/[...nextauth]/route.js:

import NextAuth from 'next-auth';

import GithubProvider from 'next-auth/providers/github';

import GoogleProvider from 'next-auth/providers/google';

export const handler = NextAuth({
  providers: [
    GithubProvider({
      clientId: process.env.GITHUB_ID,

      clientSecret: process.env.GITHUB_SECRET,
    }),

    GoogleProvider({
      clientId: process.env.GOOGLE_ID,

      clientSecret: process.env.GOOGLE_SECRET,
    }),
  ],
});

export { handler as GET, handler as POST };

The components folder is next. Put this code in components/MainMenu.js:

import Link from 'next/link';

import styles from './mainmenu.module.css';

export default function MainMenu() {
  return (
    <nav className={styles.mainmenu}>
      <Link href="/" className={styles.link}>
        e-store
      </Link>

      <Link href="/delivery" className={styles.link}>
        Delivery
      </Link>

      <Link href="/account/rewards" className={styles.link}>
        Rewards
      </Link>

      <Link href="/account/account" className={styles.link}>
        Account
      </Link>
    </nav>
  );
}

Remaining in the same folder this is for components/mainmenu.module.css:

.mainmenu {
  background-color: #232f3e;

  padding: 0.5rem;

  display: flex;

  flex-flow: row nowrap;

  justify-content: space-around;
}

.link {
  color: #ffffff;

  text-decoration: none;
}

And this is going into components/Provider.js:

'use client';

import { SessionProvider } from 'next-auth/react';

const Provider = ({ children }) => {
  return <SessionProvider>{children}</SessionProvider>;
};

export default Provider;

The file inside of delivery/page.js gets this code:

'use client';

import MainMenu from '../components/MainMenu';

import styles from './page.module.css';

export default function Nutrition() {
  return (
    <>
      <MainMenu />

      <div className="container">
        <h1>Frequently Asked Questions</h1>

        <div className={styles.faqcontent}>
          <h2>
            Is free shipping on purchases over $25 available on all products?
          </h2>

          <p>
            Things sold and delivered by e-store are eligible, as are things
            sold by marketplace sellers when e-store is the dispatcher. You can
            combine qualifying goods worth less than $25 to produce an order
            worth more than $25 and qualify for free delivery.
          </p>
        </div>

        <div className={styles.faqcontent}>
          <h2>
            How can I order and pick up from an e-store Hub Locker or Gateway?
          </h2>

          <p>
            When you're all set to place your order, choose e-store Hub as your
            delivery address. We will send you an acknowledgement message with a
            barcode once your delivery arrives. Simply go to your chosen Locker
            or Gateway to pick up your package. Have your pickup message of
            confirmation with the barcode available when you arrive. You will
            scan the barcode yourself at the Locker; at the Gateway, the store
            clerk will check it before handing you your product. There is no
            need to provide identification while picking up.
          </p>
        </div>
      </div>
    </>
  );
}

And the CSS for delivery/page.module.css:

.faqcontent {
  margin-bottom: 1rem;
}

Let's do our GraphQL route file with our data. Put this in graphql/route.js:

import { ApolloServer } from '@apollo/server';

import { startServerAndCreateNextHandler } from '@as-integrations/next';

import { gql } from 'graphql-tag';

import allowCors from '../utils/cors';

const account = [
  {
    id: 'r89fdjk23r89yew234fg89h23',

    name: 'Mark Thomas',

    country: 'United States',

    giftCardId: '89dfviuhbbwerdfv897hwedfqdfqwf',

    address: `456 Maple Avenue, Austin, TX 78701`,
  },
];

const rewards = [
  {
    id: '1',

    savingType: 'Voucher',

    description: 'Save $2 at checkout',

    info: [
      {
        valid: '2023',

        code: '89wdfeqwh89fewh98fh',
      },
    ],
  },

  {
    id: '2',

    savingType: 'Voucher',

    description: 'Save 20% at checkout',

    info: [
      {
        valid: '2023',

        code: 'erfgerwgergewgewg345',
      },
    ],
  },

  {
    id: '3',

    savingType: 'Voucher',

    description: 'Save 25% at checkout',

    info: [
      {
        valid: '2023',

        code: '34fg67werf45y45ytg0a',
      },
    ],
  },

  {
    id: '4',

    savingType: 'Voucher',

    description: 'Save 5% at checkout',

    info: [
      {
        valid: '2023',

        code: 'er234dfrgdfsgerwerwge',
      },
    ],
  },

  {
    id: '5',

    savingType: 'Voucher',

    description: 'Save 50% at checkout',

    info: [
      {
        valid: '2023',

        code: 'gerwff4576jhey6233343',
      },
    ],
  },
];

// Define the GraphQL schema and resolvers

const typeDefs = gql`
  type Rewards {
    id: String

    savingType: String

    description: String

    info: [Rewards]
  }

  type Rewards {
    valid: String

    code: String
  }

  type Account {
    id: String

    name: String

    country: String

    giftCardId: String

    address: String
  }

  type Query {
    rewards: [Rewards]

    account: [Account]
  }
`;

const resolvers = {
  Query: {
    rewards: () => rewards,

    account: () => account,
  },
};

// Create the Apollo Server

const server = new ApolloServer({
  typeDefs,

  resolvers,
});

const handler = startServerAndCreateNextHandler(server, {
  context: async (req, res) => ({ req, res }),
});

export async function GET(request) {
  return handler(request);
}

export async function POST(request) {
  return handler(request);
}

export default allowCors(handler);

Following that file we have this code with our GraphQL queries which goes in queries/clientQueries.js:

import { gql } from '@apollo/client';

const GET_ACCOUNT = gql`
  query {
    account {
      id
      name
      country
      giftCardId
      address
    }
  }
`;

const GET_REWARDS = gql`
  query {
    rewards {
      id
      savingType
      description
      info {
        valid
        code
      }
    }
  }
`;

export { GET_ACCOUNT, GET_REWARDS };

Almost done just a few files remain. Now onto the utility files. Add this code to utils/cors.js:

const allowCors = (fn) => async (req, res) => {
  res.setHeader('Access-Control-Allow-Credentials', true);

  res.setHeader('Access-Control-Allow-Origin', '*');

  res.setHeader('Access-Control-Allow-Origin', req.headers.origin);

  res.setHeader(
    'Access-Control-Allow-Methods',

    'GET,OPTIONS,PATCH,DELETE,POST,PUT'
  );

  res.setHeader(
    'Access-Control-Allow-Headers',

    'X-CSRF-Token, X-Requested-With, Accept, Accept-Version, Content-Length, Content-MD5, Content-Type, Date, X-Api-Version'
  );

  if (req.method === 'OPTIONS') {
    res.status(200).end();

    return;
  }

  await fn(req, res);
};

export default allowCors;

Now this code will go inside of utils/withApollo.js:

import { ApolloClient, InMemoryCache, ApolloProvider } from '@apollo/client';

import { useMemo } from 'react';

import { SessionProvider } from 'next-auth/react';

export function initializeApollo(initialState = null) {
  const _apolloClient = new ApolloClient({
    // Local GraphQL Endpoint

    uri: 'http://localhost:3000/graphql',

    // Add your Preevy GraphQL Endpoint

    // uri: 'https://yourapp.livecycle.run/graphql',

    // Add your Vercel GraphQL Endpoint

    // uri: 'https://yourapp.vercel.app/graphql',

    // Add your Netlify GraphQL Endpoint

    // uri: 'https://yourapp.netlify.app/graphql',

    cache: new InMemoryCache().restore(initialState || {}),
  });

  return _apolloClient;
}

export function useApollo(initialState) {
  const store = useMemo(() => initializeApollo(initialState), [initialState]);

  return store;
}

export default function withApollo(PageComponent) {
  const WithApollo = ({ apolloClient, apolloState, session, ...pageProps }) => {
    const client = useApollo(apolloState);

    return (
      <SessionProvider session={session}>
        <ApolloProvider client={client}>
          <PageComponent {...pageProps} />
        </ApolloProvider>
      </SessionProvider>
    );
  };

  // On the server

  if (typeof window === 'undefined') {
    WithApollo.getInitialProps = async (ctx) => {
      const apolloClient = initializeApollo();

      let pageProps = {};

      if (PageComponent.getInitialProps) {
        pageProps = await PageComponent.getInitialProps(ctx);
      }

      if (ctx.res && ctx.res.finished) {
        // When redirecting, the response is finished.

        // No point in continuing to render

        return pageProps;
      }

      const apolloState = apolloClient.cache.extract();

      return {
        ...pageProps,

        apolloState,
      };
    };
  }

  return WithApollo;
}

Let's finish the last few files now. Replace all the CSS in globals.css with this one:

*,
*::before,
*::after {
  margin: 0;

  padding: 0;

  box-sizing: border-box;
}

html {
  font-size: 16px;
}

body {
  background: #e3e6e6;

  font-family: 'Istok Web', sans-serif;
}

.container {
  margin: 0 auto;

  width: 100%;

  max-width: 120rem;

  padding: 2rem;
}

Replace the code in layout.js with this code:

import './globals.css';

import { Istok_Web } from 'next/font/google';

const istok = Istok_Web({ subsets: ['latin'], weight: '400' });

export const metadata = {
  title: 'e-store App',

  description: 'Generated by create next app',
};

export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <body className={istok.className}>{children}</body>
    </html>
  );
}

This goes into not-found.js:

'use client';

import MainMenu from './components/MainMenu';

export default function NotFound() {
  return (
    <>
      <MainMenu />

      <div className="container">
        <h1>404 Page Not Found</h1>
      </div>
    </>
  );
}

We will put this code in our homepage file which is the page.js file in the app folder so replace it with this code you see here:

'use client';

import styles from './page.module.css';

import MainMenu from './components/MainMenu';

export default function Home() {
  return (
    <>
      <MainMenu />

      <div className="container">
        <main className={styles.maincontent}>
          <div className={styles.contentbox}>
            <h1>Sony WH-1000XM5 Noise Cancelling Wireless Headphones</h1>

            <p>
              For total convenience, these Bluetooth headphones can be paired
              with two devices at the same time.
            </p>
          </div>

          <div className={styles.contentbox}>
            <h1>PlayStation 5 Console</h1>

            <p>
              The PS5 console unleashes new gaming possibilities that you never
              anticipated
            </p>
          </div>

          <div className={styles.contentbox}>
            <h1>Xbox Series X</h1>

            <p>
              Introducing Xbox Series X, the fastest, most powerful Xbox ever.
            </p>
          </div>

          <div className={styles.contentbox}>
            <h1>SanDisk Extreme Pro 2TB Portable NVMe SSD</h1>

            <p>
              A forged aluminum chassis acts as a heat sink to deliver higher
              sustained speeds in a portable drive that’s tough enough to take
              on any adventure.
            </p>
          </div>

          <div className={styles.contentbox}>
            <h1>Apple 2023 MacBook Pro laptop M2 Pro</h1>

            <p>Take on demanding projects with the M2 Pro or M2 Max chip.</p>
          </div>

          <div className={styles.contentbox}>
            <h1>Samsung 43 Inch BU8000 UHD Crystal 4K Smart TV</h1>

            <p>
              Immerse Yourself In Exceptional Colour All In 4K - Dynamic Crystal
              Colour delivers a new level of UHD, allowing you to experience a
              billion shades of colour for a lifelike, vivid picture.
            </p>
          </div>
        </main>
      </div>
    </>
  );
}

And lastly, this goes into the page.module.css file in the app folder:

.contentbox {
  background-color: #ffffff;

  padding: 1rem;

  width: 100%;

  max-width: 60rem;

  margin: 0 1rem 1rem 1rem;
}

.maincontent {
  display: flex;

  flex-flow: row nowrap;

  justify-content: center;

  padding: 1rem;
}

@media screen and (max-width: 1500px) {
  .maincontent {
    flex-flow: row wrap;
  }
}

Thats it! The main files are completed! It's time to deal with those ENV files now this is where we will set our environment variables so that we can get the authentication working on restricted routes. The account and rewards page will have an authentication layer on them.

Authentication setup

Our application uses Auth.js for authentication. It's possible to have many different sign-in providers for your application. This app is set up to use GitHub and Google logins. You need an ID and secret key from GitHub and Google which we will then put in our ENV files. Read the documentation and find your ID and secrets. In my opinion, it is much easier to do it with GitHub and you only need one of them to work so that you can see the authentication working in the app.

GitHub Auth setup
Google Auth setup

Make sure that you pay attention to the Authorization callback URL. It will look different depending on where your app is running and you will need to update or change it on GitHub and Google otherwise the authenticated pages won't get access. See the examples below for GitHub:

Localhost URL:

http://localhost:3000/api/auth/callback/github

Preevy URL:

https://yourapp.livecycle.run/api/auth/callback/github

Vercel URL:

https://yourapp.vercel.app/api/auth/callback/github

When you have your ID and secrets add them to both ENV files so .env and .env.local. We need two because one is for local development and the other is for production. Just copy the same code into both. See the example below and modify it with your ID and secrets.

Just two more things to mention, we need a secret for our NEXTAUTH_SECRET variable it can be anything you want. Just randomly generate a string of characters like you would for a secure password. The NEXTAUTH_URL is required for Preevy deployments without it the authentication will go to localhost when it's deployed online which is incorrect and will stop the page loading.

In some cases, we can get the authentication to work without having the NEXTAUTH_URL variable in the ENV file altogether. But it will only work on localhost, Docker and Vercel so it's safer to just keep it in there. We have set NEXTAUTH_URL to http://localhost:3000/ because that is where we will run our app first.

NEXTAUTH_SECRET="yoursecret"

NEXTAUTH_URL="http://localhost:3000/"

GITHUB_ID="yourid"

GITHUB_SECRET="yoursecret"

GOOGLE_ID="yourid"

GOOGLE_SECRET="yoursecret"

The NEXTAUTH_URL variable will need to be changed depending on where our app is hosted and running.

See the examples here:

Localhost URL:

NEXTAUTH_URL="http://localhost:3000/"

Preevy URL:

NEXTAUTH_URL="https://yourapp.livecycle.run/"

Vercel URL:

NEXTAUTH_URL="https://yourapp.vercel.app/"

Everything should be complete now so let's run our app.

Running our app locally

To run our app locally go inside the my-app folder and run this command:

npm run dev

The GraphQL Apollo Server endpoint is here http://localhost:3000/graphql so we can test our GraphQL queries in development. We can also change this endpoint inside of the file in the directory utils/withApollo.js. This becomes important when our app is online on Preevy and Vercel.

To run our app inside of Docker first make sure Docker is running on your computer. Stop the other local development server from running first because you can't have two applications using port 3000. Then run this command inside of the store-project root folder with the docker-compose.yml file:

docker-compose up

Now let's see how to get it to work as a preview environment on Preevy.

Creating a preview build on Preevy

You can follow the Preevy set-up in the official documentation and take a look at the Preevy GitHub for more setup instructions. In this tutorial, we are using AWS Lightsail as our cloud host. The main Preevy commands are:

preevy init

## Add a flag and an id like 123
preevy up --id 123

Make sure that you add an id flag and a number afterwards otherwise, it could throw an error. Update the Authorization callback URL on GitHub and Google so it matches the Preevy URL that was generated and don't forget to change the NEXTAUTH_URL variable in the ENV file to the generated Preevy URL like this example:

NEXTAUTH_URL="https://yourapp.livecycle.run/"

Also can change the GraphQL endpoint inside of the file in the directory utils/withApollo.js to the URL endpoint for Preevy.

Run the command preevy up --id 123 to push the latest changes again.

We have done so much already it's now time to finish it off with deployment so let's work on that in the final section.

Deploying our app on Vercel

The Vercel setup is pretty straightforward. Firstly create a repository on GitHub. I named mine store-project and then run the GIT commands inside of the my-app folder to push it to GitHub.

See this GIT code example here:

git init
git add .
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/replacewithyourname/store-project.git
git push -u origin main

Then sign into Vercel and Add a new project.

Next import the repository you just created.

On the next screen configure your project and there is an option for environment variables so add all the environment variables in the ENV file to Vercel and then hit the deploy button.

Our app should be live on Vercel! However, the authenticated routes won't work yet we have to make some updates to the code like before.

Update the Authorization callback URL on GitHub and Google so it matches the Vercel URL that was generated this is the first step to get the authenticated pages working.

See the example here:

Homepage URL

https://store-project-qwerty.vercel.app/

Authorization callback URL

https://store-project-qwerty.vercel.app/api/auth/callback/github

Next, update the NEXTAUTH_URL variable on Vercel to the URL that Vercel generated for your app. You will find it under Settings > Environment Variables see the image for reference.

And finally like before don't forget to also change the GraphQL endpoint inside of the file in the directory utils/withApollo.js to the URL endpoint for Vercel.

export function initializeApollo(initialState = null) {
  const _apolloClient = new ApolloClient({
    // Local GraphQL Endpoint

    // uri: 'http://localhost:3000/graphql',

    // Add your Preevy GraphQL Endpoint

    // uri: 'https://yourapp.livecycle.run/graphql',

    // Add your Vercel GraphQL Endpoint

    uri: 'https://yourapp.vercel.app/graphql',

    // Add your Netlify GraphQL Endpoint

    // uri: 'https://yourapp.netlify.app/graphql',

    cache: new InMemoryCache().restore(initialState || {}),
  });

  return _apolloClient;
}

Now push the latest changes back to GitHub so that Vercel can rebuild your codebase with the new Vercel URL. Assuming you did everything correctly you should now see working authenticated routes for your app deployed on Vercel!

So with Vercel deployment complete let's do Netlify now.

Deploying our app on Netlify

Sign into Netlify and then import an existing project.

Next, connect to your GitHub and import the project you created.

Once again add in those ENV variables and hit deploy.

And just like before our app should be live on Netlify! We have the same problem as before though, the authenticated routes won't work yet we have to make some updates to the code like the previous section.

Firstly like in the Vercel example update the Authorization callback URL on GitHub and Google so it matches the Netlify URL that was generated for your app. Next, update the NEXTAUTH_URL variable on Netlify to the URL that Netlify generated for your app. You will find it under Site settings > Environment Variables see the image for reference.

And just like we did before don't forget to also change the GraphQL endpoint inside of the file in the directory utils/withApollo.js to the URL endpoint for Netlify.

export function initializeApollo(initialState = null) {
  const _apolloClient = new ApolloClient({
    // Local GraphQL Endpoint

    // uri: 'http://localhost:3000/graphql',

    // Add your Preevy GraphQL Endpoint

    // uri: 'https://yourapp.livecycle.run/graphql',

    // Add your Vercel GraphQL Endpoint

    // uri: 'https://yourapp.vercel.app/graphql',

    // Add your Netlify GraphQL Endpoint

    uri: 'https://yourapp.netlify.app/graphql',

    cache: new InMemoryCache().restore(initialState || {}),
  });

  return _apolloClient;
}

Finally, push the latest changes back to GitHub so that Netlify can rebuild your codebase with the new Netlify URL.

Assuming you did everything correctly you should now see working authenticated routes for your app deployed on Netlify!

If the authenticated route goes to http://localhost:3000/api/auth/callback/github or http://localhost:3000/api/auth/callback/google then in the Deploys section on Netlify press the Trigger deploy button and select Clear cache and deploy site and that should fix the error.

We are done! Our application is complete and we have a version deployed online on Vercel and Netlify good job! It might not be obvious but it's worth noting that the authentication part of our app will only work on Vercel or Netlify not both at the same time. We would have to duplicate the codebase and create a unique app for them on GitHub and Google to get them to work at the same time.

Conclusion

To summarise, current web development is an ever-changing profession that necessitates a grasp and command of a variety of tools and technologies. The ones we've looked at in this article Next.js, Auth.js, databases, GraphQL, Docker, and Preevy aren't exhaustive, but they're nonetheless important in modern web development settings. Vercel and Netlify are some of the many serverless deployment platforms that make it easy for us to deploy our production applications online so that the world can access them.

With its hybrid static and server rendering, Next.js provides a solid platform for developing scalable, high-performance apps. Auth.js simplifies the difficult work of user authentication, allowing developers to quickly add secure login features. Our database study revealed the need for organised data storage and retrieval, and GraphQL shone as an alternative to REST for developing flexible and efficient APIs. Docker, an essential technology for building isolated environments, is at the heart of today's software development and deployment cycle. Finally, Preevy, an emerging player in the pre-provisioning preview environment for static sites, can accelerate development build testing considerably.

Each of these technologies has distinct advantages and applications. The true value of these tools, however, is in their combination, when utilised successfully together, these tools can allow developers to design extremely efficient, performant, secure, and scalable online applications. Mastering these technologies is no easy task it takes time, effort, and a lot of practice. However, the payoff is well worth the effort. By becoming proficient in these tools, you are not only providing yourself with the abilities required to flourish in the present web development scene, but you are also preparing yourself for the future as these technologies advance and influence the world of web development.

So, keep researching, keep learning, and bear in mind that mastery in web development is a path of ongoing learning and adaptability.