0

As a preface: I want to do this as a learning exercise. I'm not trying to produce a commercially viable app.

What are the layers/abstractions of an iOS application that is connected to a custom, self hosted backend? What technologies are needed to build this stack?

This post has helped my understanding a bit. I'm currently using Firebase as my backend but have found its NoSQL structure wrong for my app. The data I'm storing is relational, so I think an SQL database storing JSON would work better. The data is modeling Vehicles shared between Users. From my research, the Realm Platform looks like a good choice. Am I understanding the technologies correctly here? Does this sentence make sense?

General functionality:

  • Sign Up and Login of users
  • Upload/download vehicle data
  • Some server side logic
  • Pushing data updates to users in real time

So would the stack look like the following?

User Front End: iOS app written in Swift
Database: Realm Database (SQL)
Server: Realm Object Server

I'm really looking for an overview of the general architecture. I don't know anything about that, so I'm sure I have failed to provide many details that are necessary for a thorough answer.

I apologize if this question is redundant; most answers I've seen for similar questions typically end with "just use AWS, Firebase, etc".

Thanks!

Nick Rizzo
  • 15
  • 5
  • Can also try your hand at Python's Flask for backend and use whatever database you want.. although it does come with SQLAlchemy.. – Brandon Mar 22 '19 at 15:02
  • Interesting i'll check it out! Thank you – Nick Rizzo Mar 22 '19 at 15:20
  • There is a good and accepted answer but the question is a bit vague. The requirements could be handled by Firebase (which can handle relationships) or Realm's ROS. If you are rolling your own physical server, you need to take into account items such as maintenance, downtime, redundancy not to mention having the right hardware to support X users as well as connectivity, security etc. It can be a very expensive proposition as the weight of everything rests solely on you e.g. instead of spending time coding and upgrading your app, you have to spend the afternoon replacing a failing hard drive. – Jay Mar 22 '19 at 16:01
  • I apologize for the vagueness; it's the result of my ignorance on the subject. :) I'm more interested in developing my understanding the tech stack than the efficiency of doing it all myself as opposed to using pre-existing solutions like Firebase. Though I'm using Firestore (relatively new Firebase db) and I'm finiding it to be a complete mismatch for my purposes. From my understanding, Firebase is a NoSQL database which is good for "unstructured, non-relational" data management. My data is structured, non-dynamic, and relational. Dev time thus far has been slow because of this mismatch. – Nick Rizzo Mar 22 '19 at 16:16
  • Ah... Coming from a strong SQL background, I initially thought Firebase was a mismatch as well; I was totally wrong. There is the saying to use right tool for the job but understanding the tool gave me a different perspective. Initially, creating 'relationships' in NoSQL seemed like a total mismatch... however, once you understand how to approach data in a NoSQL way it gives you another tool in your toolbox; Firebase/FireStore is blisteringly fast and very expandable - I would suggest continuing with it. If you have a specific use case issue, be sure to post it here so we can take a look. – Jay Mar 23 '19 at 13:55
  • @Jay That makes sense! It sounds like I'm underutilizing Firebase. So would it be fair to say that Firestore allows for SQL-like data structuring if you want while also supporting NoSQL? In which case I might not be approaching this correctly. I'll follow up in my original post with the data models/requirements of the app. – Nick Rizzo Mar 23 '19 at 16:44
  • It allows for relationships when the object graph is created by you as opposed to created by it. Provide a simple and specific example of a relationship you need, what's you've tried (code) and your current structure. There will be a solution but it will be approached from a NoSQL kind of way. – Jay Mar 23 '19 at 18:42

1 Answers1

1

For a start you want to build your own backend and you should create your own API's that your IOS application will connect to. in short this is called REST api https://www.sitepoint.com/developers-rest-api/

you will need to use many more technologies more than just a server like Apache

once you create your backend API you will need to connect it to the IOS app which can be done using NSURLSession builtin framework form Apple or Alamofire which is based on NSURLSession but its easer to use if you are learning

you will need to learn how to do an http/https request to understand how the request is made

check this https://medium.com/@MuraliKathir/build-a-simple-api-search-with-alamofire-and-swiftyjson-80286e833315

Now to Realm. Realm is a local database that will be inside of your IOS app which helps you save data downloaded online or even user generated https://realm.io/docs/swift/latest/#queries

Marchal
  • 286
  • 2
  • 16
  • Thanks for the quick response and the links! In terms of Realm (or any other DB), would I have 2 Realm databases, one on the server and then a local one on the iPhone? The server would have all of the data for everyone on the app while the local DB would have only data relevant and accessible to that specific user? Furthermore, I'm assuming that the server and the local databases don't both have to be Realm? – Nick Rizzo Mar 22 '19 at 15:18
  • @NickRizzo yes they dont have to be the same as you said the server side can have mysql or any database and on the app you can bind the data and save it wherever you like. Realm can be used on server-side on both Linux and Windows via NodeJS and the Realm-JS API – Marchal Mar 22 '19 at 15:26
  • Thanks so much! This is filling in a lot of the blanks for me. – Nick Rizzo Mar 22 '19 at 15:37