Music Store Tutorial

[Ryan Riley]

Anyone interested in writing a Music Store Tutorial for F# similar to the one written by the ASP.NET team? We need to determine what framework(s) to use and should consider adding some cool stuff from the ML group such as a recommendation engine. It's possible we could write a generic tutorial structure and build several, similar implementations using different frameworks; it's something to consider, anyway.

Cheers,

Ryan

[Isaac Abraham]

Great idea. What / who would target audience be? If towards the existing ASP .NET community perhaps one demo would be to try to target the typical data-driven website that many devs use. How that would be done is an interesting question because obviously Razor etc. is a no-go (AFAIK) for presentation tier purposes. But for the backend this would be an excellent opportunity to demonstrate type providers for sourcing data, and records etc. as a means to expose data easily. For such a demo I would be wary of putting in anything ML in as that might muddy the waters somewhat.

I like the idea of a generic tutorial structure though - would help a lot.

[edgar.y...@hotmail.com]

Well, we do have the F# ASP.NET MVC 5 and Web API 2 template to start with...

[Karlkim Suwanmongkol]

I am interested. Who will be your target audience? Are we thinking about introducing F# to C# web developers or showing how much F# we can use to create ASP.NET web application?

[Adam Granicz]

Such a sample app/tutorial is long overdue on the WebSharper site, so I am happy to write that implementation when the target application idea is settled.

--
You received this message because you are subscribed to the Google Groups "F# Web Stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-stack-fs...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Adam Granicz, IntelliFactory
www.intellifactory.com

[Quintus Marais]

HI 

I think a comprehensive tutorial giving  strong guidance on how to do full stack F# web development is sorely needed.  This should show how to do:

• Web pages
• API's
• SPA
• Database access for relational and NoSQL databases
• Authentication and Authorisation  using something like OpenID connect

At the moment  the F# web story is very confusing for any newcomer.

[ry...@tachyus.com]

On Monday, September 8, 2014 7:53:38 AM UTC-5, Quintus Marais wrote:

HI 

I think a comprehensive tutorial giving  strong guidance on how to do full stack F# web development is sorely needed.  This should show how to do:

• Web pages
• API's
• SPA
• Database access for relational and NoSQL databases
• Authentication and Authorisation  using something like OpenID connect

That looks like a good list of topics, though I would add a bit about focusing on building the core library, as well.

 

At the moment  the F# web story is very confusing for any newcomer.

I don't think this is unique to F# compared with other languages in .NET. I find the level of documentation is sub-par compared to docs and samples that target C#. For the most part, things that work with C# work for F#, though project templates are lacking. The bigger challenge is that F# is so much more powerful for this sort of programming that the C#-style just feels clunky, and we don't have enough samples highlighting this problem.

[Ryan Riley]

The Music Store sample is getting an update for Project K / ASP.NET vNext. I am more convinced this is the correct sample project.

[Ryan Riley]

On Thursday, September 4, 2014 3:34:12 PM UTC-5, Isaac Abraham wrote:

Great idea. What / who would target audience be? If towards the existing ASP .NET community perhaps one demo would be to try to target the typical data-driven website that many devs use.

I would like to try to cover as many cases as possible. One way to do this might be to follow the suggestion that the best way to learn programming is to pick an existing project and attempt to make a change or add a feature. Taking that perspective, we could start with an existing application, e.g. the Music Store, and suggest we need to "modernize" it. We could then proceed through the following, proposed structure:

1. Build the core - this focuses on F# syntax, functional programming as excellent for programming in-the-small. This would create a separate library for managing the catalog and then the store, plugging in the library to the web app to expose it on the web.
   
2. Improved data access - Try something like FSharp.Data.SqlClient and/or SqlProvider as a different means of hitting SQL-based data stores. This could also cover changes to accommodate NoSQL storage where that makes more sense.
3. Rich web front-end - separate the app into a set of web APIs and a front-end app using, say, Angular. Build the entire back-end in F#, replacing the MVC controllers with another approach. This is where it would be nice to have a choose-your-own-adventure sort of approach with a very general structure highlighting:
1. HTTP handlers
2. HTTP resources
3. Routing
4. Middleware
5. Hosting
4. F# front-end - Create tutorials for using FunScript and WebSharper as separate, choose-your-own-adventure modules to add to the tutorial.

In each of these, I think we could point out new pieces of F# for true beginners and add sidebars for experienced C# devs to help them understand why we made a change and how it relates to what they know from C#. Some modules, such as moving to Web API, may be an almost C# -> F# adventure, whereas something like Dyfrig, Frost, or Frank may be aimed more at newcomers.

