Abstract Interface

[00:00:00]
>> Maximiliano Firtman: Something that we need to do, we need to start doing is to start working with environmental variables. Because this idea of copy and pasting the connection string and hard coding that inside go files, it's okay for the install script because it's something that we're not going to ship.

[00:00:19]
But if you're going to ship this to a server it's not really a good idea, okay, so we need to move one step. So that's why we are going to start using directly our env files. Okay, so we will get there. So do you remember that I mentioned?

[00:00:41]
That I actually want to offer you a future proof back end project, that if in the future, you actually want to change your database. And now you don't want to use Postgres anymore, you want to use MySQL or whatever, you should be able to do that easily, okay?

[00:01:01]
So the way to solve the problem is to create an interface, an abstract interface that then later we can change. But let me try to explain what that is. So to do that, I'm going to create a new folder. We can call this provider data database. Up to you, or go, of course, remember that it's not a folder.

[00:01:23]
It's a folder and also a package. So let's call it data and we're going to create our interface for this. So we can call this interface or interfaces.go. So here we are going to write in the package data an interface. So we are gonna create a new type.

[00:01:44]
But instead of being a structure, it's gonna be an interface. We can call this a movie storage. So it's a storage that will store our movies. There's gonna be an interface and the idea here is we are gonna set the signature of all the functions that we will need for our project.

[00:02:04]
And then we will force the implementation of that interface in one particular PostgreSQL implementation. Does it make sense? So it's like an abstract class in the OOP world, kind of. So in this case, for example, we will have a get top movies function, okay, something like that that returns a pair of a collection of models, movie, so a collection of movie and a possible error.

[00:02:41]
Remember that some points, it may not work, so we can return the type error. We couldn't connect to the database, something happened, so we always need to send the error and populate the error. This is a pattern. It's not mandatory, but this is a pattern. Again, what I'm saying is that you could just return the collection of movies.

[00:03:05]
You can do that, but if you do that, you will lose the ability to pass error messages across the layers of your app, which is not a good idea. Okay, so we are going to pass an error. This is a type It's not the name of a variable but it's a type, the type is error, and we know that we have get random movies as well.

[00:03:26]
It's just returning the same thing, things that we will need later, maybe in the meantime, we're not going to use them, but we will have get movie by ID to get the details. So I receive an ID as an integer. And I'm going to return not the collection of movies, but one movie.

[00:03:47]
>> Maximiliano Firtman: So models.movie, so no square brackets, just one movie and a possible error. We can search movies by name. So we Pparse a name.
>> Maximiliano Firtman: Later, we will see that ,we will need more arguments here, because we will reorder the search, we will filter the search. Okay, but for now, we can keep it like this.

[00:04:16]
If you're taking it from the rhythm, maybe you have more arguments. It's okay, you can add those arguments, doesn't matter. And in this case, I'm also returning many movies. And also we will get all the genre. We will use that later, you will see why. No arguments, and we are returning a collection.

[00:04:40]
Or a possible error. So this is my interface.
>> Maximiliano Firtman: So the idea is that we make an abstraction layer, so in the future, we may have different implementations. One can be dummy data from a JSON, The other one can be the real Postgres database, another one can be a MySQL database, and MongoDB database, different implementations of the same interface, okay?

[00:05:10]
Does it make sense? That's the idea.
>> Speaker 2: For GetMovieByID, we're not using a pointer for that one, but for all the other ones because they're all slices I guess there would be, wouldn't those be like references. But then we're copying just the one get movie by IV versus all the others being like references.

[00:05:33]
>> Maximiliano Firtman: Let me see if I understand. You're talking about what you're returning?
>> Speaker 2: Yeah, what we're returning. Forget movie by ID so that one's not a pointer. But all of the other ones are kind of implicently pointers because they're slices right?
>> Maximiliano Firtman: Yeah.
>> Speaker 2: Or am I misunderstanding?

[00:05:50]
>> Maximiliano Firtman: So they are slices so actually you are returning the slice as the collection and the collection has pointers to that. So if you're asking, if we so, what's the difference? It's creating a copy. Yeah, if you don't wanna, we can return a pointer for sure.
>> Speaker 2: So that's not an issue that we're copying.

[00:06:09]
>> Maximiliano Firtman: You are copying the movie. What's copying the movie? The values of the values of that value. Remember the value. So the movie is a value. It's a model. It has the ID, the title, the tagline, has all those properties. So if you are not passing or returning a pointer, you are creating a copy of that, okay?

[00:06:31]
If you want more efficiency in terms of memory management, pointers are better. It depends on the case. You may be also reducing, let's say, easy to understand code. Depends on the case. I'm not saying this case. So, we can do both. In terms of real performance, it's not going to be a huge deal.

[00:06:56]
It's just basic data that we are sending. We don't have a lot of like we don't have images inside the database or things like that, that cloning that or copying that will take more time, but it will be more efficient if we are returning a pointer. Yeah, you are right on that.