Hey, this is a Daily Overpass. My name is Eric and I make apps. Now today, I want to
talk about, App versioning and Databases.
Okay so today I want to answer a question that came in last week from Ian Chui
who said, "I actually have a question I'd like to ask. It's somewhat
technical so I understand if you don't want to make a vid. I'm planning on
releasing a react native app soon and in the app I have interactions with the
firebase database." That's really cool. "I am worried that in the future I will
want to update the app and/or the structure of the database but users with
the old version of the app will continue to write data using the old code and the
old structure. Do you have any insights on this. Thanks." Yeah this is one of the
things about mobile applications that we don't have a lot of trouble with on
the web because in a lot of applications you'll do your database and your
database could be in whatever format you want but your front-end is also on a
server so you could release both of them at the same time and unless you have
something like offline content. Most of the users get upgraded to the new
version at the same time so you don't have to worry about people saving in two
different ways. So we have to think about this a lot in terms of the backend
database to make sure that we have the data right. So I'm going to do something
a little bit different today. I'm going to show you, we're going to go
through some diagrams here just for those of you guys who might not know
what we're talking about. When we talk about this grid making sure
your data is right on the back end. Have a look at my iPad here. You can see most
of the time when we do applications - and I'm sorry if this is really simple, we'll
do something where we have a database and we'll have that API or business tier.
And a lot of clients we have, I have to explain what an API is and it's really
difficult. But basically, it's just like a a bit of cloud functions up here
that says, "get customer" or just say "get customer",
log in user name and password.
Sorry, my handwriting is really bad. And so, you have these functions so that your
application could just call that in the web and that API tier will interact with
the database and everything too. And if you even have like an admin site or
something. You can have that also feed off the API tier so that most
of the business logic is here in the API tier and you could have still a lot in
the in the app too - but it has to go through the cloud here to get to it, so
that's most of the time that's how it works.
Now, the thing about firebase and the newer real-time databases is that
you could connect straight to them. So you don't really need that middle tier
or the API tier and the cool thing about that is that it just updates
automatically and you put all of your logic into the app so you don't really
need that business tier logic.
You don't really need the
business tier logic anyway but it's good to have it because it protects
everything. Now the problem with this is and what Ian's talking about is that,
let's say you change the logic of your application and then you have people
using the new version of the app 1.1 and people using the old version of the app
because they haven't upgraded because that's still out there and maybe you
made some changes to the database structure and you can immediately make
version 1.0 stop working or like Ian says when they save the data in one
structure and this is expecting it in another structure. Then it messes up and
it's not so bad with the update because the update that knows
the old structure exists but the first one doesn't know the new structure
exists. If you know what I mean so that makes it difficult. One thing about
firebase, is you can still have that middle tier if you put like cloud
functions so even though you're going straight to firebase you could have
cloud functions that do the same thing as an API does and says you know get
customers and you could do that so one of the benefits of having an API, let's
go back over here - is if you had an API you can make sure that the apps get the
right data in the consistency that they expect. So let's say...
Let's say in version 1.1, we're using this is the same
concepts with sequel but we're talking about
no SQL, we're talking about firebase. Let's say in 1.1 we store data in this
way so we have a name, we have a age and we have address. We have a single
address per user. This is a very simple example but then you actually start
using the application you start realizing you know what it's really
difficult to have just one name I want to sort by surname and I want to
be able to put Mr. and all this kinds of and it's nice you
could always parse it in the middle for first and last name but maybe somebody
has three names or four names it gets more complicated. So then you want to
move it into first name, last name and what happens is on version 1.1
if you went through and updated that. That would break because that's looking
for the name field and also let's say that instead of one address you want to
have multiple addresses because they may want to have their home or their office
so you want to move it into multiple addresses and the problem with we're
talking about here is that if app 1 is expecting one bit of data and app 2 is
expecting another bit of data.That messes everything up so one of the
things that we always try to do and it doesn't work because you have
to try to anticipate a lot of things. Is anticipate everything that might be
necessary in the database and the reason I say that doesn't always work is
because no matter how much you dream up like multilingualism likes a
multi-language we've done us so many times where we have a drop-down in an
application. So let's say you have a drop-down of favorite ice cream color
and it's all in English and then we want to release a Spanish version of the
application if that comes from the database and all of a sudden we have to
add another field to that table of which language is this listed because we want
to translate all those options otherwise the rest of the app is in Spanish and
everything that comes from the database is in English. So and that's one thing
that you might be able to anticipate but it's really really hard now so what I
find to do and this is from learning is to have something in the
database like just one node that says what the version is that you're
expecting. So let's say here, I put app-info you don't really need info. Let's say
the API version, so you might have a version 1.1 of the app version,
1.2 of the app version, 1.3 and the API version stays the same because you don't
really need them to upgrade if everything will still work but when
you have a breaking change into API at that point it would be good to say the
API version required is 1.1 and that way when app number one opens up. Let's say
go back to the single tier app number one opens up it checks that node it says
what is the version of the API I expect I think it should be 1.0 and it comes
back, says no you need 1.1 at that point then you have a pop-up that says, "Please upgrade"
and that's probably the best way to do it just to get everybody on the
old version, up to the new version. Now most of the time you don't think about
that until after you release the second version which makes it really hard so
something to think about when you release your first version is if that
data is going to change if that database is going to change, if you gonna make
some big API or database changes on the backend how are you gonna handle it for
those old applications? And I've learned for so many times the hard way that we
have something out there that's already released that the clients will say,
"What about all the people who have the old versions?" and I say well there's nothing
we could do about them it might just break or we need to find some way in the
API to give them a little bit less data than than they have and also let's go
back to this one here another thing to do this example here where I got name
and then I got first name, last name. Always try to keep the interface the
same if you can so even though it's a bit redundant have name here and first
name, last name and you could have a trigger using a cloud function that
every time you add first and last name it automatically populates so that
version 1 of the app still sees the name fields and those kind of breaking
changes could be really difficult. Especially if you go through and I'm set
up age I want to put years right that just breaks everything so you
try to change the database as little as possible. It could still be done but it
gets tricky and the versioning especially on the server is probably one
of the most important things you could do. So I hope that makes sense I help
that help and I'm sure there's people out there with more experience
than I do in this and you have other ways that you do it, please put it in the
comments because I'm sure this will help Ian it will help everybody else whoever
works with it and anyway that is it for today. I'll talk to you guys again
tomorrow.