Look into alternate, website-oriented, hosting and deployment tools

[neefrehman]

This is a follow-up form the conversation we had regarding hosting and deployment @FireFlower2012 @arthurharding. Having gotten acquainted a little bit with the codebase and current workflows, I know that we currently deploy a .NET application to Azure, that renders and serves the pages upon request. I've never worked with .NET before, so it was cool to take a peek into how it all comes together!

Looking again at the designs, and thinking about what the requirements of the site are, one thing that struck me is that there isn't much "dynamic" content, which would need rendering for each request. As a result, this might make the site a good candidate for static rendering, where we build the site once per deployment, and deploy its pages and resources as files to a CDN network. The big difference here is that there is no server to do rendering on the fly, and naturally a lot of other things are simpler as a result. A few services have cropped up in recent years to handle these kinds of deployments, like Netlify, Vercel or Cloudflare Pages. Below I give some pros and cons to using tools like these, and we can have a conversation about them in this issue :—)

Pros:

1. Because this kind of hosting is quite simple, it's usually free! For example, my last company's website was hosted on Netlify for years without exiting the free tier, and it got a decent amount of traffic.
2. Because we're only deploying static files, the CI/CD process is much simpler. The services I mention above all have GitHub integrations that will deploy each commit to the main branch automatically.
   • An extra bonus is that these services also deploy preview URLs for each PR, without any configuration, which is handy for checking contributions.
   • This would be how we keep the calendar events up-to-date, since they are checked into the repo. If we move them to an external CMS, we'd have to wire up a webhook to trigger a new build when a change is made.
3. DNS routing and SSL certification can be handled for us automatically.
4. These services do have provisions for running backend code via serverless functions, if we need to.
5. CDN networks are fast, so there's a performance benefit for users.
6. For similar reasons, static sites tend to have a much lower carbon footprint.
7. By absorbing infrastructural and deployment complexity, it gives us more opportunity to focus on the site itself, and to use more frontend-specific tooling to improve user and developer experience.

Cons:

1. No .NET support. A natural consequence of not having a server, is that there's no server code! Instead, we could just write out the raw HTML, CSS and JS files ourselves—or use some other frontend-specific frameworks that build static outputs—but this will definitely involve writing more javascript code for templating. If we're happier writing C#, this could be a dealbreaker.
   • Its worth noting that we could still deploy a .NET server to handle API requests for things like form submissions. Though, we may ideally want the hostname for the API endpoints to be the same as the site, to avoid XSS attacks or CORS issues. This may be quite fiddly to get the DNS configuration right for, if its even possible to do while maintaining the DNS/SSL benefits I mention above. It would certainly be easier if we use serverless function capabilities of the hosting providers.
2. Following on from above, there'd have to be a fairly large restructuring of the codebase to remove .NET and hoist out the HTML/CSS/JS in a "static-friendly" way. Not to be taken lightly!
3. Its too simple! There's something nice about owning this site end-to-end, especially from a learning perspective (for example, with me and .NET).

So, I'd be curious to hear everyone's thoughts on the above. I don't really have a strong opinion about what would be best, as we should definitely prioritise what the team is most comfortable with, but as you can probably tell I've had positive experience working with static deployments. Please also feel free to let me know if I've misunderstood anything about the current state-of-play, as I may have over stated some pros or understated some cons.

[Fireflower2012]

Initial thoughts (in no particular order)

Stripping out the current html/CSS into a static friendly version of the site would be pretty simple in it's current state. I've been holding off using most of the more .NET specific features and setting up reusable components etc until there's a finished site design.

If we go for the option of using embedded forms rather than the API version the need for a whole lot of yet to be added back end functionality goes away.

The current hosting for the dev site is using Azure App Services which is 'serverless' ( I hate the term, just because the server is hidden from you by a whole load of VM's and containers doesn't mean it's not still there! ). and I've got a pipeline set up to auto deploy when anything is merged to main. Don't know how or if this will work with Dreamhost though.

Code wise personally I'm much more comfortable with C# than js/typescript but wouldn't mind having a reason to play with something new.

Dynamic content wise, the current solution was very much intended as a temporary thing until the design is finished.

[arthurHarding]

Thanks neef. I don't know loads about web deployment tech, so some of this is a bit above my pay grade, but a couple things stand out:

• It would be really nice to have free, simple, light-weight hosting
• The Action Network API seems like it would add a bit of complexity to the set up. And if we were going to deploy a a server anyway, maybe it would be better to keep things as they are. The main problem with using embedded forms I think is the styling - have you looked at that Jane?
• We're going to integrate GoCardless on one of the pages, but I think that'll be a fairly simple embed
• Do we want to limit ourselves to static pages? For example, maybe we will change the calendar into something more dynamic. This feels like the biggest thing for me

The other thing is figuring out whether we can get Dreamhost to play nicely, because if not, we'll have to change things around anyway. Maybe I'll ask our new recruit Lewis to look at this

[Fireflower2012]

Done a bit more research on this and it looks like Dreamhost are running Apache servers and don't currently support .Net (core or framework) https://help.dreamhost.com/hc/en-us/articles/217141627-Supported-and-unsupported-technologies

Ref GoCardless. I haven't used them before, but based on past experience nothing about payment processing integration is simple, however their advertising makes it look! Last one I did took 2-3 weeks full time to get everything set up from scratch, not including testing.

[neefrehman]

Thanks both for your thoughts!

The current hosting for the dev site is using Azure App Services which is 'serverless' [...] and I've got a pipeline set up to auto deploy when anything is merged to main

Ok good to know @Fireflower2012! Nice that things seems on the simpler end in that case

Do we want to limit ourselves to static pages? For example, maybe we will change the calendar into something more dynamic. This feels like the biggest thing for me

Good callout @arthurHarding. Being honest I did use the least sophisticated end of the "static" spectrum to make my point, for simplicity's sake. There are a few ways to add dynamism with these kind of deployment tools. Going with the example of the calendar, we could:

1. Use a webhook to trigger a rebuild whenever the content changes. This would be the simplest approach, and should scale quite well.
2. Fetch some data in the browser that we use to render the calendar. Not ideal as the section wouldn't be part of the initial page load, and we'd need to handle things like authorization in a public way (if the request needs it)
3. Use a frontend framework that has server-side rendering support. Static was a bit of a misnomer, as these deployment platforms also support server-side rendering, though it would only using server-side JavaScript runtimes. An example of a framework that could do this is Astro.
   • I still would prefer option 1 over this, as it would be nice to keep the read-side for the site as a simple CDN request.

But in any case, sounds like things right now aren't overly complicated, and we're not that bought in to .NET which is good for flexibility. So no need to make any decisions right away!

[arthurHarding]

We've decided that we're gonna stick with what we've got for the dev site - git and azure