Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion: Template Simplification #269

Open
isaacabraham opened this issue Jun 6, 2019 · 14 comments

Comments

@isaacabraham
Copy link
Member

commented Jun 6, 2019

I wanted to open this as a discussion point for the next "big issue" we see affecting the SAFE template: the increasing cost and complexity of maintaining it. This affects the project in a number of ways:

  • Harder to make changes
  • Harder to on-board new people onto the template
  • Harder to ensure reliability and stability of the template

As such, this issue is going to form the basis of a discussion of ways to remove, or at least reduce, the friction on the template. My thoughts are that the sheer number of dimensions on the template is the biggest pain:

  • Web server tech (Saturn, Giraffe, Suave)
  • Communication tech (Thoth, Remoting, Bridge, Reaction etc.)
  • Hosting platform (Azure, GCP, Docker etc.)
  • Services (Azure storage etc.)
  • UI features (Fulma themes - potentially Material etc. in the future)

This is only going to get worse in the future, so here are some ideas that we've tentatively been discussing around this:

1. Cut features

Simply remove some features from the stack that present wins in terms of cost / benefit. Primary candidates are Suave and Fulma themes.

  • Unlike Saturn and Giraffe, both of which build directly on top of ASP .NET and share much in the way of features, Suave is completely different. Many features need to be implemented in a completely different way and thus increase the cost of incorporating them in.
  • Whilst we don't capture user states, Fulma themes seem to be of minimal value. There are also other sources of Fulma themes available that aren't included in the template, so it might make sense to remove this. Two options are:
    1. Simplify the template to either have a "clean" (no Fulma) or "basic" Fulma styling
    2. Just turn on basic Fulma all the time.
      Either way, we would provide documentation for other options.

2. Modularisation

The idea here is that instead of the template itself containing all the code for Azure, GCP, Docker etc., they would become dependencies in some way e.g. NuGet packages or simply GItHub files that can be pulled in by Paket.

Coupling to the Template

We can look at this as a way that whilst the template wouldn't contain the code for the dependencies e.g. Azure, it would still contain the list of e.g. Cloud services in the template options. The template would still have to "pre-generate" the paket dependencies files etc., but they could at least be developed and improved "out of band" of the template itself. We might have to create some kind of common interface that all similar services adhere to in order to incorporate at least the "plug point" into the template e.g. in the FAKE script, if the user chooses Azure, the generated FAKE script would have to know what information the Azure deployment module needed and what the signature looked like etc.

Decoupling from the template

An alternative is to look at something more ambitious and consider either a dotnet tool or similar which is an application that can be run and make in-place modifications to a (freshly-created) SAFE application to add the appropriate features in. For example, someone wanting to add Azure support to the SAFE template would first generate a normal, clean SAFE template (which would not have any options for platform etc.). Then, as a second step, they would run the SAFE tool e.g. safe -add Azure or similar. This would add the appropriate dependencies to the Paket file, add appropriate code to the application etc.. The benefit of this approach is that it drastically simplifies the SAFE template itself and gives a much simpler (and more reliable) experience, whilst allowing the "plugins" to develop entirely outside of the template. The cost of this is that it's a more expensive option in terms of architecture and development.

Next Steps

FWIW I think a combination of both options should be used. Firstly, removal of both the options as outlined in (1) should be done in the near future. This can be achieved quickly and easily (e.g. this experimental branch removes both and largely simplifies the codebase). Second, a number of prototypes should be developed to explore option 2.

Thoughts? Ideas? Criticisms? All welcome - let's get some thoughts and feedback going.

@isaacabraham

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2019

@MangelMaxime

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

For me removing the different layout option for Fulma is a good thing. The different layout we currently have don't really add value to the template.

Most of the time, you just want to know that it's do-able and then build your own layout step by step.

If we include Bulma using npm and not a CDN server then Bulma can be customized by the user. It's also the recommended way of including Bulma.

If we want to sell Bulma theming system, we can add a link in the documentation to Bulmaswatch for example and explain how to add the theme (or link to their documentation page doc).


As an example, in Fulma I only provide a really minimal version of the template so people can quickly own the code. There is only one "small" view function which still provide a "clean" first user look.

And if they want to see what Fulma is capable of, then I point them to Fulma demo which is a more ambitious project.


My last example made me rethink about this issue #172

I am not sure if we want or can give it a second look. But I though it made sense to point it out. In. the sense that we could choose/rethink which example better serve the SAFE stack and interaction between the server/client (or is easier to understand).

For example, asking the server to increase a value rarely happen in real world. But asking the server to modify a value is much more common scenario.

@isaacabraham

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2019

Yeah, we could maybe move from counter example to something like a simple form to fill with a server-generated calculation with the result displayed on the client again.

@Krzysztof-Cieslak

This comment has been minimized.

Copy link
Member

commented Jun 6, 2019

