Should I Use An Embedded Database In My Mobile Application? (Podcast Transcript)

Amy Tom chats to Jens Alfke about embedded databases in mobile applications and how they live within your application and sync to your server. Jens is the Mobile Architect at Couchbase and a former Software Engineer at Apple. They talk about developing a mobile application with an embedded database vs a database on the server, edge computing, and the technical skills required to implement embedded databases.

In this episode, Amy and Jens talk about:

• The use of a mobile database versus a database that you would develop on desktop (03:45)
• Edge computing's role in embedded databases (17:40)
• The reasons why someone would implement an embedded database into a mobile application (21:12)
• The skills required for developers interested in embedded a database into their mobile application (27:38)

Follow Jens Alfke + Couchbase:

• Connect with Jens on LinkedIn
• Learn more about Couchbase's embedded databases

Podcast Transcript (Machine Generated - Please Excuse The Errors)

Amy: [00:00:00] Get in losers. This is the hacker noon podcast. Unfortunately, none of us are wearing pink. It's not Wednesday and we're not going shopping. But here we are. My name is Amy Tom, and joining me today is Jens from Couchbase. Jens, how are you doing today? 

Jens: [00:00:28] Doing great. I'm not wearing pink, but I do have a red t-shirt on.

Amy: [00:00:32] Yes. Close enough. Close enough. Can you tell me a bit about your background before we get started? 

Jens: [00:00:38] Yeah, let's see. I spent most of my career at Apple doing various stuff in MacOS as the most visible thing I did was I chat, which has no messages. I was Original tech lead implementer. 

Amy: [00:00:51] You're the I chat guy.

Jens: [00:00:53] Yeah, it was kind of, my prototype for a year before it became an official product. So I got to get my fingerprints all over it. So to speak, like chat bubbles were my idea 

Amy: [00:01:07] What year would you say that was in? 

Jens: [00:01:09] That was like 2000 to 2003 or four that I was working on that. But before that I worked on scripting languages, Apple script.

I worked on the Java implementation. Did a bunch of RSS stuff like a RSS reader, newsreader that was in Safari for a couple of iterations. And then I've been at Couchbase since 2011. So I'm coming up on my ten-year anniversary. Thanks. Yeah. There's only a handful of us left who have higher seniority than me. So it's fun being like the old guy

Amy: [00:01:41] so let me ask you this. What was your very first job ever? Mine was working at a bike store. 

Jens: [00:01:48] I work for AMD actually, when they were a lot smaller this is like a summer intern job. My dad was working there doing a hardware stuff and he got me a summer intern job helping with write documentation for some software.

And I was actually, when I learned to see any education prior to that do you mean like tech stuff? Yeah. I was super lucky to have been. A kid like in Silicon Valley, right. When the first personal computers were coming out. So right at the time of the Homebrew computer club, the Apple two, a TRSA, all that stuff.

So you were talking like 77 and I was how old I was like, 12 years old then. And I had just discovered computers and running little basic programs on a teletype and the idea that you could have your own computer, like that could be sitting on your desk at your house was just completely mind blowing to me.

So it was super cool to be there and actually see all these things coming out. 

Amy: [00:02:52] Oh my goodness. What was your first computer? 

Jens: [00:02:55] An Apple two, which I begged my parents for years.

Amy: [00:03:01] And, I don't even remember this. I remember dial up for sure, but that probably came a bit later. Cool. So  what exactly do you do at Couchbase?

Jens: [00:03:12] I am a mobile architect on one of our two mobile architects, which means I'm defining the how we. Build how our mobile database works are just called Couchbase Lite, which Is a separate thing from the server database and it's intended to run on mobile phones, iOS, Android, but also can run on desktop machines. And we're pushing into IOT territory like a raspberry PI level devices. 

Amy: [00:03:44] Okay. Let's talk about the implications of a mobile database versus a database that you would develop on desktop. What are the differences? 

Jens: [00:03:54] It's actually not too different from what you would do on a desktop, but the most people are used to databases being servers.

