I'm a fan of F# and plain functional programming myself. We use that and deploy docker images to linux servers. I agree that the Kestrel API could be a little less weird. But the settings are documented and work. I don't tend to use the default MVC stuff though. I hate attribute-based approaches because it is so opaque and hard to trace in code. I use more functional libs for the back-end API (see Giraffe) and JS front-ends (Elmish).
I would be very wary of a transition to microservices with only a single developer. (see Conway's Law.) It will add a lot of new problems around service communication and coordination. If you had multiple teams, you would face those same kind of issues across teams so those would need solving anyway. But with one developer, it's extra work for little benefit. You would probably be better off modularizing the existing app. I am not saying to only use a single service. But be wary of lots of single-responsibility micro-services in that org structure.
I wrote an article on F# here. There are other ways to write functional code, and F# also supports OO. But I find my approach much easier and quite maintainable.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm a fan of F# and plain functional programming myself. We use that and deploy docker images to linux servers. I agree that the Kestrel API could be a little less weird. But the settings are documented and work. I don't tend to use the default MVC stuff though. I hate attribute-based approaches because it is so opaque and hard to trace in code. I use more functional libs for the back-end API (see Giraffe) and JS front-ends (Elmish).
I would be very wary of a transition to microservices with only a single developer. (see Conway's Law.) It will add a lot of new problems around service communication and coordination. If you had multiple teams, you would face those same kind of issues across teams so those would need solving anyway. But with one developer, it's extra work for little benefit. You would probably be better off modularizing the existing app. I am not saying to only use a single service. But be wary of lots of single-responsibility micro-services in that org structure.
I'll think about it for the micro services! Thank you for your F# advice, I haven't heard much about it, so I'm going to find out!
If others want to make proposals, don't hesitate!
I wrote an article on F# here. There are other ways to write functional code, and F# also supports OO. But I find my approach much easier and quite maintainable.