Typechecking SQL in Slick and Doobie
underscore.io
Typechecking SQL in Slick and Doobie
1–9 of 9 posts
Re: Typechecking SQL in Slick and Doobie
#2It seems to me that MV* architectures have been popular because we are forced to separate code into client side, server side, and DB. As we are developing new ways to integrate these, I 'm curios to see how this paradigm will change.
I wonder, if we could write one single file that would handle client side, server side, and DB code using the same types, objects, functions, and language with no visible boundaries to the programmer, would MV* become less practical?
Re: Typechecking SQL in Slick and Doobie
#3It seems to me that MV* architectures have been popular because we are forced to separate code into client side, server side, and DB. As we are developing new ways to integrate these, I 'm curios to see how this paradigm will change. I wonder, if we could write one single file that would handle client side, server side, and DB code using the same types, objects, functions, and language with no visible boundaries to t…
Given network latency it seems dangerous to abstract out the client and server distinction.
As for MVC, I think there has been an ongoing shift away from it, or at least a refinement, for a long time. Functional programs looks quite different. React is a good example, emphasising unidirectional data flow rather than the cycles in MVC.
Re: Typechecking SQL in Slick and Doobie
#4This is great! I tend to avoid abstractions for SQL, but Slick On another note, I've never heard of Doobie, and that is as someone who has spent at least a few hours in the past few months researching better Scala-oriented database access libraries. Seems to have come out of nowhere.
Re: Typechecking SQL in Slick and Doobie
#5Something similar is available in F# using FSharp.Data.SqlClient[0].
Re: Typechecking SQL in Slick and Doobie
#6This is great! I tend to avoid abstractions for SQL, but Slick On another note, I've never heard of Doobie, and that is as someone who has spent at least a few hours in the past few months researching better Scala-oriented database access libraries. Seems to have come out of nowhere.
Doobie is quite new, though it was available before Slick 3. If you're still in the market for a database access library I would definitely check it out. It's very simple but powerful.
The evolution of database access is interesting, from raw SQL, to ORMs, to tuple oriented abstractions over SQL (Slick, Squeryl in Scala), and now Doobie and Slick return to allowing raw SQL (with machinery in place to make it safer).
Re: Typechecking SQL in Slick and Doobie
#7It seems to me that MV* architectures have been popular because we are forced to separate code into client side, server side, and DB. As we are developing new ways to integrate these, I 'm curios to see how this paradigm will change. I wonder, if we could write one single file that would handle client side, server side, and DB code using the same types, objects, functions, and language with no visible boundaries to t…
> I wonder, if we could write one single file that would handle client side, server side, and DB code using the same types, objects, functions, and language with no visible boundaries to the programmer, would MV* become less practical?
GWT, basically?
Re: Typechecking SQL in Slick and Doobie
#8It seems to me that MV* architectures have been popular because we are forced to separate code into client side, server side, and DB. As we are developing new ways to integrate these, I 'm curios to see how this paradigm will change. I wonder, if we could write one single file that would handle client side, server side, and DB code using the same types, objects, functions, and language with no visible boundaries to t…
> I wonder, if we could write one single file that would handle client side, server side, and DB code using the same types, objects, functions, and language with no visible boundaries to the programmer, would MV* become less practical? GWT, basically?
[deleted]
Re: Typechecking SQL in Slick and Doobie
#9It seems to me that MV* architectures have been popular because we are forced to separate code into client side, server side, and DB. As we are developing new ways to integrate these, I 'm curios to see how this paradigm will change. I wonder, if we could write one single file that would handle client side, server side, and DB code using the same types, objects, functions, and language with no visible boundaries to t…
There are a handful of Javascript frameworks taking this approach. The community has adopted the term "isomorphic javascript" to collectively describe them (i.e. "same code on the client and server").
See http://isomorphic.net for examples. However, note that they appear to be quite inclusive in their definition. For example, I'd definitely consider Meteor to be one of these frameworks, but React? Not so much.