6 ms·

Build a web service with F# and .NET Core 2.0

122 points by LyalinDotCom 9y ago

bsaul 9y ago
i wish this was written 3 months ago. Knowing what tools and libs i should use when coding in f sharp to perform a simple crud web api really was frustratingly difficult (for something that should be at the homepage of any server side language). it made me quit and try a different language (swift), and now i think i'll stay in that boat. That's too bad, because i really liked the idea of coding in an ML family language.
- phillipcarter 9y ago
  Author here: Never hurts to give it a try again! Three months ago, .NET Core 2.0 hadn't actually shipped yet. Although it was certainly possible to write these sorts of things on .NET Core 1.0, there was a significant lack of APIs which prevented many people from using .NET Core. Now that 2.0 has been released, I figured it was as good a time as any to push the use of F# for web services. I'll also be posting next month about using Fable to write "full stack" F# with .NET Core (Fable compiling to JS, F# with the Suave library on the backend). It'll be a bit more involved (docker, deploying to Azure, etc.), so I hope that it's useful to folks. Perhaps after that's posted, you'd be interested in giving it another go?
  - Rapzid 9y ago
    In your opinion could Giraffe shape up to be a serious competitor to Phoenix Framework for mind share? If the F# community could get something like that off the ground I think it would do wonders for the platform. Also, what's your opinion of Fable vs TypeScript as far as support for interacting with existing libraries? Fable sounds very appealing, however all the momentum behind TypeScript, its type features aimed at typing in-the-wild js code, and the massive defintely typed project are hard to pass over..
    - ReedCopsey 9y ago
      One of the big strengths of Fable is that it can easily work with existing TypeScript bindings. ts2fable allows you to convert a TypeScript binding to be used with Fable, which allows you to leverage that mindshare easily.
      - Rapzid 9y ago
        I was/am worried about the type gymnastics the TypeScript team has done to support in the wild code not being compatible with systems like scalajs and Fable(F#). Giving it another look now though, it's pretty promising seeing that Alfonso has implemented erased union types and even opened an issue to have them added to F# :)
    - zghst 9y ago
      ML-based languages seems to be the trend these days, Facebook is getting behind ReasonML, I've seen a lot of progress with the F# community this year. It is my belief that time is on F#'s side.
    - phillipcarter 9y ago
      > In your opinion could Giraffe shape up to be a serious competitor to Phoenix Framework for mind share? I think it can, yes. Although, it is not the only technology for this. The other libraries mentioned in the article are also wonderful, and I recommend using them. I'm not one to play favorites, but I do agree that something like this would be helpful for F# mindshare. > Also, what's your opinion of Fable vs TypeScript as far as support for interacting with existing libraries? I think Fable has its place to grow, even though TS is absolutely killing it right now. Eventually, you hit a bit of a wall with TS in that it's not really a functional programming language. I believe that a lot of people in the JS world are looking for an ML-style language, and F# through Fable fits the bill there.
  - dvlsg 9y ago
    Looking forward to new articles! F# as a language is a pleasure to work with, and I really hope it catches on a bit more. Last time I tried implementing a web api in f# was with core 1.0, and it was fairly difficult to find a proper tutorial that was up to date. Hopefully 2.0 will bring a lot of more stable examples.
    - NicoJuicy 9y ago
      Second that, will look out for new posts!
    - bonesss 9y ago
      I believe that full dotnet core 2.0 support will be something of a watershed moment for F#... .Net on linux has a lot to say for hybrid cloud installations and cloud based development in .Net land. F# is a near-perfect match for many of the scalable, containerized, solutions one wants deploy. The F# community is fundamentally more cross platform, so there are a lot of impressive possibilities for best-of-breed solutions coming to a kubernetes cluster near you "any day now" :) Mono is great for what it is, but a unified cross platform VM built with an eye to cloud friendliness... That's gonna be something special.
  - bsaul 9y ago
    deployment is a really an important phase ( hint : if you add redundancy and platform monitoring you'll be perfect), but i'd recommend adressing two others important steps, which, imho, are more important than F# to js transpiling ( very few tech beyond node allow you to use the same language anyway) : - work queue ( or jobs or long running tasks or whatever you call them) : because most real world service need thoses - websockets : because live data stream is also pretty common those days.
- zghst 9y ago
  From enthusiast to enthusiast, I agree that the state of F# is quite frustrating, however the route I chose is to forgo traditional development, I'm just using functions (Azure + Serverless). In my view, using a cutting edge language means cutting edge solutions for better or worse.
Multicomp 9y ago
Look I'm no ML engineer or even a data scientist, I'm much closer to PS/VBS/AutoIT land, writing C# Console Applications for really complicated stuff and/or exposing helper methods via a simple web service, but I am increasingly liking F# for its pattern-matching and type providers that let me 'lock down' bugs much more than I can in imperative languages. I get that I'm probably misusing F# for general-purpose stuff, but no matter what I like that I can write my helper web-services in F# now and not just C#/VB. Hopefully F# will become even more mainstream than it is right now.
- zghst 9y ago
  I started out during the Node + JS revolution and I am more than certain I am seeing a similar level of innovation happening in F#. The community is titled towards more mathematicians and scientist, but mainstream adoption is right around the corner.
  - nulagrithom 9y ago
    I've been on an ASP.NET Core project full-time for a year. Lately, I find myself wondering "Would it be nicer to write this part in F#?" almost every day. There's some inertia there simply because I keep thinking that the next person will hate me for forcing F# on them, but it's almost a siren call at this point... I might have to just pull the trigger and commit a .fs file.
    - chillitom 9y ago
      Do it, the next person will thank you. If not immediately then within days of them learning F#.
    - phillipcarter 9y ago
      Author here: Go for it! Wiring up a new F# project is quite simple: dotnet new library -lang F# -o FSLib cd CSharpASPNETApp dotnet add reference ../FSLib/FSLib.fsproj There are some templates in the .NET Core SDK for ASP.NET as well, so if folks are wondering if it's possible to use F# with ASP.NET Core, the answer is yes! There's even support for async controller actions using F# async expressions, so there's no need to do some of the more awkward interop between Async and Task.
sremani 9y ago
Even though CLI improved with .net core 2.0, am I the only person feeling Interactive F# is missing? I know on Mono its fsharpi, but does .net core even has an equivalent ?
- msoucy 9y ago
  It seems that .NET Core still has no equivalent to fsharpi[0]. This is a feature that I also miss and would find helpful - I currently use fsi in visual studio as a replacement for opening up a calculator or using Python for scratch computation, and having the ability to run code directly from the IDE is nice. [0]: https://github.com/dotnet/cli/issues/3913 https://github.com/dotnet/cli/issues/3913
- phillipcarter 9y ago
  Author here: We haven't completed F# Interactive work for .NET Core yet. There are some big technical problems to solve there, and it's our top priority after we complete full support for the new project types in Visual Studio. Not timeline yet, but a workaround is to use fsharpi (from Mono) on unix or fsi.exe on Windows. Both use the same compiler that you get with .NET Core.
polskibus 9y ago
What's the recommended way of doing SOA/microservices in .NET world these days? Are people still using WCF mostly? Or is there a clear new winner? I'm searching for a new stack that will be both easy to work with, yet full of pluggable features if necessary (auth, async and non async channels, etc.). Since WCF is not present in .NET Core (will it ever be?), it would be good to find something solid that will last for as long as WCF did.
- zombieburger123 9y ago
  Azure Service Fabric replaces WCF. It takes all the good parts (like the interface-based programming model, interception pipeline etc.), throws out the unneeded complexity (around bindings, configuration etc.) and comes with built-in service discovery, fail-over, monitoring, deployment with rolling updates, and much more. It also supports the actor model with automatic state replication. Together with Azure Service Bus and CosmosDB it's the best stack for developing real-world .NET SOA systems.
  - polskibus 9y ago
    That is not open source though, kind of skewed toward cloud deployments too. I need a stack that works perfectly on-premises and does not need additional services or artifacts to deploy. Does ASF meet such requirements?
    - zombieburger123 9y ago
      Unfortunately I don't think SF meets your requirements. Even though you can run SF on-premises, this still requires you to install the SF cluster software on the nodes (VMs) that make up the cluster.
      - polskibus 9y ago
        Another issue is that MS can decide at any moment to withdraw on-prem SF like they did with Service Bus.
hdhzy 9y ago
Is there a recommended Docker base image that I can use to run F# web services?
- zghst 9y ago
  Any image with mono should be quite sufficient to run a F# Docker app. Pick any of the following Dockerfiles: https://hub.docker.com/_/mono/ https://hub.docker.com/_/mono/
  - hdhzy 9y ago
    Thanks! Are there any based on .NET Core? Not that I have anything against Mono but I'd like to get setup similar to what is described in the article.
    - piaste 9y ago
      There are official dotnetcore images. https://hub.docker.com/r/microsoft/dotnet/ https://hub.docker.com/r/microsoft/dotnet/
- chusk3 9y ago
  yeah, take a look at https://hub.docker.com/_/fsharp/ https://hub.docker.com/_/fsharp/ for the official images.
lenkite 9y ago
F# still doesn't have UWP support nor is supported by .NET native compiler.
- profquail 9y ago
  That may well be true, but that’s irrelevant for many developers (e.g., me) writing things like data analysis tools and backend services in F#.
  - bonesss 9y ago
    I'd go a step further: F# being slightly slow on the uptake of new shiney-shiney-shiney things from MS means you're less likely to hit solutions based on dead product lines and/or tech. A slight moderation in speed to avoid wasteful oscillations. I'm glad that the F# community uses its time making generalized cloud computing easier and more accessible and has smart data streaming solutions. I care 0% about windows platform apps, along with most of the world (given the sales and user stats). Not to mention: since you can always use C# and VB.Net as "glue code" with F# libraries behind that, you're generally only locked out of _pure_ F# solutions if you wanna play with the newest toys. It's bad for consultants who need 5 years experience in 3 day old tech to sell themselves. It's good business for companies trying to build value and not try to stick with technical fashion-trends for no reason.
- bonesss 9y ago
  F# does not need UWP support since MS have allowed ["desktop bridge" apps](https://github.com/Microsoft/visualfsharp/issues/1096 https://github.com/Microsoft/visualfsharp/issues/1096) (which may or may not signal the unofficial death of UWP...). The .NET native compiler has some issues with handling valid tail recursion MSIL commands IIRC - they're working on it. F# will always come in second in the MS tooling wars. Interesting, though, to follow the track record of MS techs that come in first in their tooling wars over the last decade... Maybe being a bit slow on the uptake of the "latest and greatest" EF, or Oslo models, or Silverlight, or WPF, or WCF, or dotnetcores new project format, or UWPs new APIs isn't the worst thing if you want your solutions to be supportable in production for a while.

122 points by LyalinDotCom 9y ago

i wish this was written 3 months ago. Knowing what tools and libs i should use when coding in f sharp to perform a simple crud web api really was frustratingly difficult (for something that should be at the homepage of any server side language). it made me quit and try a different language (swift), and now i think i'll stay in that boat. That's too bad, because i really liked the idea of coding in an ML family language.

phillipcarter 9y ago
Author here: Never hurts to give it a try again! Three months ago, .NET Core 2.0 hadn't actually shipped yet. Although it was certainly possible to write these sorts of things on .NET Core 1.0, there was a significant lack of APIs which prevented many people from using .NET Core. Now that 2.0 has been released, I figured it was as good a time as any to push the use of F# for web services. I'll also be posting next month about using Fable to write "full stack" F# with .NET Core (Fable compiling to JS, F# with the Suave library on the backend). It'll be a bit more involved (docker, deploying to Azure, etc.), so I hope that it's useful to folks. Perhaps after that's posted, you'd be interested in giving it another go?
- Rapzid 9y ago
  In your opinion could Giraffe shape up to be a serious competitor to Phoenix Framework for mind share? If the F# community could get something like that off the ground I think it would do wonders for the platform. Also, what's your opinion of Fable vs TypeScript as far as support for interacting with existing libraries? Fable sounds very appealing, however all the momentum behind TypeScript, its type features aimed at typing in-the-wild js code, and the massive defintely typed project are hard to pass over..
  - ReedCopsey 9y ago
    One of the big strengths of Fable is that it can easily work with existing TypeScript bindings. ts2fable allows you to convert a TypeScript binding to be used with Fable, which allows you to leverage that mindshare easily.
    - Rapzid 9y ago
      I was/am worried about the type gymnastics the TypeScript team has done to support in the wild code not being compatible with systems like scalajs and Fable(F#). Giving it another look now though, it's pretty promising seeing that Alfonso has implemented erased union types and even opened an issue to have them added to F# :)
  - zghst 9y ago
    ML-based languages seems to be the trend these days, Facebook is getting behind ReasonML, I've seen a lot of progress with the F# community this year. It is my belief that time is on F#'s side.
  - phillipcarter 9y ago
    > In your opinion could Giraffe shape up to be a serious competitor to Phoenix Framework for mind share? I think it can, yes. Although, it is not the only technology for this. The other libraries mentioned in the article are also wonderful, and I recommend using them. I'm not one to play favorites, but I do agree that something like this would be helpful for F# mindshare. > Also, what's your opinion of Fable vs TypeScript as far as support for interacting with existing libraries? I think Fable has its place to grow, even though TS is absolutely killing it right now. Eventually, you hit a bit of a wall with TS in that it's not really a functional programming language. I believe that a lot of people in the JS world are looking for an ML-style language, and F# through Fable fits the bill there.
- dvlsg 9y ago
  Looking forward to new articles! F# as a language is a pleasure to work with, and I really hope it catches on a bit more. Last time I tried implementing a web api in f# was with core 1.0, and it was fairly difficult to find a proper tutorial that was up to date. Hopefully 2.0 will bring a lot of more stable examples.
  - NicoJuicy 9y ago
    Second that, will look out for new posts!
  - bonesss 9y ago
    I believe that full dotnet core 2.0 support will be something of a watershed moment for F#... .Net on linux has a lot to say for hybrid cloud installations and cloud based development in .Net land. F# is a near-perfect match for many of the scalable, containerized, solutions one wants deploy. The F# community is fundamentally more cross platform, so there are a lot of impressive possibilities for best-of-breed solutions coming to a kubernetes cluster near you "any day now" :) Mono is great for what it is, but a unified cross platform VM built with an eye to cloud friendliness... That's gonna be something special.
- bsaul 9y ago
  deployment is a really an important phase ( hint : if you add redundancy and platform monitoring you'll be perfect), but i'd recommend adressing two others important steps, which, imho, are more important than F# to js transpiling ( very few tech beyond node allow you to use the same language anyway) : - work queue ( or jobs or long running tasks or whatever you call them) : because most real world service need thoses - websockets : because live data stream is also pretty common those days.
zghst 9y ago
From enthusiast to enthusiast, I agree that the state of F# is quite frustrating, however the route I chose is to forgo traditional development, I'm just using functions (Azure + Serverless). In my view, using a cutting edge language means cutting edge solutions for better or worse.

Multicomp 9y ago

Look I'm no ML engineer or even a data scientist, I'm much closer to PS/VBS/AutoIT land, writing C# Console Applications for really complicated stuff and/or exposing helper methods via a simple web service, but I am increasingly liking F# for its pattern-matching and type providers that let me 'lock down' bugs much more than I can in imperative languages. I get that I'm probably misusing F# for general-purpose stuff, but no matter what I like that I can write my helper web-services in F# now and not just C#/VB. Hopefully F# will become even more mainstream than it is right now.

zghst 9y ago
I started out during the Node + JS revolution and I am more than certain I am seeing a similar level of innovation happening in F#. The community is titled towards more mathematicians and scientist, but mainstream adoption is right around the corner.
- nulagrithom 9y ago
  I've been on an ASP.NET Core project full-time for a year. Lately, I find myself wondering "Would it be nicer to write this part in F#?" almost every day. There's some inertia there simply because I keep thinking that the next person will hate me for forcing F# on them, but it's almost a siren call at this point... I might have to just pull the trigger and commit a .fs file.
  - chillitom 9y ago
    Do it, the next person will thank you. If not immediately then within days of them learning F#.
  - phillipcarter 9y ago
    Author here: Go for it! Wiring up a new F# project is quite simple: dotnet new library -lang F# -o FSLib cd CSharpASPNETApp dotnet add reference ../FSLib/FSLib.fsproj There are some templates in the .NET Core SDK for ASP.NET as well, so if folks are wondering if it's possible to use F# with ASP.NET Core, the answer is yes! There's even support for async controller actions using F# async expressions, so there's no need to do some of the more awkward interop between Async and Task.

sremani 9y ago

Even though CLI improved with .net core 2.0, am I the only person feeling Interactive F# is missing? I know on Mono its fsharpi, but does .net core even has an equivalent ?

msoucy 9y ago
It seems that .NET Core still has no equivalent to fsharpi[0]. This is a feature that I also miss and would find helpful - I currently use fsi in visual studio as a replacement for opening up a calculator or using Python for scratch computation, and having the ability to run code directly from the IDE is nice. [0]: https://github.com/dotnet/cli/issues/3913 https://github.com/dotnet/cli/issues/3913
phillipcarter 9y ago
Author here: We haven't completed F# Interactive work for .NET Core yet. There are some big technical problems to solve there, and it's our top priority after we complete full support for the new project types in Visual Studio. Not timeline yet, but a workaround is to use fsharpi (from Mono) on unix or fsi.exe on Windows. Both use the same compiler that you get with .NET Core.

polskibus 9y ago

What's the recommended way of doing SOA/microservices in .NET world these days? Are people still using WCF mostly? Or is there a clear new winner? I'm searching for a new stack that will be both easy to work with, yet full of pluggable features if necessary (auth, async and non async channels, etc.). Since WCF is not present in .NET Core (will it ever be?), it would be good to find something solid that will last for as long as WCF did.

zombieburger123 9y ago
Azure Service Fabric replaces WCF. It takes all the good parts (like the interface-based programming model, interception pipeline etc.), throws out the unneeded complexity (around bindings, configuration etc.) and comes with built-in service discovery, fail-over, monitoring, deployment with rolling updates, and much more. It also supports the actor model with automatic state replication. Together with Azure Service Bus and CosmosDB it's the best stack for developing real-world .NET SOA systems.
- polskibus 9y ago
  That is not open source though, kind of skewed toward cloud deployments too. I need a stack that works perfectly on-premises and does not need additional services or artifacts to deploy. Does ASF meet such requirements?
  - zombieburger123 9y ago
    Unfortunately I don't think SF meets your requirements. Even though you can run SF on-premises, this still requires you to install the SF cluster software on the nodes (VMs) that make up the cluster.
    - polskibus 9y ago
      Another issue is that MS can decide at any moment to withdraw on-prem SF like they did with Service Bus.

hdhzy 9y ago

Is there a recommended Docker base image that I can use to run F# web services?

zghst 9y ago
Any image with mono should be quite sufficient to run a F# Docker app. Pick any of the following Dockerfiles: https://hub.docker.com/_/mono/ https://hub.docker.com/_/mono/
- hdhzy 9y ago
  Thanks! Are there any based on .NET Core? Not that I have anything against Mono but I'd like to get setup similar to what is described in the article.
  - piaste 9y ago
    There are official dotnetcore images. https://hub.docker.com/r/microsoft/dotnet/ https://hub.docker.com/r/microsoft/dotnet/
chusk3 9y ago
yeah, take a look at https://hub.docker.com/_/fsharp/ https://hub.docker.com/_/fsharp/ for the official images.

lenkite 9y ago

F# still doesn't have UWP support nor is supported by .NET native compiler.

profquail 9y ago
That may well be true, but that’s irrelevant for many developers (e.g., me) writing things like data analysis tools and backend services in F#.
- bonesss 9y ago
  I'd go a step further: F# being slightly slow on the uptake of new shiney-shiney-shiney things from MS means you're less likely to hit solutions based on dead product lines and/or tech. A slight moderation in speed to avoid wasteful oscillations. I'm glad that the F# community uses its time making generalized cloud computing easier and more accessible and has smart data streaming solutions. I care 0% about windows platform apps, along with most of the world (given the sales and user stats). Not to mention: since you can always use C# and VB.Net as "glue code" with F# libraries behind that, you're generally only locked out of _pure_ F# solutions if you wanna play with the newest toys. It's bad for consultants who need 5 years experience in 3 day old tech to sell themselves. It's good business for companies trying to build value and not try to stick with technical fashion-trends for no reason.
bonesss 9y ago
F# does not need UWP support since MS have allowed ["desktop bridge" apps](https://github.com/Microsoft/visualfsharp/issues/1096 https://github.com/Microsoft/visualfsharp/issues/1096) (which may or may not signal the unofficial death of UWP...). The .NET native compiler has some issues with handling valid tail recursion MSIL commands IIRC - they're working on it. F# will always come in second in the MS tooling wars. Interesting, though, to follow the track record of MS techs that come in first in their tooling wars over the last decade... Maybe being a bit slow on the uptake of the "latest and greatest" EF, or Oslo models, or Silverlight, or WPF, or WCF, or dotnetcores new project format, or UWPs new APIs isn't the worst thing if you want your solutions to be supportable in production for a while.