Deploy to Azure Static Web Apps

Get Help and Help Others
#1

Since Azure Static Web Apps is still in preview, it is free to use for the time being.

Steps on how to deploy a Redwood app through Azure Static Web Apps:

Prerequisite: Azure & GitHub account, VS Code

  1. Install Azure Static Web Apps VS Code extension and follow “Create your first static web app” instruction on the extension page.

  2. When asked for the app folder name, enter “/” (without the quotes)

  3. When asked for the build artifact folder name, enter “web/dist” (without the quotes, take note that there is no slash before the ‘web’)

  4. After created successfully, pull changes from your GitHub repo because Azure will add a new file at the following path .github\workflows\azure-static-web-apps-*<some-random-value>*.yml

  5. Open the .github\workflows\azure-static-web-apps-*<some-random-value>*.yml file above, add the following line:
    app_build_command: yarn rw build
    under this section: jobs > build_and_deploy_job > steps > name > with
    You may refer this sample code or this screenshot :point_down:.

    image
    image954×576 36.4 KB

  6. Create a new config file staticwebapp.config.json at the root of the project with the following content:
    image
    The explanation of the code above can be found in the Fallback Routes section of the Azure Static Web Apps Documentation.

  7. Commit and push your code. Go to your GitHub Actions section you shall see 2 workflow runs, the first one failed because it doesn’t have the custom build command yet, the second successful with the custom build command. Sample link

    image
    image954×737 39.3 KB

  8. To view the published website, you may get the URL from your Azure portal or from the GitHub Action log > Build And Deploy

    image
    image831×524 33.5 KB

I’m still researching how to set up:

  1. API side to use Azure Functions

I will update here if I have any progress. In the meantime, feel free to share your config if you know how to do it. :grin::pray:

Following are some of my doubts:

  1. Why select location in Azure Static Web Apps?
6 Likes
#2

Thanks a lot for sharing @andrew-hh! I started looking at that forever ago and hit a roadblock at the Azure Functions step (and then life happened), I am looking forward to your updates :slight_smile:

2 Likes
#3

Thanks for posting this @andrew-hh! I know we’ve been looking at this for deployment and we appreciate you writing out these steps.

1 Like
#4

:sweat: I need some help in setting up the API side with Azure Functions, it’s too complex for me :cry:

#5

As someone who has gone down this path with a handful for different deployment providers you are definitely NOT the only one who finds this stuff complex.

For a lot of these deployment platforms we are working directly with the people building them and it requires a lot of understanding around both the platform and the framework.

Let us know what your blocker is and we’ll work it out :muscle:.

1 Like
#6

Azure Functions is expecting a different kind of folder structure that isn’t aligned with the dist folder structure which yarn rw deploy produced and I don’t know how to make that happen. :disappointed_relieved:

#7

Cool, I’ll follow along with the steps you’ve got outlined and see how far I get. I have a couple friends at Microsoft I can bug also.

Notes from Thomas:

You could not have asked a better question! My current project has a static site front end and Azure Functions backend.

Here is the repo

My approach so far is to deploy HTTP functions and call to them using code in the “actions” directory of my React code. I’m really taking the Grokking Simplicity book to heart there.

Here it is deployed

But it doesn’t do anything yet.

And I have a bug in the sign in code that causes a 500

Behind the scenes, they use something called Oryx to build. It’s what’s used on all Linux App Service apps (static or otherwise).

It’s open source so you can read through it if you need to, but you can write a config to tell it how to set up your app. It will detect the runtime based on the files and then (for node) run npm build.

It would also run through a similar set of commands for a Python, C#, Java, etc. app

1 Like
#8

Okay, it looks like we’re gonna end up writing a specific yaml file that’ll define the whole build, much like we’re doing with Render. I’ll touch base with Thomas this weekend and we should be able to work it out.

1 Like
#9

A million thanks @ajcwebdev :pray:

In the meantime, I’ve created a pull request to add config for RedwoodJS to the docs of Configure front-end frameworks and libraries with Azure Static Web Apps Preview.

1 Like
#10

Hi @andrew-hh,

I just got off of a call with @ajcwebdev where we tried to replace the Lambda service with Azure Functions. We made a bit of progress, but got stuck on (a) calls being proxied through the host port when running locally and (b) standing up the GraphQL server in an Azure Function.

What you have set up for the frontend is awesome. Super impressed on you getting that up and going.

As for running the service with Azure Functions replacing the Lambdas, it’s definitely possible. I would need a better understanding of how Redwood proxies calls to the API when it’s running locally and then I could work out how to fully replace the API layer.

I’m curious is there is a way to wrap the existing Lambdas so that they can be executed as Azure Functions (I don’t know if this is possible).

If we got a group together to try and work this out, I would be happy to be a part of it. We would definitely need to have a core dev to speed up the process. I have a lot of stupid questions to ask.

Ultimately, if we wanted Redwood to be easily deployable to Azure, we would need to create some alternate API template that would produce Azure Functions instead of Lambdas. It would be useful to gauge interest on that as it’s a sizable investment.

2 Likes
#11

Hi Thomas & @ajcwebdev,

Thanks for taking the time for trying it out.

I wonder if @peterp is able to lend a hand on this.

#12

Hi All! Excited to see people working on this. There’s more under the hood going on, which means this isn’t exactly a plug-n-play. I’m no expert on Azure either. So for now attempting to dump a lot of details to help others connect some dots.

I do not believe this is just a matter of replicating Redwood’s API Build process in a way that organizes functions specific to Azure.

Redwood’s API uses Apollo Server Lambda

If you look at the Redwood API package, you’ll see the GraphQL Server is apollo-server-lamba

Apollo has a distinct package for Azure Functions

Unfortunately, AWS and Azure functions are not equivalent:

I quickly dug into the code for each to verify there’s more going on than just naming:

:frowning_face:

Using Apollo Azure package

I believe the “right” way to do this will be to make the apollo-server swappable in Redwood’s API. As an experiment, one could fork Redwood and patch the API package to use Azure instead of AWS version.

Adding a “Wrapper”?

Maybe another POC path forward could be creating another package like @redwoodjs/api-server, which effectively uses Experess to server Lambda Functions. Take a look at awsLambda.ts to see how Peter does this.

I’m skeptical of this approach (admittedly very naive). Offering it as it might influence other ideas.

Using Azure Function Containers

This is likely the path of least resistance (although I don’t know how it compares to just Azure Functions).

Put the Redwood API in a container using api-server (self-hosting method). Might be a brutal start-up, but viable with tools we have right now.

1 Like
#13

I believe the “right” way to do this will be to make the apollo-server swappable in Redwood’s API. As an experiment, one could fork Redwood and patch the API package to use Azure instead of AWS version.

I agree that this sounds like the way to go.

2 Likes