Thoughts?

 

How that would be done is an interesting question because obviously Razor etc. is a no-go (AFAIK) for presentation tier purposes. But for the backend this would be an excellent opportunity to demonstrate type providers for sourcing data, and records etc. as a means to expose data easily.

I am not sure I follow as to why Razor is a no-go, though as you can see I essentially ignore it by moving from MVC to a SPA. I'm assuming static HTML or something similar to what you (Isaac) are currently blogging.

 

For such a demo I would be wary of putting in anything ML in as that might muddy the waters somewhat.

 

Fair point wrt including ML. Perhaps that could be a separate, aside referenced sample for those interested.

I like the idea of a generic tutorial structure though - would help a lot.

Does the structure presented above, though obviously very high-level, help a bit? Would you make any changes?

Cheers!

Ryan 

[Quintus Marais]

I think it  is important that the sample include showing how to deal with authentication and authorization in a modern way i.e. using something like oauth2 or OpenID connect.  Every app out there needs this, it is a minefield for unexperienced developers and no samples show how this works.  BTW  i am willing to put in some time on this project if a can be usefull, even though I am not an experienced developer at this level.  Even if I can just help with documentation

[Ryan Riley]

On Sep 11, 2014, at 12:14 PM, Quintus Marais wrote:

I think it  is important that the sample include showing how to deal with authentication and authorization in a modern way i.e. using something like oauth2 or OpenID connect.  Every app out there needs this, it is a minefield for unexperienced developers and no samples show how this works.  BTW  i am willing to put in some time on this project if a can be usefull, even though I am not an experienced developer at this level.  Even if I can just help with documentation

I would appreciate the help! I would caution you on use of OAuth2 and OpenID Connect. They are common but should be used when you need to provide social logins. If you are building your own security, I would highly recommend Hawk. The creator of Hawk has an excellent description of the topic.

[james...@gmail.com]

I think what is missing from the tutorial as proposed is playing to F# strengths from a C# dev point of view.  One of the problem with using C# imperative is you get a bunch of spaghetti code for all of your business rules. Moving to an OO solution using design patterns leads to different sets of problems -> specifically deeply nested hierarchies and overly complex constructs that have nothing to do with solving the problem.  I think showing discriminated unions and pattern matching would be awesome -> assuming that there is actually business rules in the original app.  If not, we would have to build some.  Also, once that is done, we could show functional composition.  I think Scott W's Railway Oriented Programming would be great -> there are plenty of web devs who think off the happy path and hate the amount of code bloat you get with structured exception handling.

I think simply showing how to do the same thing in F# from C# is not a good enough case to get people to switch.  I think they will switch if F# removed some of the larger pain points in using C#:

1) Everyone hates the amount of work/code/files Entity Framework brings (Type Providers)

2) Everyone hates the amount of work/code it takes to build good business rules that are 100% correct and then exten them (Pattern Matching and Discriminated Unions)

3) Everyone hates the amount of work/code it takes to do structured exception handing (ROP)