Couchbase obviously Mongo, DB, SQL Postgres, so on the difference. With a mobile database or desktop, is that the database is a library that's built into your app. So it's not some separate server you talk to. And of course you're generally not storing as much stuff in it. You're probably not going to have terabytes of data.

Amy: [00:04:21] Right. So the. It, the database is embedded into the application? 

Jens: [00:04:25] Yeah. So the the customers who are using this are companies who they use Couchbase server and they want a mobile app that can access the data on the server access or create even if so the typical way that you'd go about doing that is like a client server thing where you'd like, generate some kind of rest where he is and send them to the server and then get back this.

Bundled Jason that you take apart until you have this kind of client server round trip for everything that you're doing. The approach that we use is that the database lives in your app and is synced with the server. So all of the database queries look-ups updates that you're doing are local, which means zero latency, pretty much, we're talking file system access.

You can just do all this stuff. As though you're just some local app and, but you know that if you make changes locally, they are going to get pushed up to the server in the background. And that changes from the server are going to get pulled down into your local database on a best effort basis.

Amy: [00:05:26] Okay. So as I understand, one of the biggest challenges that developers have when they're creating mobile apps is keeping the local data in sync with whatever's on the server. Is that something that you experienced as well? 

 Jens: [00:05:39] Yeah, we do, because we have to implement this stuff, but the goal is that we keep our customers from having to deal with it.

know, Like at the end, like I said, you could just have an app that uses It's just a pure client. It just, every time it needs something, it goes and asks the server for it. And that's easy to do, but you tend to have performance problems, just latency of having to hit the server all the time.

And so then people will go, okay, we're going to catch some data. If we've, if we're like on a flight booking app, then we are going to cash like the flight schedules so that we can show them quickly. But then you have, the old thing about the. Two hardest things in computer science are naming things, cash and validation, and off by one errors and cash and validation, right.

Is how do you know when to stop fulfilling the request from the cash? Now either you have to say, we're going to read from the survey every five minutes. In which case you might be showing up obsolete data for five minutes or the server's going to have to tell you when to update data. Which has a lot more complexity.

So we go the full Monte of that way of all the data's cash, all the data that you need, but we take care of the hard part, which is making sure that it stays up there.

So the cool thing is that you can develop your app as though it was just a disconnected local app. No, you can really do most of the development and testing that way because you're working with a database, you put stuff in the database, you get stuff out, you add up some observers so that when a document changes in your database, you update that piece of your UI.

That's displaying it. And then you turn on replication. You just give it a URL of the server database to replicate with. And that's pretty much, talking to, simple general case. That's pretty much all you have to do. Because now it's just in addition to the user making changes to the database, the replicator is doing the same thing in the background and your app just displays those updates.

So instantly got this network, connect the database without even really having to think about the network very much. 

Amy: [00:07:50] Right. Okay. What are some other examples of an embedded database that you might use? 

Jens: [00:07:58] The most common one is SQL Lite, which is in fact it's they claim it's the most widely deployed database in the world that they're they asked me if there may be like trillions of SQL Lite databases out there.

It's literally on every mobile phone every set-top box, every router most cars. So on. No, it's because it's this tiny little library and see that you can put anywhere and just store data. We actually take advantage of that. We use sequel light under the hood, which is a little bit of a weird thing, implementing a, a no SQL database on top of a SQL database.

But we just use it for storing keys and values and the advantage is it's a tiny library. It's. Already available on every platform and test it on every platform. And it solves the really hard data level problems of acid properties of the database, not destroying your data, if it crashes, things like that.

And so then we build our stuff on top of it. Mobile developers might be more familiar with some higher level ones. Core data on the iOS platform is also on top of SQL Lite, but it's, Apple's mechanism for doing data persistence. Okay. What do you mean by data persistence? It's, w with core data, you don't really think it's so much like a database, just like you create objects in objective C or Swift, and you just add them to a container and they get stored there and they're persistent, so the next time you start the app, the objects are still there. We expose more of the database and less of it than that does, but still it's, It's that you can put document as we call it, Jason documents into your database and it stores some there index system that lets you acquire them efficiently.

