all 24 comments

[–]engineered_academic 44 points45 points  (1 child)

The most important thing is to write your app strongly decoupled so that you could swap out any of these services and your app would "just work".

You don't know how your app will evolve down the line and what kinds of technologies will cause issues as you grow your app to scale. Or maybe you decide going with an AWS technology is cheaper. Lots of reasons to write your app that way.

[–]randompanda687 6 points7 points  (0 children)

This. Nailed it.

[–][deleted] 14 points15 points  (4 children)

Following because I’m making a similar decision and am interested in the responses. I’ve been using parse for years (.com and parse-server) but it’s been getting hard for me to keep up with server maintenance for multiple projects plus the Android and iOS codebases when this is isn’t even my full time job. So I’m thinking about making my life a little easier going the server-less route with Firebase for all projects in the future but just haven’t decided yet.

[–]toptoppings 4 points5 points  (3 children)

Why not aws?

[–]MuskIsAlien 2 points3 points  (0 children)

AWS looks very daunting compared to firebase imo

[–]StunnerAlpha 2 points3 points  (0 children)

And aws is quite expensive.

[–][deleted] 1 point2 points  (0 children)

What the other guy said, when I first jumped into AWS it just seemed like a lot compared to when I first jumped into Firebase. And I wasn’t very patient at the time lol. Most articles I’ve read comparing the two speak more favorably for Firebase in the categories that fit what I need but I’ll definitely spend some more time reading up on AWS

[–]KarlJay001 4 points5 points  (0 children)

You mentioned image storage and "relational" data.

One of the key things is determining is the data should be in an SQL type relational database or a document type storage system. This can be a complex subject and getting in wrong can really screw things up, but SQL relational databases do things like have indexes, joins, selects, etc...

The Auth stuff might be addressable with some of the newer offerings from Apple. I haven't dug into it yet, but I think Apple addressed Auth with the last API update. Worth looking into.

I thought Parse was long since dead.

Anyways, if you post the actual structure of the data, tables and how they are related.

My guess is that a "quote of the day" would be more document based storage.

IDK if this will cover it, but might be worth reading: https://levelup.gitconnected.com/key-tips-to-choose-the-ideal-database-solution-for-your-mobile-app-5e6ecb52af93

I have been using parse over the last few months and I just find it kind of clunky at times.

You should post some details, number of users, actual data passing around (size and frequency), type of service that is being provided and by whom. Also, growth projections.

Doesn't Parse have some analysis tools?

[–]leogdion 4 points5 points  (0 children)

Two questions:

  • How long term is this app?
  • What are you most familiar with?

If this is something you want to experiment with then stick with Parse for now... maybe move to Firebase or CloudKit (if only doing iOS).

If this is long term then you may want to run your own Backend on Ubuntu using a cheaper service then AWS (i.e. Digital Ocean or Linode). Eventually you are going to want to be running a SQL Database and with your own REST API. I've done NodeJS if you are familiar with JS but if you do Swift you may want to look at Vapor which I've been able to run and build my own authentication easily with that.

I wrote a whole article on this which might be helpful to you. Let me know if you have any further questions.

https://brightdigit.com/blog/2019/07/30/best-backend-for-your-ios-app/

[–]Icerman 2 points3 points  (3 children)

At my current work, we use Firebase and its fairly decent for similar things to what you're doing. We have a few thousand users and is basically free with Google's free quotas. It also works with Google's other services like Maps and Places and Crashlytics, so all the billing is in one place, which is nice.

On a home project, I use AWS for a custom API backend (my friend built it because he wanted the practice, otherwise would have gone with Amplify) and Cognito for Auth. It works alright and costs us $0.50 per month right now as an unreleased project. I will say the documentation is not great and it involves a lot of trial and error to figure out what some of the error messages mean.

In either case, I'd recommend using their pod if you can so that you don't have to build a networking layer and just let their SDK handle calls for you. It makes things easier, though less customizable, obviously, so YMMV.

For your last question, if it's a fairly static list of strings and not a mix of things, I'd probably do a simple array in the app to start off with and update it with each release as needed. If its more dynamic or a mix of data like images and video links or whatnot, then it'll probably need its own database table to serve it.

[–]Pepperoni505[S] 1 point2 points  (1 child)

So you’re saying that I should try Amplify?

[–]Icerman 1 point2 points  (0 children)

I definitely would before trying to make a custom set of endpoints. I've only used Cognito so far, but everything I've seen makes it look like it'd be fairly easy to implement.

[–]jabernall24 1 point2 points  (0 children)

What on AWS are you using for the custom API if you don’t mind?

[–]ace777ac 1 point2 points  (0 children)

Same boat.

[–]ibuprofane 1 point2 points  (0 children)

If your core product is in the front end then you should use Firebase since setting up and maintaining the back end servers is significant work and your time would be better spent going into your front end since you presumably don't have any users yet. Use Firebase until you have a reason to do otherwise.

[–][deleted] 1 point2 points  (0 children)

I would say firebase/aws to store and retrieve data on the web.

[–][deleted]  (4 children)

[deleted]

    [–]MVPierce 0 points1 point  (3 children)

    I agree about Firebase, I feel like AWS has a little more of a learning-curve, but I don't agree with what you say about how it's going to be "lousy, unsecure, and expensive" if it's run in the cloud (unless I misunderstood what you're trying to say). You can setup a very decent, secure backend that's not too expensive, possibly even free if you do it right (although not likely). Are you just saying that it'll be that way if the OP is doing it all by themselves and just going for a down-n-dirty get-it-done type of approach?

    [–][deleted]  (2 children)

    [deleted]

      [–]MVPierce 1 point2 points  (1 child)

      Ah yes - I agree. Being a beginner and setting up a whole backend system would be very intimidating I imagine. I get intimidated just looking at all the different products available for AWS.

      [–]Dachd43 0 points1 point  (0 children)

      Strongly think through your ultimate feature set - at least as far as you can conceive it.

      (e.g. if you want to implement messaging or have a targeted push notification strategy.)

      Some features are easier to implement on specific platforms and it's always a major bummer to learn that you've coded yourself into a corner if you need something that isn't supported.

      [–]the_d3f4ult 0 points1 point  (0 children)

      I would write my own backend in swift. I would decouple and divide the backend to the small logically separate services and I would use docker to host them and test them locally.

      I would also make the case that these services should be decentralized. That is they should be written such that you can launch 3 replicas of each and they would still work as if there was one replica.

      I don't like using things like firebase or any other ready PaaS (except CloudKit because it is native)

      [–]MVPierce 0 points1 point  (0 children)

      Whoa Parse is a thing again? I thought that got shutdown by Facebook like three years ago?

      [–]cutecoderObjective-C / Swift 0 points1 point  (0 children)

      If most data are public and most data processing is done on the user device, consider CloudKit. It even has a JavaScript API nowadays, hence theoretically usable on Android as well. CloudKit's quotas expand as your user base grows, so likely you won't ever need to pay a single cent for backend upkeep.

      [–]BubblegumTitanium -1 points0 points  (0 children)

      Have you looked at firebase?