Separate nuget packages for View Engines

[giraffe-fsharp]

Separate nuget packages for View Engines

[JonCanning]

I'm happy to have a go at this

[dustinmoris]

@JonCanning

Since the view engine implementations do not reference Giraffe, I would be inclined to split them out into separate repos and handle versioning and packaging separately. They are nothing more than extensions to Giraffe.HttpHandlers and just have to write something useful to HttpContext.

That's actually true and now that you say that I am actually swayed to move this stuff into a separate repo and NuGet package.

@gerardtoconnor
Thanks for your input! It's good to get different opinions. Also, would be curious to see your JavascriptServices handler. Sounds interesting..

[dustinmoris]

Hey, thanks for this ticket and the pull request. Why would you prefer the view engines to have as separate NuGet packages?

I had the same thought in the beginning and I thought about the pros/cons of both options and came to the conclusion that going with a single NuGet package is probably the preferred choice, but I am open for discussion.

Option 1 - Single NuGet package

Pros:

• Getting started is super easy, you only have to add one NuGet package and got everything you need
• Versioning is simple with one NuGet package, because there's only one package and only one version
• Managing code and future additions are simple. There's no ambiguity if a new package should be created or not, because the core library contains everything. For example should the HtmlEngine also be split out? If someone wants to add support for other serialization protocols, should they be added to the core library or a new package? Things get messy and often there is no clear line.
• No dependency updating hell. If the core library gets changed then all other libraries have to be updated to reference the latest, which is a pain.

Cons:

• The core library will most likely contain more functionality than a single web application will need*.

*) This would be a problem with more packages as well though. An app which doesn't use razor views or XML might not add the Giraffe.Razor NuGet package, but will still have the xml http handler available.

Option 2 - Multiple NuGet packages

Pros:

• Core package will be smaller in size with less default functionality (the second can be seen as a con as well though)

Cons:

• Users must search/know what packages to add for whatever functionality they need
• Versioning becomes less intuitive. If there is a bug fix in the core library and the core library increases the version, should the other packages match that version, even though they might not have a change or shall the versions diverge?
• If the versions diverge, would it not make more sense to split the separate NuGet packages into their own respective repositories, so that their versions, tags and releases can be properly recorded in GitHub? Separate repositories would add a lot of development overhead though.
• It is never going to be clear when to create a new repo/NuGet package. What is the criteria? How big a new feature is, if it deserves a new namespace/module shall it be moved into a new package altogether or when it introduces other new dependencies shall it be split out?
• Updating dependencies will become a management issue. For example Giraffe.Razor cannot just blindly reference any version of Giraffe, it has to respect semantic versioning and a potential major upgrade to the core library could be a breaking change for Giraffe.Razor. As a result Giraffe.Razor would have to at least limit it to a specific major version (e.g. 2.*.*). Let's say there's now a new Giraffe which gets bumped to 3.*.* because there was a breaking change in the xml handler, which doesn't affect Giraffe.Razor at all, but we will have to update Giraffe.Razor to reference 3.*.* for the sake to stay on the latest. From my experience this is a pain. Nancy and Suave have the same problems as far as I can tell.

^ These where my thoughts and my justifications for keeping it all in one library until now, but I am open for other views and suggestions :).

[MiloszKrajewski]

I'm on the side of separate packages. You can leave ITemplatingEngine interface in core library but RazorTemplatingEngine should be in separate package. In my opinion it is about "decoupling abstraction from implementation".

Recently, with .NET core, you see a lot of this: Microsoft.Extensions.Logging.Abstractions vs Microsoft.Extensions.Logging, Microsoft.Extensions.DependencyInjection.Abstractions vs Microsoft.Extensions.DependencyInjection, System.Runtime.Serialization.Primitives vs System.Runtime.Serialization.

I've seen things you people woundn't believe (tm). A package depending on both NLog and log4net because it contained adapters from both. In this case it would be much better to have them separated, for example: "Tannhauser", "Tannhauser.NLog" and "Tannhauser.log4net".

I agree that there are pros and cons. It actually took me a while to find all the moving parts of "Proto.Actor" for exactly that reason, but at the same time I'm quite happy that my application does not depend on all persistence adapters (let's say, SqlLite, PostgreSQL, MongoDB and SQL Server), while I'm actually using the one I wrote myself for MySQL.

[dustinmoris]

@MiloszKrajewski
I agree with the principle of decoupling abstractions from implementations, but in this specific case there is no abstraction. All view engines are very different and have no common abstraction, so what exactly would you suggest here?

I also agree with you that having all different persistence layers in a core library doesn't make sense, but again I don't think this is the case here.