Amy: [00:09:37] Are there security implications of having an embedded database like this? 

 Jens: [00:09:41] To some degree just because, know, you've no longer just got the data living on your server. You've got it living on these devices too. And then there's a couple of answers to why this is not a problem. One is that a lot of mobile devices have pretty strong encryption like iOS does.

All of the. Pretty good. The entire file system on iOS devices encrypted, and it's pretty difficult to access as the FBI has found out. We also support our own level of database file encryption in calc light. You can use you can make it so the user has to enter a passcode to access the data, for example and that the whole data database files encrypted, and then also the The sync protocol does access checking on the server side to make sure that a client database that's connecting is only able to fetch the data that they have access to.

So you can't have like really sensitive data getting out of your server. 

Amy: [00:10:38] Right. But what kind of data might be in an embedded database? 

Jens: [00:10:44] Oh, it's there's a lot of examples on one of our earlier earliest kind of poster children for this was Ryan air, which is an airline that operates mostly in Europe.

And they had a mobile app for doing per booking flights, but they were unhappy with the performance of it, because it was doing this client server thing, hitting their servers all the time to get the data and they. Wrote a new app using Couchbase lights so that the the app was always in sync with their Couchbase server that had the kind of master flight schedules, pricing, all that stuff in it, which of course updates all the time because the airlines were always changing prices around us.

They fill up seats on a plane and they give a demo where they showed literally two phones side by side, one of them running the old app, and one of them running the new one and someone making a reservation for a flight on both. And it was just, it was funny that the one with the new app was just going, they were just did the whole thing in 30 seconds.

Whereas the other app, there were these long pauses while it would sit and be pulling up. The flight data, and then they pick a flight and there was another pause as it went to look up what seats were available and then another pause to actually, find the prices and so on.

So they gained a lot of performance which they said converts to more people booking flights. So even though the data is embedded within the application, it's still faster because it doesn't have to ping back to the server is what you're saying. Orders of magnitude faster. Because even in the best case especially with mobile networks, they tend to have higher latency than wired networks.

You're looking at higher costs just to send a round-trip request. And then it's got to hit the server where you've got, hundreds of thousands or millions of clients. We're all hitting these servers. Doing the same thing, getting these queries. Yeah, you can, you can get a result out of your database in maybe five milliseconds, whereas pitting the server and getting response back might take the order of know, a second or two or in the worst case.

Amy: [00:12:42] Right. And if I am a developer and I want to change some of the records in my embedded database, is that a quick process as well? Or does it take some time to, for the changes to take it back? 

Jens: [00:12:57] Yeah. Will doing the changes locally is super fast. Generally it's going to depend on the performance of the flash memory and your.

Phones since we were talking phones, usually, which will vary a lot by device. But like on iPhones you can insert like, Oh, probably like at least 5,000 records a second, you can just update stuff really fast. And then you said, then you've persisted the local change. And the replicator kicks in.

We'll send that to the server. As soon as it counts. So often while the app is running, you'll have a live connection to the server running over web sockets. So it will just, batch that up to our request immediately and send it to the server. But if you're not online, like you say, you're down in the subway or something.

When you make you edit your thing, there's no connection. The app will keep monitoring the network. And when it. When you come up to the street level and it can reach the internet can reach the server will then open a connection and sound it up as fast as it can. 

Amy: [00:13:55] Right. Okay. That makes sense. I think that's like with everything as well.

If I am a developer and I am trying to develop my first application with a mobile embedded database, as opposed to on the server, is there any additional technical knowledge that I need or what I already have all of the tools.

Jens: [00:14:15]  I would guess easier because if you're going to be talking to a server, then you're going to need to know okay, what's the.

