Look into F# and Fable+elmish for front-end work. Fable is a F#-to-JS cross-compiler, and the elmish "framework" is Model-View-Update. MVU is great because there's not much to it, and most of the code you write is your own functions and data instead of being heavily entangled with framework abstractions. I haven't used Fable/Elmish yet, since I was already using Elm, upon which it is based.
I despise ORMs (including EF). However, I do highly recommend Dapper. It is a "micro-ORM", basically just a row-to-object mapper. It's really fast.
Most of the F# courses you find on Pluralsight will be on the server-side. Check out some courses by Mark Seemann. Probably a lot of good ones out there, but I'm familiar with his work from his blog and videos.
I can't immediately point to a Fable-Elmish (front-end) tutorial since Fable hit 1.0. There are some older ones for 0.8, but the setup is a little different. However, the fable-elmish github provides a brief overview and some sample applications. AFAIK, when you see React mentioned, it is for the DOM rendering engine not the full React framework.
It is one of those things I've invested in heavily and later been bitten by its constraints.
Where an ORM really pays for itself is loading/saving nested object graphs that are represented by multiple tables with FK relationships. However, I can usually load/save the same object graph as a document (e.g. JSON-serialized) just as easily and without all the extra ORM tooling.
This is about as complicated as I make database access nowadays. Plus a few more features around performance (run multiple queries at once to avoid round trips, unbuffered reads for large result sets, etc).
But our app is designed to support that. I can save an entity both as a document for viewing/editing purposes, and also save some of the information in a flat table along with a full-text search column for listing/searching.
Look into F# and Fable+elmish for front-end work. Fable is a F#-to-JS cross-compiler, and the elmish "framework" is Model-View-Update. MVU is great because there's not much to it, and most of the code you write is your own functions and data instead of being heavily entangled with framework abstractions. I haven't used Fable/Elmish yet, since I was already using Elm, upon which it is based.
I despise ORMs (including EF). However, I do highly recommend Dapper. It is a "micro-ORM", basically just a row-to-object mapper. It's really fast.
I am aware of dapper and in my company we already use it in our system.
Do you have any starting point for those F-things. If not, I suppose, that best place to start is pluralsight or something similar?
I learned a lot from F# for Fun and Profit on the language itself.
Most of the F# courses you find on Pluralsight will be on the server-side. Check out some courses by Mark Seemann. Probably a lot of good ones out there, but I'm familiar with his work from his blog and videos.
I can't immediately point to a Fable-Elmish (front-end) tutorial since Fable hit 1.0. There are some older ones for 0.8, but the setup is a little different. However, the fable-elmish github provides a brief overview and some sample applications. AFAIK, when you see React mentioned, it is for the DOM rendering engine not the full React framework.
Would you care to elaborate? For the record: I don't wish to start a pro or anti discussion.
It is one of those things I've invested in heavily and later been bitten by its constraints.
Where an ORM really pays for itself is loading/saving nested object graphs that are represented by multiple tables with FK relationships. However, I can usually load/save the same object graph as a document (e.g. JSON-serialized) just as easily and without all the extra ORM tooling.
This is about as complicated as I make database access nowadays. Plus a few more features around performance (run multiple queries at once to avoid round trips, unbuffered reads for large result sets, etc).
But our app is designed to support that. I can save an entity both as a document for viewing/editing purposes, and also save some of the information in a flat table along with a full-text search column for listing/searching.
Thanks for sharing your view and the article :)
I like how your tooling is lightweight and simply using sql.