Building Real-World Applications in F#
It’s been a while since my last post and in this past few months, I have been exploring the F# language. I have gone through the different Pluralsight courses and at the moment I’m reading Expert F# 4.0. It’s been all good and I’m loving the language.
I’ve been having an Internal Struggle dropping my old Object Oriented habits namely the SOLID Principles. You see.. in C# whenever I started a Project, I would go through a ritual setting DI Containers, Separating Layers into Libraries e.t.c. It was a necessary evil but it was a ritual that could scale. I’ve used it from small demo applications to large scale payment platforms. In OO circles, this is referred to as the Clean Architecture.
In Idiomatic F# However, a lot of the specific practices of SOLID principles break down and I was stuck in a position where I had to ask myself
“Do I just do all the things I used to do or Do I rethink the way I assemble Applications”
The first option seemed like the most pragmatic way to proceed.. However I ran into a few problems
- The first problem is that If I reuse all my skills i.e. DI Containers, Interfaces, Mocks e.t.c. Then I would essentially be writing C# with an F# syntax.. Which wouldn’t be much good.
- The second problem is that in C# my existing legacy applications allowed me to have some inter-dependencies between layers but the F# compiler forbids this which means that porting an existing app will require a restrucuture of those parts.
- The third problem is that most of the libraries and frameworks that I’m used to are either heavily Object Oriented or Mutation Heavy. An Example of this is my favorite Data Access Library Entity Framework which is not only Mutation heavy but also requires Circular Dependencies between the Entities. In Idiomatic F#, I’d use a Type Provider but that’s a whole different way to think about Data Access. But then I’d lose some niceties like Code First Migrations and the ability to inspect generated SQL
- The fourth problem is that F# code is super concise with little in the way of “structure”. And as such it’s difficult to justify the heavy handedness in the segmentation of C# projects. For example, what is the point of having a full blown DLL that has only a single file in it? Trying to impose “structure” like classes and interfaces would only serve to introduce bloat. Also the F# approach of writing small scripts to test out functionality is lost when everything is hidden behind an interface
My goal in these series of blog posts is to document my research on how to answer these questions. To come up with a repeatable design process for Building Large Scale Applications without fighting with the Language, Libraries or Tools.
Already I have had some of these questions answered by
- “Look, No Mocks! Functional TDD with F#” — Mark Seeman
- “FSharp Phone-Cat Application” — Tamizhvendan S
The Sample Application I’ll be writing is an E-Commerce Website called Dumia. I’ll be using Angular and F# WebAPI to build it. The source Code for this will be on my github (https://github.com/odytrice/Dumia)
So that’s about it. Please note that as at the time I’m writing this. I have no answers to these problems and as such. If you have answer to any of them, kindly let me know in the comments.
Thanks
Series
