Spin up a Fullstack F# WebApp in 10 minutes with the CloudSeed Project Template
Date: 2025-01-31 | build | cloudseed | create | docker | falco | fsharp | modulith | postgres | webapp |
I've just pushed some big changes to CloudSeed for its v3 release and it's been awhile since my last CloudSeed Quickstart tutorial so here I wanted to share an updated version.
In this post we'll walk through spinning up a fullstack F# webapp in 10 minutes using CloudSeed and discuss its philosophy and some details about how to build apps with it.
CloudSeed Overview
CloudSeed is an F# project boilerplate for building fullstack webapps. CloudSeed's goal is to provide a seed from which to grow a simple, scalable webapp with F#. It provides the core components needed for most webapps (web framework, configuration, db upgrades) but avoids being too prescriptive so as to remain flexible for the majority of apps you might want to build.
System Architecture: Modulith (Modular Monolith) with vertical slices.
- Frontend: Whatever you like. CloudSeed's backend is a web server so you can build endpoints to return data or frontend markup / webapps as you wish.
- Backend: F# + Falco on ASP.NET
- DB: Postgres
Related: Build a Fullstack Webapp with F# + Falco
Hosting: Docker containers for simple "run-anywhere" development. If it runs on your machine, it can run on any machine with Docker installed (most clouds support this).
Again - CloudSeed is a "seed" for your app, not a fully grown tree. Its goal is to provide a simple, scalable foundation from which to build the app you want.
Running CloudSeed
CloudSeed assumes you have two things installed on your system:
- Docker - To be able to run Docker containers
- Docker Compose - Used to orchestrate the dev containers together
For details on installing these, check out the official Docker docs (it should take less than 5 mins to install and works across all major OS).
To run CloudSeed locally, you need one command: docker-compose down --remove-orphans && docker-compose build && docker-compose up
This spins up 2 services - a local development database so you can build / test locally on an env that mirrors prod and the backend App.
Once spun up, you can access each at its preconfigured endpoints:
- App -
localhost:5001
- Web test:
localhost:5001/health_web
- E2E DB test:
localhost:5001/health_db
- Example e2e webapp:
localhost:5001/sentinels
- Web test:
- DB -
localhost:5002
Of course no production app is complete without tests so we have a preconfigured testing project you can run with another command:
docker-compose -f docker-compose.test.yml down --remove-orphans && docker-compose -f docker-compose.test.yml build && docker-compose -f docker-compose.test.yml up
This basically does the same thing as the previous command but instead spins up a development database for testing and runs the test suite against it. Local testing databases are nice because it again allows us to write integration tests that test technologies that mirror what we'd run in prod - hopefully catching any compatibility issues early.
CloudSeed Code Walkthrough
We can't cover all the code in a 10 minute walkthrough but we can do a quick survey of some of the most important bits.
Program.fs
- This is the App's root / main. It spins up ASP.NET, pulls in Configuration, upgrades the database, builds services / injects dependencies, and configures Falco web framework with all endpoints.Configuration.fs
- Handles reading in the app configuration based on the environment.wwwroot
- Where you can store any static files you want to serve with your webapp (useful for things like CSS, favicons, or JS files)Infrastructure
- Holds shared infra across the app. Mostly DBUp configuration and upgrade scripts inDatabaseUpgradeScripts
Sentinels
- An example vertical slice so you can see how I like to build domains (you don't have to build this way if you don't want to).
Related: Getting Started with F# and Entity Framework
The Sentinels module is provided as an example of how I like to build vertical slices on CloudSeed. You do not have to build this way but I've found it to be a good pattern across many of my side projects.
It's made up of 3 files:
SentinelDomain.fs
- Contains the Domain Models followed by Persistence (here using Entity Framework for db access)SentinelService.fs
- Contains workflows / service functions for the domain. Follows a loose CQRS pattern here.SentinelPresentation.fs
- Contains SSR HTML code and exposes a list of endpoints to be consumed by the App's composition root inProgram.fs
The Sentinels module is intentionally simplistic and built to showcase various usages of CloudSeed's core components while being very easy to rip out when you no longer need it.
Next
That's a quick and dirty overview of CloudSeed, my F# webapp boilerplate I use to start most of my projects. This is how I like to build webapps but the approach / tools / technologies won't be everyone's cup of tea and that's okay.
If you liked this post you might also like:
Want more like this?
The best way to support my work is to like / comment / share for the algorithm and subscribe for future updates.