4) Everyone hates the bloat of XML code comments (not sure how to do in F# better)

[Dave Thomas]

One thing though, showing how to use F# even if quite similar to C# is a starting point, documentation is quite lacking on F#.  Ive heard this mentioned a lot, as well as mentioned go poor MSDN docs too.

[Isaac Abraham]

That’s true, although I believe MS are now accepting pull requests for the MSDN docs for F# - Ryan, I believe that you had some PRs accepted on this recently?

[Isaac Abraham]

The data access story is an interesting one in that there are several sub-stories for F# that meet different needs. For example, the EF provider is (IMHO) a decent option if you want to do a “lift-and-shift” from an EF4 C# / VB library. However, there are so many other SQL TPs out there. Ross’s one is in some ways similar to a conventional ORM albeit it adds several very nice features on top. On the other hand the SQL TP is possibly a better fit for e.g. CQRS-style models where you don’t want to have some pervasive domain model that lives in the DB and everything comes from. Certainly from a Web API point of view, where you might have multiple renderings of your data, it made more sense to me to use that one instead.

 

From: web-st...@googlegroups.com [mailto:web-st...@googlegroups.com] On Behalf Of james...@gmail.com
Sent: 15 September 2014 12:39
To: web-st...@googlegroups.com
Subject: Re: Music Store Tutorial

 

I think what is missing from the tutorial as proposed is playing to F# strengths from a C# dev point of view.  One of the problem with using C# imperative is you get a bunch of spaghetti code for all of your business rules. Moving to an OO solution using design patterns leads to different sets of problems -> specifically deeply nested hierarchies and overly complex constructs that have nothing to do with solving the problem.  I think showing discriminated unions and pattern matching would be awesome -> assuming that there is actually business rules in the original app.  If not, we would have to build some.  Also, once that is done, we could show functional composition.  I think Scott W's Railway Oriented Programming would be great -> there are plenty of web devs who think off the happy path and hate the amount of code bloat you get with structured exception handling.

--

[Christopher Stevenson]

Well, F# has the one line xml comment for summaries.

[Ryan Riley]

On Monday, September 15, 2014 6:38:44 AM UTC-5, Jamie Dixon wrote:

I think what is missing from the tutorial as proposed is playing to F# strengths from a C# dev point of view.  One of the problem with using C# imperative is you get a bunch of spaghetti code for all of your business rules.

We would have to clarify what you mean by spaghetti, but I generally agree.

 

Moving to an OO solution using design patterns leads to different sets of problems -> specifically deeply nested hierarchies and overly complex constructs that have nothing to do with solving the problem.  I think showing discriminated unions and pattern matching would be awesome -> assuming that there is actually business rules in the original app.  If not, we would have to build some.

I think this would be useful, but we may find that the business rules are so simple as to not show this very well. An add-on project focused on a recommendation engine might do this more justice.

 

Also, once that is done, we could show functional composition.  I think Scott W's Railway Oriented Programming would be great -> there are plenty of web devs who think off the happy path and hate the amount of code bloat you get with structured exception handling.

Agreed on ROP.

 

I think simply showing how to do the same thing in F# from C# is not a good enough case to get people to switch.  I think they will switch if F# removed some of the larger pain points in using C#:

1) Everyone hates the amount of work/code/files Entity Framework brings (Type Providers)

2) Everyone hates the amount of work/code it takes to build good business rules that are 100% correct and then exten them (Pattern Matching and Discriminated Unions)

3) Everyone hates the amount of work/code it takes to do structured exception handing (ROP)

4) Everyone hates the bloat of XML code comments (not sure how to do in F# better)

Excellent points, though sadly I don't think everyone really does hate those things. I think we could at least prove a better way exists, even to the hold-outs. :) 

[Ryan Riley]

On Monday, September 15, 2014 7:27:51 AM UTC-5, Isaac Abraham wrote:

That’s true, although I believe MS are now accepting pull requests for the MSDN docs for F# - Ryan, I believe that you had some PRs accepted on this recently?

I wish. I haven't had time. I think Reed Copsey had some PRs accepted, though. The bigger point is that MSDN is accepting contributions to docs. We should include that as part of our goals.

[Isaac Abraham]

Ah yes, it was Reed – apologies for the confusion on my behalf there! And yes, docs are important J

 

From: web-st...@googlegroups.com [mailto:web-st...@googlegroups.com] On Behalf Of Ryan Riley
Sent: 23 September 2014 16:28
To: web-st...@googlegroups.com
Subject: Re: Music Store Tutorial

 

On Monday, September 15, 2014 7:27:51 AM UTC-5, Isaac Abraham wrote:

That’s true, although I believe MS are now accepting pull requests for the MSDN docs for F# - Ryan, I believe that you had some PRs accepted on this recently?

I wish. I haven't had time. I think Reed Copsey had some PRs accepted, though. The bigger point is that MSDN is accepting contributions to docs. We should include that as part of our goals.

--

[tomek.h...@gmail.com]

Is there any update to the topic?

I'm gonna write Master Thesis on "Application of Functional Programming to Business Applications Development" next year and thought I could create such tutorial on how to write F# Web app, and then refer to it in my master's work.

Do you think that's a good idea? 

[Jamie Dixon]

That is a an awesome idea.  And you can use my Nerd Dinner demo for any ideas.  Good luck!

--
You received this message because you are subscribed to a topic in the Google Groups "F# Web Stack" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web-stack-fs/gcthe2nhs9M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web-stack-fs...@googlegroups.com.

[Ryan Riley]

On Wed, Oct 29, 2014 at 10:40 AM, <tomek.h...@gmail.com> wrote:

Is there any update to the topic?

I'm gonna write Master Thesis on "Application of Functional Programming to Business Applications Development" next year and thought I could create such tutorial on how to write F# Web app, and then refer to it in my master's work.

Do you think that's a good idea?

That's a fantastic idea! I'm still planning to get this started, probably on my next flight; however, we will need and want more than one tutorial, and my general premise is to follow the open / closed principle. :) I hope others will extend on the skeleton I build. 

