I want to develop a native application to ios.
I want to build an app that is a mix of Instagram and YouTube,generally.
I need to persist and get data to and from the database,store user data(images,videos,audio etc.), Allow user to edit his uploaded media ( images,videos,audio etc.).Also things such as drag and drop, GPS and image edition are added.
So far I think these are the most demanding features that app will contain.
I think about using swift for the front end, but I am still considering what language and database to go with to develop this application.
I though I should maybe go with php laravel framework RESTful api(since I know it already), combined with firebase.
Any better suggestion you might think about, and why?
Will appreciate your honest thoughts about this.
I was really putting the last hours in order to determine the right language for developing the back-end and the database. And I reckon that really node.js and mongoDB , along with Swift will make the perfect match!
node.js seems to be good for my app, as it does not really require very complex computing, and MongoDB is ideal for social networking features. These are the main reasons I am going with this stack :)
Also,about scalability, it's easier in MongoDB,rather than MySQL.
Related
I'm fairly new to app development, and have no apps in the app store. However, the app that I have been working on is really progressing along.
The backend database that I have been using is Firebase, because it is so user friendly, easy to use, and easy to roll out an MVP. However, in the last couple of days I've really started hitting barriers with Firebase and how limited its querying functionality is, and how the code will become a "spaghetti" mess after a while. I'm looking for advice from some experienced programmers/developers.
Is Firebase viable for an app that depends heavily on searching? Can I couple Firebase with another service like Algolia and ElasticSearch to fix this problem? I'm concerned that if I press forward with Firebase and I eventually need to swap over to my own database that it will be pretty much impossible if I had 100,000 users. Especially factoring in the cost of such services after the app scales.
Or should I start my own backend (even though I have no experience with this at all) and move forward from there? I can learn, and don't have a problem putting forth effort in this area, but its a whole new journey for me. If this is the absolute right thing to do in order for me to have the ability to turn my app into a success story like your Uber's and AirBNB's, then I want to start out in this area and not get screwed on a transition from Firebase.
In summary, my question: If you were to start a company that could be the next Uber, where would you start your MVP? Firebase w/Elastic Search, your own custom backend, MongoDB, node.js, etc?
Thanks so much for the help and insight in advance!
I am an novice programmer and I need a little direction.
Here is the concept of what I am looking to do:
Let's say I have an iOS and or OS X app for let's say storing people's names and phone numbers. Now I want to be able to have multiple people to be able to use the same app on different devices and access the same database; read and write values at the same time.
I am moderately well versed with Core Data and I have found that it works well but is not capable of accomplishing what I am trying to do.
Could someone point me in the right direction to find resources where I could learn how to do this? Thanks.
I apologize if the question has been asked before; I tried to do searches but I didn't know exactly what to search/could not find what I was looking for.
It seems that what you want to achieve will require an external database storage, which would provide an API that both your iOS and Mac OS apps will use in order to read/write to this common database.
There are plenty of resources on how to setup a database and an API. A pretty simple (yet heavy) approach would be to create a little web server in the language of your choice (PHP, Ruby on Rails, Node...) that exposes a hosted database, and communicate with that API from your apps. My advice if you are a beginner, would be to have a look at RoR to setup a simple web server/Restful API that exposes a MySQL database: http://guides.rubyonrails.org/getting_started.html.
If this is not the answer you're looking for, maybe you want to use iCloud in order to keep your data in sync between devices. However, this is not applicable in a multi-user land (e.g. this will work fine for multiple devices of the same user).
I'm new to web in general and django (python web framework) as well.
I find python easier to work with but most of my colleagues prefer java.(play framework)
Would it be possible to mix them in a web application?
Would it be easier if I just dump django and start using play?
Someone in Integrating Django and Rails mentioned 'messaging', and I wonder what he meant by that.
It's definitely better idea to jump into the Play (or django) then mixing both solutions. Reason is one, fundamental. Although it is possible to mix one framework with other, or even mix frameworks from many languages, first... you need to know all elements at least very well. Then you can search for most optimal ways for connecting them and use the best parts from each, to get best possible result.
As de facto Play's and djangos approaches are very similar I see no good reason for trying connecting them, especially, when bigger part of the team uses one solution, the best option is to follow them.
While, as you wrote - you're new to the django as well, that switch should not be a problem. You can just in future write similar project in django and compare productivity, performance etc. Maybe then you'll convince your colleagues for trying something else.
BTW: Messaging between two apps should be done with documented API's, just consider each other as a 'foreign' service. You can share database, but make sure that frameworks don't duplicate functionalities.
In other words - if you'll write a ContenteManager in django, make sure, that Play guys connect to the DB as a client, or vice versa, don't try to mix responsibility between two solutions (even if written in the same language/framework) cause you'll fail.
I think messaging between two separate frameworks is possible by a number of ways :
intensive exchanging data-files (we're back to DOS days...)
sharing the same database (not described in books , but I've seen it )
communicating trough key-value store as a common data-source
All those solutions are the same if you put diesel fuel in your Ferrari .
Anyway , if you step on a framework you don't like , probably it has some kind of database , that you can use . My advice is to abandone the old and ugly framework , instead of learning to work with it - burden in your hands (soundgarden) .
I'm trying to write a scalable interactive chat application for an existing high traffic website. It needs to be scalable on day 1, and chat's concurrency and multi-broadcast issues make it a tricky thing to scale.
My initial plan was to write the whole thing in rails and refactor the chat server into erlang later.
Although I am an experienced PHP dev and sysadmin, both node.js and RoR are new and extremely alien technologies to me, so I could use a little help understanding the core concepts and applications in this scenario. With so many new technologies, it is hard to understand them all.
Firstly, I recommend you review http://ajaxim.com/. The software is a pre-packaged version of what you want that relies on Node JS (far easier than rolling your own).
If you still want to write something yourself and have no experience with either technology, I recommend you review some introductory materials:
Node JS and Rails
The two sources are not free but will give you a quick one hour crash course on each technology.
You can also have a look at http://pusherapp.com ! This is if you want to implement a chat app right away.
If on the other hand, you want to implement one all by yourself, Node.js + Socket.io is your best bet. However, if you want chat rooms and stuff, have a look at this:
http://github.com/shripadk/express-juggernaut-demo
This demo app uses Express.JS framework and Juggernaut 2.
I would suggest going for only Node.js if you are building apps that require high concurrency. Its fairly easy to implement a chat room using Node.js compared to other server-side languages (mainly thanks to modules like socket.io). The event-driven architecture of Node.js makes it really easy to implement such stuff. The only catch with Node is that you have to think everything asynchronous! If you are good at Javascript then Node.js should be easy to learn.
How can i write a cloud-aware application? e.g. an application that takes benefit of being deployed on cloud. Is it same as an application that runs or a vps/dedicated server? if not then what are the differences? are there any design changes? What are the procedures that i need to take if i am to migrate an application to cloud-aware?
Also i am about to implement a web application idea which would need features like security, performance, caching, and more importantly free. I have been comparing some frameworks and found that django has least RAM/CPU usage and works great in prefork+threaded mode, but i have also read that django based sites stop to respond with huge load of connections. Other frameworks that i have seen/know are Zend, CakePHP, Lithium/Cake3, CodeIgnitor, Symfony, Ruby on Rails....
So i would leave this to your opinion as well, suggest me a good free framework based on my needs.
Finally thanks for reading the essay ;)
I feel a matrix moment coming on... "what is the cloud? The cloud is all around us, a prison for your program..." (what? the FAQ said bring your sense of humour...)
Ok so seriously, what is the cloud? It depends on the implementation but usual features include scalable computing resource and a charge per cpu-hour, storage area etc. So yes, it is a bit like developing on your VPS/a normal server.
As I understand it, Google App Engine allows you to consume as much as you want. The back-end resource management is done by Google and billed to you and you pay for what you use. I believe there's even a free threshold.
Amazon EC2 exposes an API that actually allows you to add virtual machine instances (someone correct me please if I'm wrong) having pre-configured them, deploy another instance of your web app, talk between private IP ranges if you wish (slicehost definitely allow this). As such, EC2 can allow you to act like a giant load balancer on the front-end passing work off to a whole number of VMs on the back end, or expose all that publicly, take your pick. I'm not sure on the exact detail because I didn't build the system but that's how I understand it.
I have a feeling (but I know least about Azure) that on Azure, resource management is done automatically, for you, by Microsoft, based on what your app uses.
So, in summary, the cloud is different things depending on which particular cloud you choose. EC2 seems to expose an API for managing resource, GAE and Azure appear to be environments which grow and shrink in the background based on your use.
Note: I am aware there are certain constraints developing in GAE, particularly with Java. In a minute, I'll edit in another thread where someone made an excellent comment on one of my posts to this effect.
Edit as promised, see this thread: Cloud Agnostic Architecture?
As for a choice of framework, it really doesn't matter as far as I'm concerned. If you are planning on deploying to one of these platforms you might want to check framework/language availability. I personally have just started Django and love it, having learnt python a while ago, so, in my totally unbiased opinion, use Django. Other developers will probably recommend other things, based on their preferences. What do you know? What are you most comfortable with? What do you like the most? I'd go with that. I chose Django purely because I'm not such a big fan of PHP, I like Python and I was comfortable with the framework when I initially played around with it.
Edit: So how do you write cloud-aware code? You design your software in such a way it fits on one of these architectures. Again, see the cloud-agnostic thread for some really good discussion on ways of doing this. For example, you might talk to some services on GAE which scale. That they are on GAE (example) doesn't really matter, you use loose coupling ideas. In essence, this is just a step up from the web service idea.
Also, another feature of the cloud I forgot to mention is the idea of CDN's being provided for you - some cloud implementations might move your data around the globe to make it more efficient to serve, or just because that's where they've got space. If that's an issue, don't use the cloud.
I cannot answer your question - I'm not experienced in such projects - but I can tell you one thing... both CakePHP and CodeIgniter are designed for PHP4 - in other words: for really old technology. And it seems nothing is going to change in their case. Symfony (especially 2.0 version which is still in heavy beta) is worth considering, but as I said on the very beginning - I can not support this with my own experience.
For designing applications for deployment for the cloud, the main thing to consider if recoverability. If your server is terminated, you may lose all of your data. If you're deploying on Amazon, I'd recommend putting all data that you need persisted onto an Elastic Block Storage (EBS) device. This would be data like user generated content/files, the database files and logs. I also use the EBS snapshot on a 5 day rotation so that's backed up itself. That said, I've had a cloud server up on AWS for over a year without any issues.
As for frameworks, I'm giving Grails a try at the minute and I'm quite enjoying it. Built to be syntactically similar to Rails but runs on the JVM. It means you can take advantage of all the Java goodness, like threading, concurrency and all the great libraries out there to build your web application.