Giraffe is intended, as often stated, the GoTo ASP.NET Core native framework for F# developers. The big focus here is on ASP.NET Core and in ASP.NET Core the de-facto standard view engine, which is almost used by all ASP.NET projects I have seen, is Razor. Additionally I also added DotLiquid, because it is the only templating engine (not view engine) that I know exists in .NET and it has its very own valid reason to be there IMHO. I don't think there is a real risk of more view engines being added in the future, because there is not many as far as I can tell. I believe that most Giraffe users who will want to write a web app which has a UI will most likely have to use either Razor or DotLiquid, but maybe I am mistaken.

However, assuming we would split out the view engines into separate NuGet packages, how would you address the cons I have listed. What would you do in terms of versioning. Would you move them into a separate repo as well? At what point do you suggest that a piece of code deserves a new NuGet package?

EDIT:

Re .NET Core packages of ...Abstractions vs. the implementation. That makes a lot of sense for the packages which you have listed, but is it comparable to what we have in Giraffe? Also mind that all this code is written in object oriented C# and that all C# (as well as C# ASP.NET Core) projects are built on the DI principle, where a segregation of interfaces and concrete classes are the core architecture of every application. This does not apply to F# at all.

[JonCanning]

Hi @dustinmoris, thanks for your work on this project

My situation is that I have three projects that I want to move to AspNetCore; a REST API, a website that uses RazorEngine, and one that uses Handlebars.NET.

The first doesn't need views, and the other two are not supported. My thinking was that I could cut down the size of the core app, and add support for other view engines as packages.

Since view engines are numerous, and here's yet another one being developed by someone on the ASP team, https://github.com/sebastienros/fluid, is it something Giraffe should be opinionated about?

[dustinmoris]

@JonCanning

Since view engines are numerous, and here's yet another one being developed by someone on the ASP team, https://github.com/sebastienros/fluid, is it something Giraffe should be opinionated about?

Fair point...

Quick question to you as well, because that is something that I am really not sure about: How would you approach versioning, especially tags in Git with a repo which produces multiple NuGet packages. Is there a good example where this is handled in a nice way?

Also, sorry for starting this discussion before merging your PR. I just want to make sure we are taking the right decisions with Giraffe and asking a few questions too many has never hurt so far :)

[JonCanning]

No need to apologise, it's a significant change and it's your baby.

Since the view engine implementations do not reference Giraffe, I would be inclined to split them out into separate repos and handle versioning and packaging separately. They are nothing more than extensions to Giraffe.HttpHandlers and just have to write something useful to HttpContext.

[gerardtoconnor]

@dustinmoris I have already build a JavascriptServices handler that pre-renders (with data prefetch) through Node.Js for Angular/React and does not use any MVC/Razor/DotLiquid ... I have not used Razor for years, its a bit of a legacy technology when it comes to the web in the real world (I know old school asp.net enterprise love it but its inferior user experience vs SPAs), I know people will argue that you can build the SPA into Razor and Node.Js is big and clunky, but I want to only build view templates once, and a lot of other developers feel the same way (or have web devs who separately want full control).

I fully appreciate we are are introducing complexity on versioning with nuget etc is not wanted ... but, in my humble opinion (with this being your baby) there does seem to be a good trade off in that we should strive to have most major viewengine (Razor, SPA, and Fable etc) nuget plugins and the HttpHandler would be the standard interface across all, leaving core Giraffe as a webapi that can extent to view engine you want.

I find it bit annoying seeing so much MVC/Razor built into a SPA app when I'm not using it and it is just bloating/convelouting the core API surface. Just my feelings on it though,

[gerardtoconnor]

would be curious to see your JavascriptServices handler. Sounds interesting..

I'm working on a few nice things in the background ;) ... will finalise & open issue as soon as finished router & task CE (on third(&last) iteration of router), JSSH still needs a few tweaks on data pre-load render but other than that, working very nicely, not a single bit of server render/template in sight (outside of server node.js pre-renderer), completely and nicely decouples the client app & webapi, and with existing caching middle-ware pre-renders delivered (near) zero latency.

@JonCanning would you potentially be able to assist down the line with packaging JSService Handler into Nuget, I can follow your PR and should cover most, but just in case I get stuck?

[dustinmoris]

@gerardtoconnor That sounds interesting :)

@JonCanning I just pushed a new release with your changes. There is two new NuGet packages now. Closing this issue now. Thanks for your contribution!

[JonCanning]

Excellent, I claim the first nuget download. If I implement additional view engines would you want them added to the core repo or should I publish them separately?

@gerardtoconnor of course, happy to help

[dustinmoris]

@JonCanning Let's add more view engines as separate NuGet packages going forward now, but keep the projects in the same repo as it is now with Giraffe.Razor and Giraffe.DotLiquid.