You know what let's say, it's a rest API, which most of them are. So then you're going to need to know that the whole scheme of what are all the different endpoint URLs I can hit? How do I format the Jason to do a particular request? What kind of series of requests do I have to do to first first get this entity and then look through the data and get this thing and then send a request for that thing, and then doing all the Jason parsing to get the stuff back using. Couchbase light. There's really, you don't need to know about that stuff. You just pretty much need to know what the scheme of the database is, which, that's Jason documents, that Nam document for storage, Jason. So it'd be like, okay, this is the property that's used for this.

We're storing this property as an array of values that are, maybe they're all strings, whatever you just kinda need to have that basic schema. And then it's a pretty simple API where you just open the database, you say, okay, get me the document with this ID. And then you get it back as Jason, or you can construct a query where It's we don't actually use CQL, but it's a similar approach.

So you would say let me, I want to select these properties out of all of the documents that match these criteria. So you might say the type of document is airline and I want to get, all of the flights for the airline, with this name, and it's returned to you, this numerator of all the flights that, the Jason object with all the flights and then.

Amy: [00:15:54] Right. How long would you say it takes to develop a mobile application with an embedded database start to finish?

Jens: [00:16:01]  It depends a lot. A lot of it is learning curve. But I've I've put together simple apps in, in a day or two. And really like most, once you get past the learning curve part, I think most of it is UI.

Which is good because that's the part that most developers are already familiar with. Unfortunately I don't spend enough time. I don't get enough opportunities to be messing with, table views and view controllers and all that stuff. I mostly buried down in the low level C plus into grudging.

But so that part's always the hard one for me, but once you've got that stuff, it's really easy to hook those things up to aquarium, just, get the query results. Pull it all up as a table, you, we have a thing called live queries, which is really useful for this, where you can run the query and then you get your results set.

You know where to probably let go put it into a table view or a less or something like that. But then the query will keep notifying you whenever it's results change. So if something changes in the database, it'll say, Hey, new results. And then you just go and update your GUI. Right. And would you say that there's a lot of planning that's required before you start building.

There's for any app, ideally I think most of the planning actually goes on what happens at the data level, because obviously your server and your client are going to be sharing the same documents so that you need to come up with what the schema for your document is going to be. Not in the really strict form of SQL database, but just, these are Jason objects.

What do they look like? What kind of keys are we going to use? And Yeah, you just need to be sure that the data that's being used on both server and client is you both have the same understanding of what the schema for it is. 

Amy: [00:17:39] Right. Okay. I want to talk to you about edge computing. It's become a big buzzword over the past little while, so I want to get  together on what the definition of edge computing is. So what would you define it as? 

Jens: [00:17:55] Yeah. The way I think of it is that every once in a while, people rediscover the fact that the computers at the, at, know, the computers that people are using are not just dumb terminals, but are actually pretty fast and smart.

Like that happens. Like I said, when I was a kid Oh, wow. Now you have this Apple too, and you can dial up to something and display it. So you've got stuff like CompuServe, where you could actually have some kind of graphics or AOL. And then, everything's spinning with the web.

It happened again. And. Then we've got, went back to the cloud and now people are discovering again that, yeah, maybe we should like take advantage of the CPU on all of these phones and watches and IOT devices that are all over the place, because these things are as fast as our mainframes were a couple decades ago.

So yeah. It's taking some of the load off of your servers, your cloud infrastructure by doing more of the work. Closer to where the people are. Yeah. It seems just like a very broad term, as well as IOT is becoming a very broad term cloud, people love these like super vague terms that they can use as my words.

Amy: [00:19:03] Yeah. But what does it really mean? Yeah. And what is edge computing's role in embedded databases? 

Jens: [00:19:11] Yeah I think just having a database. At the edge, like on a user device that is edge computing on its own. And it's doing a lot of work to take a load off of the server because every query that you're running locally on your device as a query that the server doesn't have to make.

So if you've got a million, Of your application out there and they're all doing their queries on it, locally, your servers, you've just saved your server millions of queries per whatever per day or whatever. Right. And further than that with, if you're using these devices to enter data if they're some kind of, data collection thing, like maybe an IOT device, then you can do some kind of prepping or aggregation of that data before it gets up to the server.

