Flutter Firebase & DDD Course [3] – Auth Facade Interface

validating data and making illegal states unrepresentable is our second nature after the previous part but you know having these nice value objects by themselves is quite pointless let's start taking steps toward implementing the application layer responsible for taking raw email and password strings from the UI to the authentication back-end hello welcome to reso cocoa where you are getting prepared for real out development so that you will get freelance clients or a job and be confident about the apps you build so subscribe and hit the bell to join us on our quest for become an in-demand flutter' developers before we can venture out into the world of the application layer for which we have already created a folder we first need to create an abstraction for the firebase auth and Google sign-in classes inside the domain layer so this means we are still not going to actually implement or even touch anything which is related to firebase directly we are just going to sort of create a safe layer in between firebase which deals with real data and our own nice domain layer which is the core of our app so why are we doing this well we want to make firebase into a true implementation detail we definitely do not want to be entangled in to firebase so much that our app cannot run without it for example if we should decide to switch to an authentication server and communicate with it through an API and through HTTP requests we will be able to do so easily with the approach we are taking in this domain driven design series and secondly we are going to create abstractions to fulfill the domain driven design spec where the application layer cannot depend on classes from the infrastructure layer and be sure to check out the written tutorial from the link in the description where you're going to be able to find all of the code written in this video all of the links to different explanations links to the github repositories associated with this tutorial series and overall go through this lesson at your own pace so which actions do we need to perform on the authentication back-end in our case that's going to be firebase off and Google sign-in but again we are trying to abstract things so I'm just going to call it authentication back-end well there are really three things which we should be able to do right now and those are register with email and password sign in with email and password and sign in with Google so we now know that we should implement these three things but we are still a long way from their actual implementation I mean we don't even have any firebase plugins imported into the pub spec that yamo file yet so we cannot even possibly implement the three aforementioned methods but what we can do even now is to create an abstraction and we are going to leave the implementation of these three register and sign-in methods for later parts and doing so will allow us to focus on the blocks in the application layer in the next parts before even really jumping to implement all things firebase and jumping into the infrastructure layer because we are going to be moving along the layer tree we started off in the domain layer we're going to be here for quite some time and then we're going to go over to the application layer which is the second innermost layer you could say and only then we're going to touch infrastructure and presentation which are the outermost layers so less therefore create an eye of facade dot dart file it going to live under domain of and it's called I of facade dart because it's going to be only an interface you know dart offers only abstract classes and it doesn't have any real interface keyword unlike Java or Catalan or even c-sharp but although there are no real interfaces we can overcome this bad thing which dart has in the language design with strong naming conventions so in our case in this tutorial series whatever starts with AI is going to have all the interface and there is gonna be no implementation present whatsoever inside that class so it will be called I office odd and it's going to have three methods oh and by the way facade is a design pattern which is used for connecting two or more classes which have weird interfaces and you cannot really use those interfaces in your app and facade takes those multiple classes and plug them into a nice and unified interface and you can learn more about facade from a link which is available in the written tutorial so we want to be able to register with email and password so we're going to create future Voyles for now register with email and password this method is going to take in two required named parameters let's import flutter foundation I know you could also import meta dot dot but we are in a flower anyway we are now going to be migrating this to angular Dart so it's perfectly safe to the Fator foundation no worries regarding this if you want to you can always use imports Mehta that darlin you are gonna be good to go as well but just for the sake of simplicity I'm gonna import foundation because that's what I can import automatically okay so this method needs to take in an email address and a password and because we are inside the domain layer we are now just going to accept any sort of a string now we're going to use the email address and password value objects which we have created in the previous part so the first parameter will be add required email address email address the second one will be required and I don't know why it tries to tell my name here for some reason so require password password okay now we can just simply copy this method which is for registering with email and password and we are also going to have another one with the same signature but it will be called sign in and the last method which will be here for now is gonna be future for it sign in with Google it's not gonna accept any arguments because we do not need neither an email nor a password in order to sign in with Google we don't need any parameters to be present over here and also if you take a look at the diagram in the infrastructure layer for which we have currently created an interface there are only repositories there is no word about facades however facades are on the same level as repositories they still deal with raw data from data sources in our case when we implement this I off facade using fire babies we're going to be dealing with the firebase off but in addition to repositories they also have the role of simplifying interface of the contained classes that's because as I already said in the beginning once we start implementing this interface here it's going to depend on firebase off and also on Google sign-in classes and so that we do not need to depend on multiple classes inside the application layer we are just going to simplify the interface of two classes into just one class using I off facade that's the role of a sod let's look at the return types of these methods now because something doesn't play right here although you may think that the future of oil return type is perfectly fine I find it quite disturbing because how are we going to handle failures or exceptions well we definitely do not want to catch around exceptions inside the application layer if you look at the diagram right now you see that the repositories or facades in this case receive exceptions so we're going to catch exceptions inside facade but the facade should then return a failure it should not allow any exception to just pass through it right so just like we have created failures for indicating if a value object holds a valid or an invalid value right and we are using an either type as a union for the valid and invalid cases we are going to also use the either type for unifying the valid sort of so non erroneous and erroneous return types before we can start writing either inside this future generic parameter like this we first need to know what sort of a failure we should return inside this either right so let's create such a failure right now and also I have just noticed that we are importing value objects that Dart two times here so let's just get rid of it and we're going to import value objects like this just once okay and let's create authentication failure Union so under domain R we are going to create a new file or failure dart and in here we are again going to create free East Union so the structure of all failure will be very similar to what we have going inside the value failure Union and let's think about the possible failures which can occur inside our authentication back-end we do not actually really need to know about what can go wrong precise the inside firebase off but knowing about the possible errors probably wouldn't hurt and there is a link to the kinds of errors which can occur in firebase off in the written tutorial the failures which are going to be present inside the earth failure Union though are going to be valid no matter what kind of an authentication back-end we use in the end so the first thing which can happen is that the user taps out of the third party signing flow for example from Google sign-in the second failure which can occur is that an error on the off server occurs some sort of unspecified averages occurs and the signing of course fails in that case the third thing that can occur is that the user wants to register with an email which is already in use and of course you cannot have two emails used by different users and lastly it can happen that a user enters invalid combination of an email and password so of course you cannot sign it if you have invalid email or password so let's reflect all of these possible failures which I have just described into a freest union since we are going to be working with Freese we need to provide PDF which is part free statement and again you can get all of these snippets which I am using right here when you go to the article for the free tutorial to which you can get from the cart in the corner so we want to create F Union because it's a free Union its name will be all failure and the first case factory will be cancelled by user and let's just make its type called cancel by user okay and let's import freeze annotation right over here and now we can run our most favorite command which will be flutter Bob run bill run Watch delete conflicting outputs just to be safe all right and once this runs we should have the first case factory generated for us let's go ahead and create all of the other case factories so the next one will be for the further unspecified server error so let's rename this to server error and this server error failure will be sort of a catch-all failure which we will use whenever we actually don't know what went wrong so if something unspecified goes wrong we're just going to return server error the next failure which we need to have here is when email is already in use and the user tries to register it again with a different password so email already in use okay let's make the actual type also generated and lastly we're gonna have invalid email and password combination this is quite a long name but regardless of that we now have even this possibility invalid email and password combination failure this is all nice that we have these four failures which can occur on our authentication back-end but now let's go to the auth facade and let's try to think how we can return these failures from the methods so of course we now know that just like in the value objects we can use either or either whichever pronunciation you prefer to return either a failure or regular good value the problem is that if we have an either here and we return or failure in the left side of either well what are we going to return in the right side of either right because these methods are perfectly fine returning void we do not need to return any sort of a real value from a sign-in method right we do not even need to return the signed and user we are going to handle that later on a bit differently so how can we possibly return void inside the right side of either well can we actually return void directly let's see once we import either from darts it seems that we can actually return void but I will tell you bad news and that is that once we would try to run this code having void inside the right side of either would not actually work well it would simply create a bunch of problems down the line for us so we cannot use void even though it doesn't really create any syntax error right off the bat so if we cannot use void what can we use well if you are a swift programmer you know that Swift's void type is actually a type not just a keyword right if we try to go to void definition there is nothing in there but if we try to go for example to another built-in type definition for example future is built into the dart SDK we can actually see the definition of future that because future is an actual class but void is not a class at all it's just a keyword but in Swift void is an actual class it's actually an empty tuple similarly Carleton programmers know that there is no void in crafting but there is unit in cotton and unit is sort of like void and now if you are a category theory mathematician and a functional programming professional please don't kill me I know that units and this sort of down voids are not the same thing but just for the sake of simplification I think that saying so is it's good thankfully we can also use unit type which comes from darts if we take a look it's sort of a empty two-pole right at least it indicates to be so in the two string just like in Swift but regardless of how this unit is implemented we know that this is a regular class so we can actually have it as the type parameter of either all right that was quite a long explanation but I needed to go through it and so that you understand why we cannot use for it that's because void is not a class in Dart it's just a simple keyword and now we can just copy this either and paste it into all of the other future type parameters so now these functions return future of either an off failure or unit which you can also basically read void so these either don't return any value or they return a failure and what's perfect about this sort of a signature for a method is that even though now it may seem sort of an overkill to return units rights and all that for when the sort of correct value of a function is void if the return type of a function is an actual value so let's create some sort of a return the value right value string for example so if a function returns a string there is nothing more simple than to change unit to string and now we have converted this return type to hold either an all failure or a string and it was easy to do so right but when your functions or methods return void you are going to change it to unit if you want that void to be present inside either all right if you want to go through this tutorial at your own pace once again and to get all of the code check out the written tutorial available from the link in the description so we have created an interface inside the domain layer which will allow us to implement the application logic without any firebase of dependencies because after all this is just an interface and it has nothing to do with any sort of a firebase implement they and we have also thought through the different of failures and we have come to the conclusion that there are really four failures which we need to handle in our app and lastly we have also discovered the unit type which is sort of a void with more functionality this means that we are now completely ready to start implementing the sign-in form and we are now going to create any buttons and text fields inside the UI just yet instead we're going to hop into the application layer to work on the sign-in form block in the next part so definitely make sure to subscribe to this channel if you do not want to miss it and if you are serious about becoming a great flower developer who can build real apps for clients or at the job go to flutter that education and link is also in the video description to get the top curated Futter news and resources aimed at improving your app development career over there you can also subscribe to my mailing list to get the best photo resources delivered weekly right into your inbox and if you do not want to miss more tutorials like this be sure to subscribe to this channel and also join notification squad by hitting the bell button to make sure you grow your flutter skills because here are reso coder I am just determined to provide you with the best tutorials and resources so that you will become an in-demand flutter developer if this video helped you with modeling your facade interfaces and all that give this video a like and also share with our developers who are surely gonna find it beneficial to leave a comment if you have anything to say see you in the next video [Music]

Channel: Reso Coder

Views: 17,429

Keywords: resocoder, tutorial, programming, code, programming tutorial, flutter, flutter tutorial, flutter firebase, flutter firestore, flutter firebase auth, flutter firestore tutorial, flutter firebase tutorial, flutter architecture, flutter architecture patterns, flutter domain driven design, flutter ddd, flutter database, flutter todo app, flutter todo app tutorial, flutter todo app firebase, flutter app tutorial, flutter app example, flutter clean architecture

Id: jNF48xIfnq8

Length: 24min 20sec (1460 seconds)

Published: Tue Mar 17 2020