Fable: Alternative architecture suggestion

[alehro]

The project is great but I currently see a mess in configurations. I myself cannot do anything except of running some samples. Currently I need Fable to work for project where I have ASP.NET + WebApi + IIS + EntityFramework. It implies a lot of assembly dependencies.
I have tried to keep all in one assembly - fable-compiler crashes being not able to transpile code which shouldn't be transpiled.
I had tried to move the code for fable to separate assembly in the hope that fable will respect this and transpile only these code without any dependencies. The problem with it that I still need to keep dependency on other project from the solution. I suspect that --refs option may help but I cannot get it working.

So, as I see you have problems with dependencies management. As it is always been harsh topic we need to take it really seriously. I don't believe that stuff like --refs option is reliable enough even if I get it working. In real applications where you have many dependencies managing all of them could be nightmare.
I already had similar problems with TypeLite library for Typescript interface generation from assembly.

I suggest alternative approach. What if instead of command line we use VisualStudio. I mean that we put all code we need to transpile to separate assembly but require it to be exe file calling fable compiler internally.
That way we use VS infrastructure for dependencies management. I understand that this looks a bit awkward and may be not cross-platform etc., but it still could be a solution.
BTW, I'm failed to build compiler with tests too. So, my speculations are pretty raw. Please let me know where I'm wrong.

[alfonsogarciacaro]

This is going to be difficult because I'm working on Mac with Visual Studio Code, so I've absolutely no idea how this VS infrastructure for dependency management would work :wink: Fable cannot compile a project if it doesn't know how to resolve calls, this is intended because you don't want to have calls failing at runtime in JS.

My advice would be to create a separate project in your solution which contains only the code supposed to be compiled to JS. This can include shared files with your server project (e.g. types defining your domain model, etc) but shouldn't have any dependency of assemblies for the server (ASP.NET, WebAPI, Entity Framework...).

BTW, the way to compile multiple projects and references is changing in 0.7. You can see some preliminary instructions in #522.

[Krzysztof-Cieslak]

That way we use VS infrastructure for dependencies management. I understand that this looks a bit awkward and may be not cross-platform etc., but it still could be a solution.

Creating tight coupling with one particular [bad] editor, and one particular [bad] OS is not solution to anything. Such thinking is a reason why we are in place we are [.Net is dead. ]

[alehro]

@alfonsogarciacaro, thank you for advice, I think it's going to work.

[alehro]

@Krzysztof-Cieslak , ha-ha-ha, I'm full time .Net developer of corporate web applications. So, my vision is a bit different.

[rkosafo]

@alehro Indeed, it is as @alfonsogarciacaro said. Having a separate project for fable is the way to do. Compilation goes through as expected without the dependency issues. With this, the approach remains the same irrespective of the backend. Currently working on a FeathersJs application with Fable currently only for the frontend and it feels almost the same as the previous apps with suave and also asp.net core.

[alfonsogarciacaro]

Closing the issue, please feel free to reopen it if you've any other question.

[xperiandri]

I think @alehro raised absolutely reasonable topic.
It would be extremely nice to have a single fsproj for front-end and ASP.NET Core back-end.
Maybe it can be done with conditional compilation, can't it?

[MangelMaxime]

Please don't mixed the frontend and backend code...

For example, if you use Elmish which part of the code do you want to mix ? The types ? Why would the view and the server need the same types ? Probably just for the interface part yes, so a common classlib would do the job.

Also, you can have easy communication between the server and the client. See this arcticle

[xperiandri]

I don't use Elmish as it does not look expressive for me. I would better use XAML + C# and transform to HTML + JavaScript as I know them better and can visualize in designer.

Why would the view and the server need the same types ?

Yes.

Probably just for the interface part yes, so a common classlib would do the job.

It can but why am I limited to compose everything into a single project?

Also, you can have easy communication between the server and the client. See this article

Suave is to slow and having routing in a single place is impractical. Moreover it does not support something like ASP.NET API Versioning.

[alfonsogarciacaro]

Fable is not tied to any specific library like Suave or Elmish, you can use anything that better fits your needs :smile: On the server side, you can use any programming language for that matter. The main advantage of using F# both on the back and front ends is you can share types and you have also tools to make communication easier like Fable.JsonConverter or Fable.Remote.

However, making it possible to put everything in the same project is complicated, so I'd recommend to use different projects. For the shared types you can use a shared project as @MangelMaxime suggests, or simply include a reference to the file containing the shared types in your frontend project.