Like maybe the server doesn't need to know every single temperature reading on your device. You can collect them and generate some statistics on those and then send those up to the servers. So the servers only. It needs to get a hundred numbers instead of 10,000 numbers, but we love to collect data for no reason.

Yeah. Was still on the device. Right. So if the server needs more data than you could have a way of getting that up to the server, 

Amy: [00:20:28] Yeah. I feel like with data and big data and everything like that, people are more like, what if I needed in the future? I should just have it. I'll just take it. But it does have a big load impact on the application or the server or wherever you're getting your storing your data. So that's a good thing. 

Jens: [00:20:48] Yeah. Plus, you could send the data up to the server, but maybe there's some kind of Pre computing or aggregation that the local device could do. Even if it takes the little IOT device, six hours to generate this computation, whereas the server could do it and in 30 seconds. It's still worth it to have that device doing it because it's on anyway. 

Amy: [00:21:12] So if you had to sum up, then why would you say that having an embedded database in a mobile application is important? 

Jens: [00:21:21] There's a lot of reasons. And I think user experience is a big one. This kind of, low latency having offline access is really big.

I know of applications where people have used these types of databases in refugee camps, like aid organizations, working in refugee camps where there's no infrastructure, that. This is like a war zone. There's no cell network. They can like have their workers go off and collect data on, sanitation or health or whatever.

And they can all get together at their local wifi in their tents and and then put all their data together. I think also it's, I like use cases where there isn't necessarily a big server involved. The way that I actually got into this whole field, I didn't use to be a database guy. The way that I got into it was through being interested in peer-to-peer applications, peer to peer networks, where how could you just let people create stuff themselves and share it with each other without having to have it go through a server?

Like I keep dreaming that Sunday. I'm going to have time to write my Facebook killer. My peer-to-peer Facebook killer. You don't have to worry about some mega corporation monetizing all of the posts you write or things like that. What is so appealing about peer to peer technology? I think just that you don't need infrastructure for it.

You don't have to, or you don't have to set up a server somewhere and then administer that server. You don't have to deal with logins. You don't have to. Once you have a server, you have to pay it around the server and. Then you get into, like, how do we make money off of the clients? That generally leads you into advertising.

And so now you're serving ads to clients and now to make yourself appealing, you're giving the advertisers, all the client juicy details of the. Stuff that they're posting, it's not like Facebook set out to be evil, that it's just this very slippery slope, that. If it's peer to peer, you don't have any of those temptations where it's just an app, you just distribute this app.

And if you have a million users, it's not your, it's not costing you the developer anymore than if you have a hundred users because they all bring their own. 

Amy: [00:23:45] Right. Do you think that this comes to back to decentralization?  

Jens: [00:23:50] Yeah. The, there's still a lot of good reasons to have servers to have, collect it in one place.

I think there's definitely applications though. People's personal data stuff people are sharing with friends and family and so on where I would prefer to see that kind of stuff, the not being stored or accessible to places that aren't those peoples. What do you think the implications of that are?

Great question. Yeah. We, I think we have negative locations just from the way that things are now. So hopefully things could be better. There's a lot of people working on this and different ways and yeah, there's decentralization happening with apps like mastered on and so on, which are more federated where you have lots of different servers, but Yeah.

And there's possibilities like it's called sometimes called translucent data where the data is stored on a server, but it's still end to end encrypted. So like I could encrypt a record on my device and then it goes up to the server, but all the server sees is encrypted data, which preserves privacy.

I have another question that I have, sorry to cut you off. Is there a use case or a scenario where it would be better to put your database on the server as opposed to embedded into the application? 

Yeah. I think if the data set that you need to query is too big. Then... ha. It depends on, it depends on the use case, right?

So maybe you have a gigabyte of data that needs to be queried. That's actually feasible given, current, your current phones coming out that have they're coming out with ones that have five, 12 gigabytes of storage now. Just them saying, and if you've got really fast internet, then you could sync the gigabyte database to that.

