EmpowerApps.Show
EmpowerApps.Show
Cloud and Backend Services For Apps
Previous Episodes
Define Whether You Do Need Cloud or Backend Services
You Do Not Need If…- Privacy-Sensitive Data
- No Cloud Backups Needed
- Already Storing Using a Third Party APIs
- Example App Developed by BrightDigit - CE Genius
- Multiple Devices In Sync
- Cloud Backups Nessecary
- Example App Developed by Shiny Frog - Bear
What To Consider When Deciding How To Store Data?
- MVP vs Enterprise
- What is an MVP? Most Viable Product
- Start With the User - Project Estimation Episode
- What Devices Does the App Support?
- How Complex is the Data and Queries?
- Are Outside Jobs Needed?
- Such as Cron Jobs, Backups, Push Notifications, etc…
- Consider Prices - Bandwidth and Storage
- Consider Developer Team’s Comfort Level
- Develop Abstracting User Experience From Data Layer
Build a Custom Web App
Virtual Machine OptionsWeb App OptionsDatabase OptionsProgramming OptionsSwift OptionsServer Software OptionsOther Software ConsiderationsMobile Backend As A Service
Music by Roman Bulakhov from FugueFull Transcript
[00:00:00] Erik Gillespie (Host): Hi Leo, it's me. Again.[00:00:01] Leo Dion (Host): Hey, Eric. Glad to have you on to help host this episode. So today we're going to talk about back-end and cloud services for your IOS app. And I think first we should talk about when you should need a back-end or cloud service because I don't think it's needed in every absolute case when it comes to an IOS app or any mobile app.
[00:00:25] Erik Gillespie (Host): Yeah, I'm really curious to hear what your ideas are on this.
[00:00:27] Leo Dion (Host): So one thing to consider is there's a lot you can get away with without even doing cloud services. The thing with an IOS app is if you're storing your data in something that is like iCloud or in a lot of cases people really don't need the cloud to store their data. They can just sort on their phone itself. I think often times when we think about building an app that's something to think about is like do you really need this stored in the cloud and if you maybe can provide a manual mechanism to backup the data into some sort of iCloud storage as a file that saves a lot of trouble and saves you a lot of time and money quite frankly when you're building your mobile app. And then that way you don't really need a cloud service or a back-end service in a lot of cases.
[00:01:15] Erik Gillespie (Host): What are some situations where you think it's okay to go with a back-end service or on the flip side choose to only or mostly store things directly on your users phones.
[00:01:27] Leo Dion (Host): I think anything that's privacy sensitive. I think you should definitely just store on the phone locally because that's a whole other headache you having to deal with if you're worried about that stuff being stored in the cloud and if it's very simple stuff if it's things that they just need on their phone and if they lose it, it's not the end of the world I think it's totally legitimate to only store that stuff on the phone. Also, if you're using any third party apis in other words. Like let's say you're using Twitter or YouTube or some other API where you're not really storing data. Data that's being stored is essentially being stored in this third party structure than it's not really necessary because you can just use that third party API as your database in many ways.
[00:02:06] I'll just tell you one case I built an app for nurses and doctors to do continuing education for their career and all that data was just stored in core data, which is essentially a SQL lite database abstraction layer. And so all that stuff was sort of essentially in SQL and it was all sort of locally and there was just a simple option. They don't have the budget for it. They didn't have the timeline for it either. So the simple way we did it is we just have a manual backup process that you can run and it essentially creates a zip file of this data stored as a Json or JavaScript object notation file. And so if they wanted to back up they can just sort it in iCloud and if they ever wanted to restore it they can always restore it back on their iPhone. Where I think a back-end service and a cloud service is really helpful is if you're going to have it available on multiple devices .So for instance I'm a big user of Bear, which is an awesome note taking app that's available on all Apple devices and they use kind of combination iCloud and CloudKit they store their stuff in the back end and then that way if I pull up my notes on a Mac or on my iPad or my iPhone. I always have it accessible because it's all stored in the cloud. I think that's where something like a back-end service is really useful.
[00:03:19] Erik Gillespie (Host): Like when you need to synchronize data across multiple devices
[00:03:22] Leo Dion (Host): Exactly. Yep. So I think that's really where it's really nessecary. As we get into this we'll talk about complexity of like data in any sort of like back-end stuff for notifications ,things like that, that's where we really are going to want to look at having a stuff stored in the cloud somehow
[00:03:37] Erik Gillespie (Host): gotcha. So what are some things to consider when you decide that you do need back-end storage?
[00:03:42] Leo Dion (Host): One thing to consider is timeline and budget and specifically what is the purpose of this app? Is this just a simple MVP or is it more of a long-term app that needs to be well architected when I first starts off? Because if it's an MVP, use something that you know how to use that's easy, that's simple and that's cheap and just get it done and have something that is usable and can be tested by your audience and seeing whether it works according to what you're testing as far as the app's value to the customers.
[00:04:15] Erik Gillespie (Host): Just going to ask if you could briefly explain what you mean by MVP.
[00:04:18] Leo Dion (Host): So by MVP, I mean most viable product if you're familiar with like Lean Startup methodology. So you're just proving to whether this is a product that your customers are actually going to want. And so you're just getting something quickly out there that essentially works and that you can see whether this is something customers want or you need to pivot or you need to change something or something like. Does That that make sense?
[00:04:39] Erik Gillespie (Host): Yeah, like a bare-bones version of like the basic features that you think that your customers or your users want exactly.
[00:04:46] Leo Dion (Host): Yep.
[00:04:46] Erik Gillespie (Host): Okay.
[00:04:47] Leo Dion (Host): Otherwise if you're building like an Enterprise app for a big Fortune 500 company, you probably are more likely going to want to build something a little bit more robust and customizable. That doesn't necessarily rule out some of the more cheaper options, but it's just something to consider is what do you want to work with in the long term because it's going to be used for quite a while. I think another thing to consider is when you're developing the iOS end of things and you're writing your Swift or Objective-c code to talk to this back-end make sure you have some healthy abstraction with your API communication so that way in case you pivot and use a different service at some point that that's not a big deal to what you view or what you're showing the user on the front end if that makes sense.
[00:05:27]Erik Gillespie (Host): I think so. So do you recommend doing some user-focus design and come up with the kind of data that your users need and then work your way back towards how you would need to store that in some kind of a back-end storage.
[00:05:40] Leo Dion (Host): Yeah, absolutely in an earlier episode. I believe it was episode number 6. We talked about project estimation and one of the first things I do when I have workout app is almost like a little MVP in a way is I build out the storyboard the UI of the app and essentially fake the data to make sure that that data is what the customers want and then go backwards which is exactly what you're saying. So get your UI because that's the most important thing that the users are going to see get that stuff settled and ready before you go in and build the back end in some cases. I think that's a useful rule
[00:06:16] Erik Gillespie (Host): right on.
[00:06:16] Leo Dion (Host): So another thing to consider is what devices you support. Are you only supporting Apple devices - In which case we'll talk about the more Apple centered back ends. Are you also going to support the web? Are going to support Android? Are going to support Windows and Linux desktops? Are you going to support internet of things? Because that all Is something to consider when you're looking at different backgrounds, which we'll talk about in a little bit. And then the other thing to think about is the complexity or simplicity of your queries, which is essentially when you're asked for data back or the data itself.
[00:06:50] How complex and simple is it? Because some things especially relational data is best done through some sort of SQL database when in some cases you might be better off with like a document storage type database and all the various other nosql or other types of data structures that you can do with a database so that's something also to keep in mind.
[00:07:09] Erik Gillespie (Host): Okay. And so if I'm understanding correctly some other thing ways that you could approach that is do you need to aggregate your data or you do you need to create filters and view it in a lot of different ways and combine your data set? Is that close?
[00:07:23] Leo Dion (Host): Yeah, that's exactly it.
[00:07:25] Erik Gillespie (Host): Okay, and then on the simple side, it would be I need to look up a user with this ID. I need to look up, you know the single record with this ID or something along those lines.
[00:07:33] Leo Dion (Host): Yeah, exactly. Are you willing to just kind of offload a lot of the complexity of a good query over to the device like your iPhone or is it important to have that stuff on the server and done on the server instead? That's really the question asked.
[00:07:47] Erik Gillespie (Host): Okay.
[00:07:47] Leo Dion (Host): Another thing is do you need any sort of like outside communication or outside jobs, like cron jobs essentially scheduled jobs to be run on a periodic basis. Doing backups - that's another thing we could talk about because that stuff doesn't necessarily come with a lot of the more track cloud level databases that we're going to talk about.
[00:08:09]Erik Gillespie (Host): One of the ideas there is that the user does something that creates data and then you need to be able to do something with that data whether or not they have their phone on.
[00:08:18] Leo Dion (Host): Yes, exactly. Just because you think you might need a Cron job doesn't necessarily mean you might need one. Because in a lot of cases you can just get away with like having the person when they run your app run a particular job that they haven't run in like several days.
[00:08:32] That's totally a reasonable way to get around not having access to cron jobs is just having the user do it automatically when they run the app. So that's always something to think about. That's just a way to get around the lack of the ability of having cron jobs and last but not least. I think the two other more important ones is what's your developer team comfort level like what's their expertise in that's going to matter a big deal because if their expertise is a .net shop, you probably are just better off having a Windows back end with SQL Server and C# just using like Web API and have at it. If you're already getting a decent price on your Azure instance go for it because that's what your team is an expert in. There's nothing wrong with that. So, you know it all depends. What's your team? What's your price? Because it definitely matters. Does That make sense?
[00:09:21] Erik Gillespie (Host): Yeah it does I mean let your developers the ones who are going to be supporting all of this do what they do best. Yeah, that sounds very empowering.
[00:09:28] Leo Dion (Host): Exactly. So let's talk about the different options. The first option we're going to talk about is probably the most customizable the most robust perhaps and that's just hosting your own server essentially and even that comes with different abstraction layers.
[00:09:42] So you can buy your own server and have a hosted at a site you can have a virtual machine which is what 99% of people do and get something through like AWS EC2 or Linode or DigitalOcean. I'm doing linode that's like five bucks a month super reasonable and if you listen to any other podcasts in the technical area, I'm sure you can get a really reasonable discount. They are very reasonably priced. You can go that route.
[00:10:04] If you want to go another layer of abstraction. There's something like Kubernetes. This is Google's thing, but it's open source. I believe even like AWS and Linode or DigitalOcean also host Kubernetes instances, and that's like a software layer of abstraction. I'm not an expert on kubernetes, but that sound about right Erik.
[00:10:23]Erik Gillespie (Host): I think so. I was just going to ask if you would mind explaining a little bit about what some of these are.
[00:10:28]Leo Dion (Host): I am not an expert at them, but they're just simply put it's another way to easily plug in your app into an infrastructure without the headache of setting up an entire machine essentially. People are big fans of kubernetes and for good reason, especially in the dev-op space but that's another layer of abstraction rather than just sending up a whole server essentially.
[00:10:48] There's of course Docker which is uses Kubernetes as well. And there's other container type instances that you can use. I've used Heroku as well. Heroku is fantastic. If you're just starting from scratch and want something very little to try out with I highly recommend starting off with Heroku with that.
[00:11:05] You don't even need to know kubernetes or how to setup an HTTP host or any of that stuff. That's super super easy. And that's also something to consider as well and they're not that expensive.
[00:11:14] Erik Gillespie (Host): I haven't dived into a lot of the specific platforms that you just mentioned, but I'm a little bit familiar with Heroku and I know that some of these platforms I would project don't necessarily support all of the different types of data storage solutions that you might want to host.
[00:11:30] Leo Dion (Host): Or if they do they might charge them at a premium. I mean, that's part of the problem If anything. And we'll get into that in a little bit.
[00:11:37] Erik Gillespie (Host): Research Is important and don't just pick one and then think it's going to be smooth sailing
[00:11:43] Leo Dion (Host): right like with a virtual machine. You pretty much can put whatever you want to put on it. That shouldn't be a big deal because you have a blank slate to do whatever you want with but with Kubernetes or Heroku you're going to want to look at what databases they actually support.
[00:11:56] Well, let's just get into like the different database structures you could do you could do like a traditional SQL database like MySQL or Mariadb postgres or if you're doing Microsoft, you have SQL server or if you're really, you know, you're doing some Enterprise and you're a masochist you could always do Oracle
[00:12:14]Erik Gillespie (Host): and have a lot of money.
[00:12:15] Leo Dion (Host): Yeah, exactly. So those are options if you want a more of like a SQL relational database type structure. That's what I like to go with. That's what I'm used to and despite dabbling in nosql I've always found that I almost want to go back home to SQL when it comes to database structure because that's how I think of stuff - in real a relational ways the problem with those is that. And to be more expensive but that's always an option. Heroku has a free option with postgres, which is really nice. If you're doing something small and just want to do a SQL database.
[00:12:45] Erik Gillespie (Host): Yeah, that seems like it would work with the MVP approach very very well.
[00:12:49] Leo Dion (Host): You could always do something like Mongo if you want something more loose and document-based there's redis of course and other key value type database structures as well.
[00:12:57] So those are your options when it comes to data storage as far as the database is concerned. Programming language again, what is your developer team familiar with: just stick with like PHP? That's still pretty popular; ruby's very popular; nodejs; if you're a .Net shop. There's always C sharp. You can run on that and luckily for us Swift developers. We have a plethora of options right now.
[00:13:18] There's Perfect; if you're on the Enterprise side of things and we want to stick with Swift I would recommend looking at Kitura by IBM - they're moving fast on that. If you want something more community-based than I would highly recommend Vapor which is what I've worked with and it's really awesome and easy to set up both on development when it comes to xcode or if you're setting it up on a Ubuntu I got Vapor set up on Ubuntu box over on Linode and that worked fantastic. So that's something can consider again. What is your developer team want to do? What's their toolset? What are they familiar with you're going to go find with any of those options.
[00:13:55] When it comes to running your HTTP server, you have your choice with like Apache which has been around for forever. If you're doing dotnet there's IIS, of course what's really grown in popularity in the last 10 years is nginx because it's so simple and there's a great Community out there and it's much simpler than Apache and that's always something to look at as well. Did I cover everything you can think of as far as server, database, programming language, and abstraction?
[00:14:20]Erik Gillespie (Host): I think in regards to picking a language as well. If you don't have a team then these popular ones are also ones that you can look out for if you're looking for Freelancers to do some one-time development for you.
[00:14:32] Leo Dion (Host): Yes, and if you're looking for a Swift developer who's worked with Vapor contact me
[00:14:37] Erik Gillespie (Host): nice
[00:14:38] Leo Dion (Host): because I've worked with vapor and it's a really fun framework to work with if you're already a Swift developer.
[00:14:43] We've talked about the main stuff you need but then you're going to need some sort of monitoring security and backups and things like that and that's also something to consider. What I set up to get the app working on Ubuntu for Vapors is I used supervisor which essentially runs the app so that way it can be tunnelled through nginx through the main server and supervisor is really good.
[00:15:04] If you're looking for security or a CDN or things like that, you definitely want to look at cloudflare. They're pretty reasonable for what you can get for free from them. I would highly recommend checking them out. I don't know if New Relic is specifically PHP related but New Relic is really good for monitoring when it comes to your app.
[00:15:21]Erik Gillespie (Host): I recommend actually testing all of these out. So whichever one you decide actually try it out and make sure that for any kind of security or monitoring that you're able to not just read and understand how to use these tools. You can use them and that they work the way that you think and if you're doing like database restores and recovery and security that you're testing those really well. This is an area of your infrastructure that needs to be pretty rock solid or your entire application will just go down and be unavailable
[00:15:50] Leo Dion (Host): That's a really good point Erik. So some of the advantages of hosting your own is the fact that you can customize everything down to the minutiae, I mean you basically have a whole machine that you can work with that is also the disadvantage because the burden is on you to make sure everything is set up correctly wear as a lot of these other services. They pretty much can take care of everything. All you need to do is write your app code and get your database setup. So that's something to think about. I think the good time to host your own is if you're building Enterprise or long-term application. If you're using something outside of the Apple domain, I think it's something I consider is just hosting your own server or having your own web app.
[00:16:29] And then if you're doing any sort of complex queries or complex data, definitely you want to take a look at setting up your own SQL database. And if you absolutely need backups or cron jobs or things like that you definitely want to take a look at hosting your own.
[00:16:43] I would not recommend hosting your own if you need a simple MVP or if you're doing this only on Apple devices or your data is fairly simple. Of course, this is all pertains to what's your price range? What's your developer team Comfort level and things like. That but those are things to consider.
[00:16:57] Erik Gillespie (Host): It sounds like basically if you have simple needs go with the simplest solution and then plan on scaling out from there according to the growth of your own needs.
[00:17:06] Leo Dion (Host): Exactly. And let's be quite honest with ourselves here quite often people are rewriting web apps all the time. So especially in software nothing's written in stone.
[00:17:16] So I would definitely think long term but not too long term because in the very long term the stuff is going to be re-written quite frankly keep that in mind as well. I don't know how I put that but so it makes sense Erik. Let's talk cloudkit now, which is Apple's more or less back-end storage. CloudKit is essentially like an abstraction layer of object storage cloud based object data storage.
[00:17:41] It's a fairly simple to use if you're sticking with iOS it comes with push notifications so you have the ability to do that. It's completely native to Apple. So if you're running a Mac app or an iPad app or using an Apple Watch or Apple TV, it's really easy to do. It also includes a JavaScript component for the web.
[00:17:59] So you have that ability. If you're doing something web-based. However, there are some disadvantages. Right now, It's probably pretty difficult to use for Android. I say that because there is no like. It is Android use, you know, it's interesting. We talked in the previous episode about Apple's growth in the services space.
[00:18:17] It'll be interesting to see if they make any moves towards Android with CloudKit June with WWDC because you know if they're putting an iTunes on a Samsung TV, or they're putting Apple music on an echo you'd think they wouldn't mind putting cloudkit on Android, but we'll see about that. I think there's probably ways to get around that with Android.
[00:18:34] I'm not an Android developer, but I would think there's ways you can call the JavaScript API using Android or at the very least you could like say running ionic or Cordova app and just use JavaScript in that sense using cloudkit. And you know going to the desktop maybe if you're running an electron app, for instance, you might be able to just use cloudkitJS with that so that option is available but like I said there might be an uphill battle.
[00:18:59] Erik Gillespie (Host): Do you happen to know if the JavaScript API can be used from node? Or is it only from the browser?
[00:19:06] Leo Dion (Host): I don't know that that goes to the next point is like would you be able to like write an app on a Raspberry Pi using cloudkit JS? Like I have no clue about that. That's a really good question and somebody out there knows that right us back. We'd love to hear.
[00:19:18] Where it is an easy yes is if you're just going to target only Apple devices. Then I would say cloudkit is definitely what you want to go with and then if you don't need a lot of outside jobs, like I said, you probably could figure out how to write your app so that way you don't really need a crown job, or maybe you do automatic backups in the app itself. These are seriously powerful iPhones so really I wouldn't worry too much about straightening a user's iPhone when they have so much power, especially with these like newer iPhones. I think you're totally fine offloading some of the stuff onto the iPhone itself if your data is not too complex or your data or your queries aren't too complex when I wouldn't suggest using it is if you're not doing Apple only I have some hesitation about just depending on cloudkit JS for everything if you're not targeting only Apple devices. And if you absolutely absolutely need outside backups or outside cron jobs of some sort to be run and you're absolutely cannot do it on an iPhone or an iPad then you might want to consider not going with the cloudkit option if you're targeting especially slower devices or you really need to offload a lot of these queries or data is just way too complex to sort and cloudkit then you might want to not consider cloudkit in that case.
[00:20:50] Maybe we'll do a little history lesson. So I would say about five years ago six years ago the most popular one out there by far when it came to mobile backends was Parse. Parse then got bought out by Facebook and then Facebook essentially killed it. Now, they open sourced it so anybody could run their own Parse server, but out of the ashes of that came another startup called Firebase. And I don't know how many years it's been but a Firebase essentially got acquired by Google.
[00:21:20] And as far as what I've seen it's the most popular mobile backend as a service and actually backend as a service over all because of price probably but also that it's available on a plethora of devices. Erik, you've actually used Firebase, correct?
[00:21:36] Erik Gillespie (Host): I have and yeah on the surface, it seemed really really appealing and I've got to say right now I would be hesitant to use it in to any of my applications that might scale
[00:21:49] Leo Dion (Host): so could.explain a little bit about how Firebase works?
[00:21:52] Erik Gillespie (Host): You can think of it as a nosql database that stores everything that effectively as one giant JSON object; every single user if you have user records, if you have a Blog every single post, it's all going to be in one giant JSON structure and they have a very basic querying language that you can use to access data within that JSON structure, but it's not very robust and it's got a little bit better, but I think this typically ends up happening with a lot of NoSQL databases if you want complex querying capabilities typically you end up duplicating a lot of your data to make it a little bit easier so.
[00:22:26] Leo Dion (Host): Did you run into a lot of like map-reduce issues with Firebase? That's what I've run into when it comes to Mongo is like you end up having a lot of map-reduce and like that stuff can get really complicated really quick.
[00:22:39] Erik Gillespie (Host): Yep. So there's a lot of different ways that I needed to use this data that took a lot of consideration and to how to secure the data how to. So data how to do things efficiently and then also like you were suggesting how to actually manipulate all of the data once I do have it so that I can report it to the user in the correct way.
[00:22:59] Leo Dion (Host): Does Firebase allow you to offload a lot of that complex querying over to their servers you can pick they do have functions. So you can do things on the Firebase server as you would or you can run your own server. And so you can query the Firebase database manipulate the data on your own server and then send that to the users or.
[00:23:19] Erik Gillespie (Host): You can even access everything directly from the browser or your IOS app and then manipulate the data directly on the client device. The tough thing is Firebase does make it really easy to get started with a database and do some really cool real-time interactions with basic data sets. And so there is a strong appeal and I can understand why there's this popularity to it and it's really good as an introductory database.
[00:23:44] If you want to learn how to do real-time database integration in a web browser and you don't want to have to introduce like rest apis or making graphql or any other typical ways where you have to just create a bunch of extra code, In order to get access to data. Firebase is a great way to go about it.
[00:24:01] However from my experience if you're doing anything more than basic it gets really complicated really quick. So very early in this episode you mentioned the security is one of the concerns. If you have clients accessing the database directly and you don't have any server in the middle there. Then you have to start writing all of these different rules in Firebase in order to make sure that user X cannot access data that is exclusive to user Y that's really complicated and it's kind of like JavaScript but it's not quite JavaScript. So there's all these nuances that you have to learn about how to use it.
[00:24:34] Testing is also really challenging. So the way that you watch data is you watch it query URL. So you provide a path, to an object or a structure within your Json that you want to watch and anytime there's changes to that fire base will automatically stream that data to any of the affected clients. So you have to be concerned about the size of the data. So if you have let's say you have a user profile that has your username and an avatar and a bio you have to be mindful that if you want to just present in the navigation bar on any given page the name of a user that you only want to query for the name of the user otherwise you might be incurring a lot of extra downloads if the bio or that image change. So there's some performance impacts if you don't model and code your Firebase application correctly.
[00:25:22] Leo Dion (Host): So this sounds a lot like subscriptions and cloudkit. So in cloudkit you can do something like a subscription and listen to changes in the database for a particular user. Is it some similar to that and then you get like a push notification with subscriptions essentially?
[00:25:37] Erik Gillespie (Host): Yeah exactly the Firebase realtime database doesn't use browser or client push notifications. So you don't have to do the like I allow this application or this website to push notifications to me.
[00:25:54] Leo Dion (Host): Right
[00:25:54] Erik Gillespie (Host): and it does that really well. So the data syncing does work marvelously. However, sometimes it can take a long time to sync data if you're watching an entire user record and they change their profile. Meanwhile, all of your users who are in a chat room who only care about the username then may have to download this profile that is maybe like one kilobyte and until that is donethey don't actually see any changes to like a username or anything like that.
[00:26:28] Leo Dion (Host): Yeah. That's a really good point.
[00:26:29] Erik Gillespie (Host): Yeah, so you have to be very careful about those subscriptions or what you're listening to.
[00:26:34] Leo Dion (Host): Now cloudkit has the idea of like a private database, public database and a shared database you have somebody like that like CloudKit? Or is it all just kind of like a database which is kind of the more traditional way of doing things?
[00:26:46]Erik Gillespie (Host): Firebase has a few different storage options might be able to guess this since they store in the real-time database everything as JSON you have all of the same limitations of what you're able to store so binary data is automatically out.
[00:27:00] So if you need to store files PDFs or images or anything like that, That will go into a different Firebase service. So you have to then code to separate ways to potentially get access to the data that you need which can have its benefits. However, it can also seem a little cumbersome. The last point is the querying capabilities.
[00:27:19] They've gotten better. However, there's still really basic and definitely not as powerful as what you can do with like an SQL database. I would say if you have any kinds of reporting needs or you need to aggregate lots of data and then present it to the user in. One, two, three, or more different ways than you may need to take that into consideration when you're modeling your data and potentially create duplications of your data, or maybe just reconsider using Firebase for that kind of reporting need.
[00:27:50] Leo Dion (Host): Okay, that makes total sense.
[00:27:52] Erik Gillespie (Host): It does seem really really popular but the more I dig into it like there are some companies using it but not a whole lot of like enterprise-grade companies that are really relying on Firebase. So that is something to consider as well. And I would recommend considering that not just for Firebase.
[00:28:09] But any kind of storage solution that you're going to use see if there are any big companies is using it if you want something that's rock solid and stable and gets a lot of support you can. Be sure that these big companies who have lots of lots of time and money to spend will have taken the time to research and vet these solutions and so you can offload some of the work on to them and consider it a little bit safer to go with a solution If you have like one of these Fortune 500 companies using it.
[00:28:37]Leo Dion (Host): What do you think of Fortune 500 company is using for their back-end?
[00:28:41]Erik Gillespie (Host): I've seen a lot of them end up hosting their own.
[00:28:44] Leo Dion (Host): Yes.
[00:28:44] Erik Gillespie (Host): I am seeing them shift more towards cloud based Solutions but what they tend to do is do a lot of self manage types of solutions.
[00:28:51] Leo Dion (Host): Yep.
[00:28:52] Erik Gillespie (Host): Not necessarily like a Heroku but maybe like AWS or there's other what are considered enterprise-grade.
[00:28:58] Leo Dion (Host): When it comes to your Fortune 500, If they're going to go Cloud, they usually go AWS, Azure, IBM - typically those are those are the big three Cloud platforms that I've heard of maybe maybe Google if they've been given enough incentives to do that as well.
[00:29:13] I don't see a lot of Firebase. Now, I've also seen the case where. You might use multiple database systems. So maybe you have like MySQL for some of your data. And then maybe you'll have like a real time data using Firebase. Is that a use case you've seen a lot of?
[00:29:27] Erik Gillespie (Host): I haven't seen a lot of it, but it was it is something that I would consider. I think graphql makes that a little bit easier because you can aggregate data from a lot of different sources more easily with a rest API you basically have to do all the coding yourself. So if you want to use Firebase and postgres, for example, then you create an API and then your apis server-side code will connect to both of those places pull down the data they need and then manipulate it however and then spit it back out to you so definitely very viable something to consider.
[00:29:57] Leo Dion (Host): Could you explain a little bit what graphql is as opposed to rest API
[00:30:01] Erik Gillespie (Host): With a rest API, typically you have a URL or resource on the web and you will fetch that and download one piece of data with graphql from the client you can provide a multitude of data that you want to access and then a graphql will take on the responsibility of figuring out how to quickly get and combine all of that data and then get it to you.
[00:30:31] Leo Dion (Host): Yeah, I think Rest API kind of is a very simple as far as what you can query. It's meant to be like that. It's always been structured in that way.
[00:30:39] So you can say I want to get user with ID 20 and I'll just do it and then maybe you can maybe attach some filters and things but it's really it's very simple as far as that where I think like with graphql which is by Facebook. They've done is they've created a weight so that the client can send a complex query essentially in some sort of JavaScript object notation format.
[00:31:01] And then the server has the responsibility of figuring out how that query is to be run and how that query data is supposed to be outputted to the user. Is that correct?
[00:31:11] Erik Gillespie (Host): Yeah for my understanding. Yeah and it introduces some alternative concerns with rest. You have a single resource that you're trying to fetch so it's pretty easy to lock down data. With graphql, then you have to consider now a user is potentially queering for anything that they want because you're exposing this query API to potentially anyone.
[00:31:31] Leo Dion (Host): Yes.
[00:31:31] Erik Gillespie (Host): So how do you protect all of this data? How do you make sure that they don't come up with a query that is going to just totally bog down your server or get access to data that they're not supposed to have access to. How do you actually present errors when they occur?
[00:31:45]Leo Dion (Host): Anything else you want to talk about as far as Firebase is concerned?
[00:31:47]Erik Gillespie (Host): I would recommend using it for very very simple situations where you have data that is not going to change in structure over time, data that's generally flat and when you don't have to do lots of complex queries. So on the flip side of that if you have lots of relational data you have to do a lot of reporting you have lots of large Fields like files to download that might be text-based so you'd be inclined store them in Jason or you have very complex security needs then you might want to consider some alternatives to Firebase.
[00:32:19] Leo Dion (Host): Yeah, because I feel like Firebase is the most popular it's the hotness and from what you've told me with your story is like it's not necessarily a good fit for most things. Is that correct?
[00:32:31] Erik Gillespie (Host): I think most people when they're building applications have grand ideas of them scaling to lots of people being used for very big things Firebase is very appealing for small projects. However, from what I've seen they get really complicated really quick. So as your needs change firebase might not be able to adapt and grow with you and can be very difficult to continue to support.
[00:32:55] Leo Dion (Host): I think it's a really good point Erik. So always consider your developer team your price when you're doing your backend and help simple. Can you make your data? How much can you get away without a lot of the complexity of a home-built server?
[00:33:07] Because the backend they're great. If you don't mind dealing with the hosting and all their headache and also even if you do a custom back-end consider how much of that can be abstract and you're willing to get away without having to maintain a server all on your own. If you're doing anything in the Apple space and you already have a team of Swift developers I would recommend looking at vapor at the very least for your back end. But if your team is mostly .net Developers or mostly Ruby developers or PHP or Elixir or go or rust or whatever one of the plethora of languages out there consider the comfort of your developer team. If you're just doing mostly Apple apps so stuff for the Mac iPad iPhone TV watch whatever consider cloudkit. With Cloudkit, you can get away with a lot. It's very very cheap. Apple practically gives it away for free. You're hardly ever going to run into the limit and it's really easy to use when you're working with Apple devices and you're already programming in Swift or Objective-c.
[00:34:00] And then as far as Firebase, it's great if you're doing really simple data or you're working with a really simple MVP but really look at the limitations before you jump into it. It might not be a good fit for what you're looking for. And you know, if you need to pivot do it early it. Don't do it when it's too late, if you feel like your data isn't a good fit for whatever you end up picking pivot as quickly as you can because you're not going to want to be burnt out by constantly trying to get your data to fit and in particular space.
[00:34:28] Erik Gillespie (Host): Yeah. Yeah. I totally agree with that
[00:34:30] Leo Dion (Host): cool. So yeah. Thank you so much for coming on again and telling your story about Firebase and we will talk to you later.
[00:34:37] Erik Gillespie (Host): Alright take it easy. Thanks for having me.