I strongly support removing complexity and some options from template. One of the ideas behind SAFE is pushing users into right direction (which fits into F# Pit of Success philosophy), and I think too many options is against this goal - it adds confusion and cognitive overload, users shouldn't need to study all possible options to make decision.

An alternative is to look at something more ambitious and consider either a dotnet tool or similar which is an application that can be run and make in-place modifications to a (freshly-created) SAFE application to add the appropriate features in.

I think I've mentioned something like that ages ago ;-) Again, I'd strongly support such option - this is what popular JS frameworks do. It turns out generic template engines like dotnet are not customizable enough - yes, they're flexible enough to do everything (just like we do here in template) but at cost of the good UX. Good UX will always be connected with particular usecase, and if we want to provide it for SAFE i believe CLI tool is a way to go

Examples:

@theimowski

This comment has been minimized.

Copy link
Member

commented Jun 6, 2019

Indeed layout options seem to be the lowest hanging fruit here.
But I wouldn't just remove those options - I think there's some value in examples that one can copy paste just to try something out.

Hence I suggest to create a repository per each fulma layout currently in layout options (hero, admin, landing, etc..) - the repositories could be e.g. under https://github.com/Fulma org?
Then we could point in docs to those repositories for sample layouts, and remove the options from SAFE template.

I'd leave "none" and "fulma-basic" options for now, since I believe at some point we could add basic materialUI or antD fable bindings

@MangelMaxime

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2019

Hence I suggest to create a repository per each fulma layout currently in layout options (hero, admin, landing, etc..) - the repositories could be e.g. under https://github.com/Fulma org?

If we host them under Fulma repo, I will probably strip then from all the SAFE Stack part. They will probably be like the Fulma-demo, just showcase application that are available online and which try to provide an interactive sample.

  • An interactive dashboard
  • An animated landing page
  • etc.
@isaacabraham

This comment has been minimized.

Copy link
Member Author

commented Jun 6, 2019

@theimowski isn't that just going to be more to maintain? I'd rather just point people to themes (there are others as well e.g. Bulmaswatch which I've used in the SAFE Search app and it worked just great.

Regarding materialUI / antD - I'd be up for stripping it out completely and adding back in if / when that happens - we've been planning those for a while but they're not high priority at the moment really.

@theimowski

This comment has been minimized.

Copy link
Member

commented Jun 10, 2019

If we host them under Fulma repo, I will probably strip then from all the SAFE Stack part

Yes, that's what I had in mind

@isaacabraham IMO there's a value in having working examples of various layouts. It shouldn't be hard to maintain also as the only dependency there is Fulma.

There's also value in having option of excluding Fulma from SAFE template - e.g. for https://github.com/theimowski/SAFE-TodoMVC I used --layout none as there's a CSS ready to use from NPM

Talking about Material UI and Ant D I didn't mean we should add them now, but rather that we should design possible options so that it is easier to add them in future.

To sum up, I propose following changes to layout options:

  • remove all options but none and fulma-basic
  • fork Fulma-demo in Fulma organisation and create example layouts for: admin, cover, hero, landing, login and publish them (github pages? - what you use @MangelMaxime?)
  • in docs point to example repos with Fulma layouts
@theimowski

This comment has been minimized.

Copy link
Member

commented Jun 11, 2019

@bruinbrown

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2019

I think there is significant benefit in having v2 as a refactor release with a more prescriptive means of developing full stack applications with F#, this would include removal of Suave, removal of Fulma templates (potentially with an expansion of the scss file to include description of how to use different templates and variables in there). I'd also be inclined to go as far as removing libraries like Reaction and Remoting to start with as well as the Azure services components. But I think there's significant value in keeping the different deployment options in place, especially if we can keep them there without needing to modify the application itself.

Then once we've got this, we should look at what new features we could start to add in V3 which could grow the SAFE ecosystem

@theimowski

This comment has been minimized.

Copy link
Member

commented Jul 3, 2019

I've released SAFE.Tool 0.0.1 - nuget, repository
This is an early PoC and I'd like to gather your feedback
You can try it out:

  1. dotnet tool install -g SAFE.Tool (in future we can make it local tool for SAFE projects)
  2. dotnet new safe

Currently following workflows are allowed:

Build and run using SAFE Tool

  1. safe build
  2. safe run

This builds / runs the application just by using the tool, in fact build.fsx is completely ignored.

Add a feature to SAFE project

  1. safe add docker

This creates a .config/safe.json configuration file and saves info to enable docker integration. We could potentially use the config file for other features that we plan to remove in v2: deployment options, communication, authentication etc etc

Build and run docker

  1. safe build docker
  2. safe run docker

This will respectively build a docker image and run SAFE in docker container - note you need to have docker enabled to do that, otherwise the tool will tell you it's disabled

Remove feature

  1. safe remove docker

Disables docker for the project

@j-sauer

This comment has been minimized.

Copy link

commented Aug 18, 2019

IMHO a custom cli tool like the above is the way to go. For me as a user it is not helpful to have plenty options when beginning with SAFE. I like the possibility to add further things like deployment setups later. Also updates to a new version of SAFE could be achieved more easily (how often this happens for an application, I do not know to be honest).

@isaacabraham

This comment has been minimized.

Copy link
Member Author

commented Aug 23, 2019

@theimowski what would you say the next steps for the tool are? I've had a quick play with it - perhaps we should look to add something that impacts on the code itself e.g. add support for fable remoting or something?

@theimowski

This comment has been minimized.

Copy link
Member

commented Aug 23, 2019

I'm currently working on the "plugin" model where all deployment options we currently have are separate NuGet packages that one can plug into SAFE app. So the goal is to remove these options for v2 but still being able to use those as separate plugins

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.