There's always going to be data that's bigger, okay, now we have a terabyte database or something like that. So if you need, if the queries you need to run, have to be able to plow through that much data. It's not really going to be practical to put it onto a local device, so you might like instead. Do you know, do a partial query of it and then narrow it down and then talk to the server to do the rest of it. Okay. Can I do a hybrid of both then? Yeah. It just takes more work. So you could use the local database for the data that, that it's okay to sync.

And then you do use a more traditional web application approach or, or rest API approach to talk to your server side. Server out to get the rest of the data. Okay. So I just gonna take a lot more upfront work then. Okay. Yeah. It, conceivably, that could be.

Automated a lot more, but it hasn't been yet. So you'd still have to say, okay, now we fall back to the client server approach and have this rest API that's implemented on our server that will look update on the server for you and send it back. So do you not have very many people do that then? It hasn't come up as a really big thing.

I'm at one or two levels of removed from the customers themselves, know, I've got product managers and support people and so on in between them and me. So I don't know if it just hasn't come up or if people just don't mind doing that kind of stuff themselves, a lot of the time people will have a web application anyway.

For accessing stuff in addition to a mobile app. So they may then already have that kind of rest API setup. If it's something that the JavaScript in their web app is hitting to do those same queries, then it's okay, we can just write some code in our mobile app to hit those same rest end points and get the data.

Amy: [00:27:38] Right. That makes sense. Do you have any advice for aspiring developers who might be interested in creating their first mobile application? 

 Jens: [00:27:48] Yeah. What comes, what I keep coming back to is that I'm in that position because every time I have the time to write a mobile app landscape has changed, i, like I'm, I know iOS I go to write an app and like now they've got, these new layout mechanisms and then, okay, next time I go to write an app.

Now they've got Swift UI and I'm like, okay, cool. Swift UI looks really great. I'm going to learn that. And so next time I do something, there's probably gonna be something different. But I think just the, knowing the whole architecture for how you build things with views and controllers and so on is.

Amy: [00:28:20] Yeah. What would you say is the essential technical Nicole baseline knowledge that you need to have in order to start?

Jens: [00:28:28] I guess just, working knowledge of the language involved, which there's a lot of choices now. Yeah, that's one possibility. If you're using something like react native, I tend to prefer like, Using the more of the core languages of the device. I feel like you get better performance and better integration with the platform. So these days I'd use Swift. 

If I were an Android developer, I'd probably be looking at Kotlin just because it looks like a more modern language than Java. Is there any implications between iOS development and Android development and when it comes to embedded databases?

With both of them, you can use Couchbase light and the API is pretty much the same. We work hard to make the API is compatible on all the different language platforms we have. For the record, we also support dot maps. So you can write in C sharp or other.net languages on either of those platforms.

Yeah. So it's not very different between iOS and Android, then if you're using Couchbase Lite. Yeah. If you're not, then I, again, I'm not very familiar with Android. So I, there is a library for a higher level wrapper around SQL Lite. It's probably not exactly the same as core data, but hopefully it has similar attributes.

You don't have to keep it. You don't have to write out these a select few from blah, blah, blah, Aquarius. You can just worry about like you're creating objects and storing them.

Amy: [00:29:59] Right. I know I'm not a mobile developer. So I think I'm just not familiar with this, but is it common for people to be both an Android and an iOS developer? Or do you usually stick to one.

Jens: [00:30:12]  I imagine people mostly stick to one just because the API sets on both are pretty deep. And, I think you'd probably end up like having to keep paging out your knowledge of lawn and paging in the other one, which is a mess and unpleasant to me. Every place I've worked at, there's been mobile development.

We've had here's some iOS engineer, here's an Android engineer. 

Amy: [00:30:33] Okay. So people specialize in a certain thing that makes sense, because it's such a deep set of knowledge that you need to get into

