Bringing F# Snippets under our roof, part 1
What is F# Snippets?
F# Snippets, an open-source community project started a few years ago by Tomas Petricek, is a website that aggregates useful F# code snippets contributed by the community. The snippets are usually short, concise chunks of code that demonstrate how to solve a specific problem with F#. The code view is enhanced with tooltips that provide hints about types and signatures. This feature, enabled by F# compiler services, further facilitates understanding of F# syntax and type system.
Tomas was looking to hand over the relay baton, that is, for someone else to take over the hosting and related expenses. As this clearly aligns with our mission to ensure that everyone involved in F# has a positive experience, we therefore offered to support in this regard.
In this series I go through the process of transfering the project under our hosting.
Exploring the stack
In a few emails and meetings between me and Tomas, I was given the lay of the land and ‘keys to the kingdom’, which is to say access to the GitHub repos and the existing deployment of the app in Tomas’ Azure subscription.
Fssnip comprises 3 different GitHub repos:
- fssnip-website, the webapp code
- fssnip-data, data backup repo
- fssnip-tools, which I did not interact with at all.
Fssnip-website is a Suave 2.5.6 app running on .NET Core 3.1. The project is built using FAKE; the data access layer is abstracted in such a way that it uses the local file system (when run in a local dev environment) or Azure blob storage (when running up in Azure) to access the collection of ~3000 snippets so far.
fssnip-data is where the state of the snippet collection is being committed to for backup. This is triggered manually.
On Azure side, the application is comprised of the following services:
- A Windows App Service plan
- A Storage account (to store the snippets)
- An App Insights instance with several Metric alert rules.
Even though these resources were not going anywhere anytime soon, I exported the ARM template of the resources, as I thought they might come in handy as reference for when I would be recreating the resources in our subscription.
Now with a decent overview of what the existing application looked like, the next step was to migrate the resources to our subscription, and see if we could put in place some improvements at the same time. Stay tuned for Part 2 to find out what happened next!
