Well, hello everyone, my name is Jacomo. I'm an Italian developer. I do quite like
function programming though that is not the topic of today. I'm helping build what I think
is a very cool open source project it's called gleam. It's a programming language. If you're
curious about it, let's have a chat about it later. But we're here to talk about data
phases today. Talking about data phases, of course, maybe I don't know our marketing
department or whatever marketing advertisements, they want us to make beautiful graphs
and crunch data because of course they do. They need that and so it's up to us to then
go fetch the data and figure out all the data crunching and data wrangling that we need.
Or maybe we're just building something for our friends. Well, I do love reading. I have a
book club with my friends and of course being a nerd knowing how to code. I had to do
something with all the data that I was gathering from them. And so here we are. We have books,
they have genres, we rate them and so on and so forth. This is really just a simple example.
But it doesn't really matter what you are building because when you are dealing with a
database, well, that will come with the age or question of how do I talk to the database?
How do I get the data out? How do I do the data wrangling? And answers might take
entirely different looks. On one end of the spectrum, we might be writing sequel totally fine.
At the other end, we might do something quite opposite. We want to abstract it away to even hide
the fact that sequel is there. Using fancy tools like what amps, that shield the developer
from ever having to write any line of sequel. That can be pretty cool as well.
And usually as developers, when we are faced with this kind of choices, we like saying that
a developer should really be a polyglot. We should be using the right language, the right tool
for the job. We like that because that allows us to then advocate for the language we prefer.
Of course, we should be using Java or Python. Oh, oh, not really the Java audience. I see.
Okay, all gleam, for example, because that is a great language and we should be using that.
But, well, it doesn't really matter. You could put any language in there. I think that
they're right tool for the job. When it comes to talking to a database, well, that is sequel.
That is the language meant to be talking to the database. So, it does some really nice advantages.
I think this is quite the nice crowd to give this talk to because I want to find much push
mixing that sequel is good. It makes us more intentional about how we are implementing our specific
workflows because we can see that we're implementing something using what one, a pair,
tens, hundreds or different queries and then we can see that we're doing something that is inefficient.
Usually, we want to do as much as possible with this little round trips to the database as possible
and being the ones that are writing the queries rather than having them generated under the
route as an implementation detail puts us in the control spot where we can decide how to do something.
So, it's also a lot harder to overfetch data because we are the ones who need to be writing select
star overfetching the data. We can catch that pretty easily. I was reading our
cool article, scaling Bosque's URL to power 800 million users and this company was facing
most of its problems with some problematic queries coming from algorithms and they ended up having
to then inspect those and see what was going on understanding what was going on under the wood.
So, not really an implementation detail at this point when we need to have a look at it.
So, if using SQL and not saying it's going to magically make our applications faster,
but it kind of drives us towards this bit of success, what it's easier to do the right thing
to not make something that is terribly and woeful is low without even noticing.
So, if SQL is so good, then where is all the SQL? Why do we feel like we need different tools?
Why do we feel like as developers we need to abstract it away? Well, when it comes to writing
an application, we usually do that in a different language. This is what it might look in
a gleam, for example, to run a query, it doesn't really matter how it does it. If you squint hard
enough, it would be exactly the same in say Java, for example, seeing that you love it.
So, what happens is our query becomes a string in our programming language.
One first drawback is we lose syntax a lighting and then we need a way to bridge this gap
between the relational wood where we have tables with rows and columns and the ward of our
application where we might have objects, data structures or whatever we might use to then represent
some domain concept. And so, we need to tell it that for example, here the first column
ISBN that is a string and we're going to use that as the book I just began indeed.
The second column is again a string that is the title and then we're using it to build this
book data structure. It doesn't really matter how gleam does it. And this might look totally
reasonable as long as we don't start writing more than just the simplest of the queries.
Because of course, then requirements change, maybe we need to fetch more data.
Maybe someone comes and does it refructuring, they switch columns around in our select query.
Well, that might look silly, but I guarantee you if something can happen, it will happen sooner or later.
And then now we have some really hard to find bugs because the decoder we've written saying that
the first column is the, I just began and the second is the title is no longer right. And when do we
start seeing these errors pop up? Well, if we've been diligent and we've written tests,
those will happen in our test suit and we'll see something fail, hopefully, if we have a good
coverage. Otherwise, those are going to happen in production, where things suddenly go wrong
and then we get page and we need to figure out why something broke. Not really a pleasant developer
experience. So we start from our place where we're thinking about the data that we need and really
what we want to do is we want to fetch and use it, that's it. Of course, we need to write some
SQL to do that, but now going from SQL to fetching the data is not a simple because we need to
write some glue code that decoding logic that bridges the gap between these two words. And then
finally we use it but glue code while it's in the name, it's sticky. It calls for more glue code
and then we find bugs and we need to go back to writing SQL and then we need to write again
some more glue code. It's really painful. No one wants to do that. So what should we do? Should we
just give up? Except that as now I said SQL is, well, it's not the right language when building
real-world applications. Well, of course, not, you know, the title of the talk. You do not need
an ORM. So SQL could be the right language for the job. What would it look like then to embrace
SQL rather than trying to abstract it away? Treat it as an implementation detail. Well, what I would
like to show you? What if, sorry, calling a query was as simple as calling a function or a
method if you're doing object oriented because then we know how to do that in our language of
choice. Whatever that is, we deal with the data that is coming from the database. We know how to
coding programming language x that we like. So I would like to show you a library that tries to
do exactly that. It's called the SQL and the author of this library. Really, it's not the
first of its kind. There's blends of libraries that do this in many different languages.
This is thought for glean though. And I think the best way to get a sense for it because this
might sound a bit and maybe what does it look like to embrace SQL and have a nice developer
experience? Well, it's for with a live jammer, which is quite scary to me if someone could hold
the microphone. So I don't, can I just, okay. Thank you. So let's jump right in. So here we have
a project. And what it means to embrace SQL is we're writing our SQL queries just in plain
old dot SQL files. As boring as it can be, but as nice as it can be. Because now we get, well,
since accelerating, we get the output of IDEs. We might be using an entirely different one. Here,
I'm using, for example, data grip. I think it's quite pleasant. It could be anything really.
So here we're building a ranking of books. So we are giving a number to each book based on its
rating. Number one is going to be the best and so on and so forth. Say we want to make this a
tad more complex. We can turn it into a sub query, call it ranking. And only get the best
three books, for example. So where the position is less than or equal to three. Maybe we want
only the covers of the best three books for each genre. So let's group by genre. I don't think
a sub query is all that nice to read. Let's make it a commentable expression. Much better.
Now we see that we have a warning. Select star. Avoid that because that is all the fetching
data. We never want to do it. We want to be precise about the data that we send to our application.
So let's just select the genre and we want to do an aggregation. So a re aggregation of the
covers. And just like that, we have a cover image, maybe. As covers. And just like that, we have
something really nice. And basically the idea was writing this for us. We have refactorings.
We have water completions. We can move code around pretty easily. SQL has been around for a long
time. And these tools have been developed to making the experience of writing it really nice.
But again, this is just a SQL query. So how do we actually run this? Then from our application,
from our Glim code in this case? Well, to do that, you would add the squiro library as a dependency.
I've already done that because I don't trust the Wi-Fi. And then we can just let run the
squiro entry point. And just like that, you can see that something has happened. It says generated
one query. So squiro is doing under the hood. Just some pretty straightforward code generation.
I'm saying straightforward. It looks straightforward. It's actually pretty involved. But at the end
of the day, what really matters is that what it does is it's understanding our queries, talking to the
database and figuring out what is the shape of the data that we're getting back. So that it can
generate those decoders that glue code that now we no longer own because it's taken care of by
squiro. So it can see, for example, that the squiri with written returns rows that contain two columns.
The genre column that is a string and the covers column look at that. That is a list of strings.
We did an aggregation and it could figure that out pretty right. And then it defines a function
to just call that simple query. And it is exactly the code I showed you earlier. Nothing fancy going on
here. But now it is the one that is taking care of actually making sure that this is right
and stays in sync with our database. So what this looks like when then we are developing our
application is we write the SQL query and then just like that we can start using it. So we can call
the function and we're good to go. We don't have to deal with any other really boring glue code
and maintaining code that is really not important. And since now everything is nice and type safe,
we can get the best tooling out that we want from our language. In the game, for example,
I can automatically match on all the cases we see when talking to our database. We could get an error.
Well, I will not bother with that. Here I'm making something pretty straightforward that I could
manage in our live demo. Let's pretty short. We are just server side rendering some HTML.
So what we could do is we make a list and then we transform those rows that are coming from the
database. So we get those rows and we turn those into maybe a list item. So now this doesn't
exist obviously, but since the language and the language server now can understand what we're
dealing with, we get a lot of help from the language server. We can generate this automatically.
We can automatically put a method to get the data out. We can then start writing some more code
making the list item. We said we were making. So let's build maybe a title with the text that we want,
the genre, for example. And then another list, a list of covers. So let's do that.
So here we can transform those again. We can get those covers. We see we get her those are a list of
strings. And we turn each cover into an image. Maybe to make something that is nice to look at.
We generate it again and we're good to go. So one final list item and this contains
an image. So let's do this source. And that is that cover that we have. And just like that,
we're good to go. We could just focus on what we wanted making a nice to look application.
And so what we have here, if we run it, maybe let's see if it works. Pingers crossed.
Perfect. Seems like it started. And look at that. Okay, pretty right for what I could manage in our
HTML. And we have the books that we're fetching from the live database that is running on my machine.
Okay, let's get back to our presentation. So we have a really nice developer experience here
because we're dealing with just plain old SQL files. And now also think about this. The data
that you have is going to help to leave any application that you're going to build on top of it.
So if you get tired about squirrel and gleam, that would make me really sad. But you can switch
to any other language, take those SQL files, and you're good to go. You're not getting locked in
by a specific language, a specific framework that then you have to keep using to reuse that code.
Errors start happening at build time. The feedback loop is really tight. If we make a type
or an query, well, we're going to see the error right in our terminal. As we generate the code,
hopefully you can appreciate the effort that I put in to making that look nice and presentable.
And so now it's a lot easier to deal with that. We started from a really bad place where to do
with a lot of glue code. And to add them, don't get me wrong. They can have a great developer
experience because they take care of those two steps below. Don't care about the SQL,
you don't have to care about the glue code. Pretty happy, pretty right. But I think that obstructing
the SQL away is a recipe for applications that are slower, not as performant. So what if we want
to embrace SQL? Well, we can just let tools do the boring job. Take care of that glue code
for us automatically. And so we can stick to the best language for the job at each step of the
development. We write SQL when talking to the database. And then we use the language that we
know and love, Glim for me, or whatever other language you prefer, when you're building your
application. And so that is why you do not need an ORM. My name is Jacomo. I thank you so much for
coming here today.
If I can still 30 more seconds, please consider sharing your feedback. If you like this,
let me know that would make my day. If you didn't, let me know how I can improve this. So I can
make this better. If you want to keep in touch, I am on social media. You can send me a good
or fashion email, or you can, of course, this is open source. You can have a look at Squirrel.