Jens: [00:30:41] are higher level frameworks. You can use that let you develop for both. Like I said, react native for doing JavaScript development or you can use you can do.net type development on both platforms using different adopter libraries.

There's trade offs, right. You obviously save development time writing in a cross-platform framework, but you lose tend to lose performance and access to all the kind of specific APIs on the different platforms. 

Amy: [00:31:08] So that's not necessarily what you would recommend then. 

Jens: [00:31:12] Yeah. And I think things have probably gotten a lot better.

It's my my history is Apple, right? So I worked at Apple back in the day. It was like a lot of applications. People like people would develop for windows and then just do these half-hearted Mac ports of them, or they'd, there were some kind of cross-platform libraries for doing stuff, but they always tended to look really crappy, at least on the Mac.

 Pick your platform and then write something that's really good for that platform, because you can tell as a user, you can really tell. 

Amy: [00:31:40] Yeah. I was going to say, I feel like I notice when a application is developed and intended for iOS versus intended for Android, and then they just converted it for the other one.

Jens: [00:31:51] Yeah. Or you get these, like now you get these applications that are built with Adam where it's it's a website, but they've just packaged it up into a double clickable app. Like in Slack, Slack is like that. A lot of the desktop apps, from like web focused companies now, or like they're built that way.

And you can tell because the whole thing runs in one window. And if you go to the menus, there's like practically nothing in the menu bar. And it doesn't really play nice with a lot of platform features like sometimes drag and drop won't work, right. Or you just, things don't behave kind of the way that you expect.

Amy: [00:32:24] Okay. Okay. I feel like maybe you can tell, but I can't tell. 

Jens: [00:32:29] Yeah. Like I said, it works pretty well, but but the cracks will show up.

Amy: [00:32:34] Yeah. Okay. Okay. Actually, here's a good question for you then. What do you need from an app in order to consider it a good application? 

Jens: [00:32:44] It totally depends on the app, right. With a game. I don't really care about how it fits in with the platform. Games, aren't going to use normal looking buttons. Right. They're going to do some special buttons and that's themed like their game. So there it's like mostly, okay. Is it performance?

I'll actually, I'd like to be able to share my saved data across devices. And that's something I know that varies with operating system. Apple's got their own. My cloud API is for that on Android. But if it's like a productivity app that I, I want it to behave the way I expect.

Have the, if it's an iOS app, I want to see the, the now far along the bottom the different tabs. And I want it to share stuff with other apps. Things like that. Yeah. UI is super important. And then, okay. Cool. Cool. Any final tips for aspiring developers from Yens?

Yeah. I think, given the theme of this, if this show that I waited too long before, like diving into databases. Right. And even if you don't think of your app as needing a database, it's Oh, I'm only going to be storing a couple hundred things or a thousand things, I can just put those into a Jason file or, or something simple like that.

It actually makes sense to use a database nowadays because the API APIs are pretty intuitive and it will just save you a lot of work later on. You don't have to deal with You don't have to load everything into memory at once, which will speed up your launch time. You never get corrupted files because database is like, if they have one job, right, their job is to not lose your data.

And they do that really well.

 And I suppose it's more scalable for if you're just starting out as an app and you're growing it would be more scalable to start with a database as opposed to converting to it later on. 

Amy: [00:34:31] Yeah. Because you tend to, I think at any kind of domain, you tend to run into people who are just like trying to push your product.

Past what you thought the limits were. Yeah. You might think okay, I'm just going to store all the records in this Jason file. And then you get somebody who's using this and it's I've put 50,000 records into this thing and it's really slow starting up and it takes forever to save. And you're like 50,000.

Wow. I'd never really intended it to get that big, but yeah, sure. Why not use something scalable for your data? 

Yeah. Okay. Yeah. Thank you so much for joining the podcast. I really appreciate it. 

Thank you so much. If you like this episode, you can catch us at hacker noon on Twitter and LinkedIn and Instagram.

If you didn't like this episode, it was hosted by Limarc. Thanks, bye.