Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
iOS Cloudkit, Parse, RESTKit, json, your own server
- Thread starter grandM
- Start date
- Sort by reaction score
I like to use Node.js. It's based on JavaScript so it's really super easy to learn. And it's completely free. And most the major database technologies out there have a library for Node.js so you can use it with whatever you want. You can use Node.js with MongoDB (my personal favorite), MySQL, PostgreSQL, etc. etc. etc.
Basically EVERYTHING has a Node.js module. For example, one of my clients wanted the backend I am building for them to be able to send out SMS messages. Super easy, just used a Twilio Node.js module and it only took a few lines of code.
If you happen to have a fast enough internet connection, you can run it completely for free off of your own computer to serve iOS users. The main reason I use AWS EC2 to run my node instances isn't because of speed. My computer could run laps around Amazon's first few options, and I've got gigabit fiber. It's mainly because of the security of the AWS platform.
Basically EVERYTHING has a Node.js module. For example, one of my clients wanted the backend I am building for them to be able to send out SMS messages. Super easy, just used a Twilio Node.js module and it only took a few lines of code.
If you happen to have a fast enough internet connection, you can run it completely for free off of your own computer to serve iOS users. The main reason I use AWS EC2 to run my node instances isn't because of speed. My computer could run laps around Amazon's first few options, and I've got gigabit fiber. It's mainly because of the security of the AWS platform.
Security is of course enormously important. Are you suggesting one better should not try setting up its own server? If so, why did you prefer Amazon above Parse? For now you probably saved your data in Core Data. After this you had to translate that data into your amazon database using your own API. Or am I mistaken?
I try to deal with Core Data as little as I possibly can. I try to have a very specific way of storing data. It's either almost entirely saved on the server, or it's almost entirely saved on the app. I almost never try to do both because it gets very complicated very fast.
Sometimes you can't avoid it, and in those cases, there are some basic techniques to synchronize two databases that you can read about online.
About security, there are a lot of things one needs to consider when setting up their own server. With AWS or Parse, most of this is taken care of for you. Of course, your actual Node.js server needs to have some basic security techniques (ie. TLS encryption, temporary access keys passed in with every request or cookies or something like that, hashing data when appropriate instead of saving the real thing like with passwords, etc). A lot of this stuff really is just common sense when you think about it. With Parse you almost don't have to worry about it at all. With AWS you need to design your server securely. And with your own server you need to work with firewalls and things like that.
The reason I like making my own server is flexibility. For example, let's say I want to make the following request: "send any users within 10 miles this message". If you weren't using Parse's Cloud Code (which is so similar to Node.js that you might as well learn Node.js), then you would have to do it the dumb way. You'd first have to query your Parse database to get a list of all users within 10 miles. Then you would have to upload the message to the server addressed to only those users.
But with Node.js (or any other server you can run arbitrary code on), for this same request, you can create a REST endpoint extraordinarily easily that will basically take several parameters, such as "distance" for the number of miles to find users within, "message" which is the message you want to be sent to those users. So instead of two separate requests, you only need to hit up one single REST endpoint and the server will do most of the work intelligently. It's also a lot faster since it's VERY fast for the server to query its database and do some work with that data.
So overall, the more you can do in the 'cloud', the better (usually).
Sometimes you can't avoid it, and in those cases, there are some basic techniques to synchronize two databases that you can read about online.
About security, there are a lot of things one needs to consider when setting up their own server. With AWS or Parse, most of this is taken care of for you. Of course, your actual Node.js server needs to have some basic security techniques (ie. TLS encryption, temporary access keys passed in with every request or cookies or something like that, hashing data when appropriate instead of saving the real thing like with passwords, etc). A lot of this stuff really is just common sense when you think about it. With Parse you almost don't have to worry about it at all. With AWS you need to design your server securely. And with your own server you need to work with firewalls and things like that.
The reason I like making my own server is flexibility. For example, let's say I want to make the following request: "send any users within 10 miles this message". If you weren't using Parse's Cloud Code (which is so similar to Node.js that you might as well learn Node.js), then you would have to do it the dumb way. You'd first have to query your Parse database to get a list of all users within 10 miles. Then you would have to upload the message to the server addressed to only those users.
But with Node.js (or any other server you can run arbitrary code on), for this same request, you can create a REST endpoint extraordinarily easily that will basically take several parameters, such as "distance" for the number of miles to find users within, "message" which is the message you want to be sent to those users. So instead of two separate requests, you only need to hit up one single REST endpoint and the server will do most of the work intelligently. It's also a lot faster since it's VERY fast for the server to query its database and do some work with that data.
So overall, the more you can do in the 'cloud', the better (usually).