[Tomek Heimowski]

Cool, I'll start gathering ideas then while watching updates on the topic here

--

[emai...@gmail.com]

As a new comer to F# from the C# ASP.NET world, this hits the nail on the head. I've decided to slowly try and introduce it into the workplace as a way to remove a lot of the extra boilerplate we have to write with C#.

What I'm finding though, is that while available tutorials give a good intro over what's possible, they stop short of showing best implementation practices.
For example, using the SQL data type provider is FANTASTIC; but there aren't clear examples showing how to use it with a repository pattern or to then map the result to a ViewModel.

[Isaac Abraham]

Good point. Oftentimes you might not actually have a like-for-like – some design patterns or solutions in one often don’t exist in the other world – but perhaps there could to be a simple sort of table / chart / decision tree that answers questions like “this is what I’m trying to model – I would use this sort of pattern in OO / C# world – what would you use in F# world” e.g.

 

Use case	Idiomatic C# solutions	Idiomatic F# solution
ORM-style data access	Entity Framework	SQL Type Provider
Raw data access	Dapper, Massive, ADO .NET	SQL FSharp Data Client

 

Etc. etc.?

 

From: web-st...@googlegroups.com [mailto:web-st...@googlegroups.com] On Behalf Of emai...@gmail.com
Sent: 14 January 2015 17:03
To: web-st...@googlegroups.com
Subject: Re: Music Store Tutorial

 

As a new comer to F# from the C# ASP.NET world, this hits the nail on the head. I've decided to slowly try and introduce it into the workplace as a way to remove a lot of the extra boilerplate we have to write with C#.

--

You received this message because you are subscribed to the Google Groups "F# Web Stack" group.

To unsubscribe from this group and stop receiving emails from it, send an email to web-stack-fs...@googlegroups.com.

[Ryan Riley]

On Wednesday, January 14, 2015 at 11:03:02 AM UTC-6, emai...@gmail.com wrote:

As a new comer to F# from the C# ASP.NET world,

Welcome!
 

this hits the nail on the head. I've decided to slowly try and introduce it into the workplace as a way to remove a lot of the extra boilerplate we have to write with C#.

That's exciting news! Please feel free to reach out and ask questions when you run into problems!
 

What I'm finding though, is that while available tutorials give a good intro over what's possible, they stop short of showing best implementation practices.
For example, using the SQL data type provider is FANTASTIC; but there aren't clear examples showing how to use it with a repository pattern or to then map the result to a ViewModel.

See the http://todobackend.com/ F# samples. At least for my current production app, repositories and view models would just bloat the solution. In some cases we return the generated types, and in others we use records that represent the result of computations that consume the generated types. The reason you don't see some common OO patterns is that they are simply not necessary. Modules with functions tend to be sufficient, and if you need an interface for data access, you can easily wrap the functions in an interface as is done in the TodoBackend samples I created. I hope that is helpful. I know it can be challenging to convert from the OO patterns to something else. I went through the same transition. I'm still going through various transitions as I realize some of my firmly held opinions are no longer relevant or necessary. :)

Cheers,
Ryan

[Andrew Cherry]

Great to hear that you're exploring F#, I hope you're having fun! I think you're right, as a community I think we could do better at helping people transition between C# and F# (and the web world needs that as much as any other part of the community). I'm not totally sure why we're not great at it (well, I know why *I'm* not great, but that's more obvious...) 

I think it's sometimes because when you get to the point where you feel like you know "enough" to start helping others, you've forgotten the things that aren't obvious as they're second nature now.

I think your example is an interesting one. You'll have to forgive me for quite a simplistic understanding of what you're doing, but I think I might approach it in this way...

Repository pattern: Hmmm, what do I need a repository for? I want to avoid having duplicated logic for retrieving and persisting data in lots of places. In C# the only real way to do that is to put that logic in some class, and then have everything use an instance of that class. Hmmm, what's the idea more simply? Well, putting all of the "methods" (or functions in this case) in the same place. Would it be ok if I just created a module with all of the functions in, where each of them takes an instance of the SQL Type Provider type as an argument? Maybe it would, so I'd probably start like that. That way I can pass around an instance of the data source itself, and pass it to functions which use it to retrieve data. Because modules and functions are first class, I don't need to worry about passing them around in some way.

Object mapping: Do I need anything clever here to map a collection of objects? In C#, again just having plain functions becomes a bit awkward - they need to live somewhere. How about I write a function which converts DTO -> ViewModel? Ok... Now I can use that in lots of different ways. I can pass a DTO to it - I can List.map it over many DTOs... Maybe later I'll create a ViewModel -> DTO function... Now if I paired them, maybe I could do something with that? Hmmm...

I'm not saying those are the right ways at all (which is probably not helping) but maybe it's usefully illustrative. I think Scott Wlaschin writes some excellent things on thinking functionally (or thinking with functions) which might help rather more than me.

I think the thing which has helped me think about web programming in F# the most is the realisation that with F# you don't really need to build everything in to the web framework and its ideas. The web side of things can be a small thin layer. The rest of what's happening should just look like standard F# - if you're doing something which you wouldn't consider doing if you were writing the same logic in a console app, I've found that to be a bit of a sign that you might be able to do it more simply.

Sorry for the ramble, hope it doesn't hinder your journey!

A.

--

[Irfan Charania]

That's exciting news! Please feel free to reach out and ask questions when you run into problems!

Thanks!

Currently I'm trying out ideas from "low risk ways to use fsharp at work".

But I'm also working on a toy project to cement ideas, and how things would work for an ASP.NET MVC app. This is where I'm struggling a bit in terms of best practices.
Is this the right group for posting questions or would that be in F# Discussions group?

See the http://todobackend.com/ F# samples.

Thanks, looking through it.

but perhaps there could to be a simple sort of table / chart / decision tree that answers questions

Yes, that'd be helpful!

view models would just bloat the solution

I'm not sure then what a clean solution is to formatting/localization/etc, where ViewModels provide the solution through attributes

I think the thing which has helped me think about web programming in F# the most is the realisation that with F# you don't really need to build everything in to the web framework and its ideas

Being relatively new to ASP.NET MVC (with a lot of WebForms experience), it's tough to figure out how I can easily go on the road not taken.

Part of it is also in seeing how I can adopt ideas that will lessen the pain points (and convince others to come onboard).
For example, in previous projects we opted to use POCO code generation templates for data access. A quick demo of that, side-by-side with hand-coding, or Enterprise Library, Entity Framework, were enough to convince people right off the bat.

On Wednesday, January 14, 2015 at 9:58:50 AM UTC-8, Andrew Cherry wrote:

Great to hear that you're exploring F#, I hope you're having fun! I think you're right, as a community I think we could do better at helping people transition between C# and F# (and the web world needs that as much as any other part of the community). I'm not totally sure why we're not great at it (well, I know why *I'm* not great, but that's more obvious...) 

I think it's sometimes because when you get to the point where you feel like you know "enough" to start helping others, you've forgotten the things that aren't obvious as they're second nature now.

I think your example is an interesting one. You'll have to forgive me for quite a simplistic understanding of what you're doing, but I think I might approach it in this way...

Repository pattern: Hmmm, what do I need a repository for? I want to avoid having duplicated logic for retrieving and persisting data in lots of places. In C# the only real way to do that is to put that logic in some class, and then have everything use an instance of that class. Hmmm, what's the idea more simply? Well, putting all of the "methods" (or functions in this case) in the same place. Would it be ok if I just created a module with all of the functions in, where each of them takes an instance of the SQL Type Provider type as an argument? Maybe it would, so I'd probably start like that. That way I can pass around an instance of the data source itself, and pass it to functions which use it to retrieve data. Because modules and functions are first class, I don't need to worry about passing them around in some way.

Object mapping: Do I need anything clever here to map a collection of objects? In C#, again just having plain functions becomes a bit awkward - they need to live somewhere. How about I write a function which converts DTO -> ViewModel? Ok... Now I can use that in lots of different ways. I can pass a DTO to it - I can List.map it over many DTOs... Maybe later I'll create a ViewModel -> DTO function... Now if I paired them, maybe I could do something with that? Hmmm...

I'm not saying those are the right ways at all (which is probably not helping) but maybe it's usefully illustrative. I think Scott Wlaschin writes some excellent things on thinking functionally (or thinking with functions) which might help rather more than me.

I think the thing which has helped me think about web programming in F# the most is the realisation that with F# you don't really need to build everything in to the web framework and its ideas. The web side of things can be a small thin layer. The rest of what's happening should just look like standard F# - if you're doing something which you wouldn't consider doing if you were writing the same logic in a console app, I've found that to be a bit of a sign that you might be able to do it more simply.

Sorry for the ramble, hope it doesn't hinder your journey!

A.