I have 2 questions:
First, what's the difference between a web application and a cloud application? Are there any differences at all? If I'm developing a web application (a site with many interactive features), can I call it a cloud application?
Second, if there's a difference between a cloud and web application, what languages can cloud applications be developed in? Would a scripting language like PHP be useful for that?
Thanks.
UPDATE: I have watched the video in one of the answers, but I am still a little confused. Taking Google Docs as a example, all I see is a user interface that can be created with html and JS, along with a server script, and the data is stored in a database, which is basically the same thing a web application does. Or is it different?
Thanks
Web applications can run on "the cloud". The cloud is basically a collection of dynamic computational resources (cpu, ram, storage etc) that can be used by web applications.
This allows apps running on the cloud to scale well because they are allocated resources dynamically.
You can use public clouds such as Amazon's EC2 - or build your own private clouds.
A web app running on a cloud isn't exactly a "cloud app" - but the app is simply hosted on a cloud.
I find the first half of this video explains it very well (if a little annoying).
Also see this quesiton which has some good answers.
A web application is an just an application deployed on a web server.
The user accesses this application knowing that it is accessing a remote application and this application has a specific purpose.I.e. implements a specific functionality.
When you start talking about the cloud, you have a different concept alltogether.
The idea is that you want to access a service that you have no idea where the service actually is being deployed.
The main benefit is that a company can save resources.
For example a company can have e.g. their own CRM and have to pay money for servers, for IT personel etc. or just access a service in a "cloud" where the company providing the cloud is responsible for the servers etc.
So to answer your question, to build the cloud you use web applications as "modules" to provide the cloud.
But a web application by itself (separate of this context) can not be considered as cloud application (unless it runs as part of the cloud).
Anything that runs locally can run in a "cloud". Cloud computing is the inevitable movement of traditional applications/processes to a dedicated provider. Analogous to the Walmart syndrome, where little mom and pop shops have fallen by the wayside.
The difference between a cloud and web application is where it sits.
Web and cloud apps both are distributed applications having server and client parts. They store data on a server side, but can have local data cache for offline cases.
Web applications performed/run by browsers. Normally, they are written on HTMP/CSS/JavaScript. Adobe had another vision of client parts. They proposed special Flex language for Abobe Flash as client run-time environment (prior it has been killed this year).
Cloud apps are very similar to web apps, but their client parts are native applications specially developed to run on selected target platforms (OS X, Win, iOS, etc.)
Related
My web app has multiple App Engines. Each App Engine has its own function. Apps were created with PHP as backend in Google App Engine and uses Cloud SQL and Google Cloud Storage for database and storage respectively.
The following Google App Engines are needed to be combined:
Client Database App
Permission Database App
Transactions Database App
Fields App
Reports App
Performance App
Data Entry App
Pattern Matching App
They are all coded in PHP and run in Google App Engine. They use Cloud SQL and Google Cloud Storage for storing data. Can they be binded together to function as one?
An App Engine application is made up of one or more "services." Many developers only use the "default" service. You can split your app into multiple services and each service has its own app.yaml configuration file and its own settings. In fact, an App Engine app could be comprised of services running in different languages (Python for one, PHP for another), and even both runtime environments (Python on flexible environment, PHP on standard environment).
One of the nice things about this "microservices" approach is that you can deploy or rollback the code for each service independently of each other. You can also share resources across them like Datastore or memcache (Memcache and a few others aren't currently supported in the flexible environment though). You can also pick different instance types or scaling options for different services, which could help you optimize costs or performance.
So yes, this is possible and can be a very good practice for many applications.
I found myself in several discussions throughout the week regarding a web application under development and whether it should leverage an API that is being created.
Here's the situation. I have a PHP MVC web application with a MySQL DB as well as several mobile apps all being developed in house. For the mobile apps we're building a rest api. The big question is why should my PHP web application now use that rest api? I've always expected the use of an API to be for third party systems that need to interface with my database or for systems built on a different technology. The web app is certainly not a third party system and the services are in PHP. If the API is on a different server than the web app then I guess it could be considered a third party system... which has not been decided yet.
To me, it just seems strange to leverage the API for the web app especially since the APIs services are going to be limited to about 50% of the functions available in the web app leaving me to build the other 50% that would be unique to the web app. I also foresee a performance hit to the web app stepping through the service layer rather than just accessing the DB directly. On the other side I see more maintenance having a code base for my web app hitting the DB and similar functions built into the api for mobile apps.
Has anyone found themselves in a similar situation and can provide some technical pros and cons to why I should just use the API or can point me to a solid case study?
Pros:
What if one day you decide to move the backend app to another machine? With an API, your app code won't need to change.
What if one day you grow, and need to scale to 10000 backend apps instead of 1? With an API, your app code won't need to change.
What if one day you decide to swap out MySQL for Mongo? With an API, your app code won't need to change.
^ Enforced separation of concerns between data access layer (DB) and application
Cons:
More code up front when writing the app layer
More incremental work when you need to support a new app layer feature that your API doesn't support yet
To me, the pros clearly win.
I'm totally new about mobile application development and i'm getting really confused about few things.
I'm actually developing web application under zend framework 2 (php framework) and Zend studio (IDE).
So to not starting all over again i want to make a mobile app (for learning purpose) with ZF2 and Zend studio.
I've been following that tutorial.
So i'm not sure to understand how the data are stored. Until now i have used MySQL with phpmyadmin for my web applications.
From what i understand, i need to use a cloud server such as Parse, phpcloud or else, am i right?
My question is, how the website and the mobile app will share the same data?
typically you will have to write web services that will expose a few methods which in turn will get the required data you want to share.
So your connectivity should look like Mobile APP --> Web Service --> DB
Make sure to thrown in some kind of authentication to avoid abuse of your web services. The webservice can be deployed on the same server that is hosting the website
One more way is to access the mysql database directly from your mobile application . This is NOT recommended because essentially you are exposing your DB to the world. This is OK in case of a corporate application which will only work within your company network or with a controlled environment.
You can use a PaaS like Heroku or Openshift to host your web application. But The web application must also expose a set of web services, which can be used to send and receive information to and from the mobile app.
I think the tutorial you mentioned explaining about building a mobile web site. That is you need to support your web site for small screens like mobile phones or tablets.
If you are planing to build a native mobile application, best approach would be to expose core services using RESTful web services.
using the same database... you have 2 options.... either make a php script to attend the mobile request, or creating a special mysql user that has access to the same database your website uses...
I have a Windows Azure subscription.
My requirement is to run a PHP script on my server. This PHP script will create a JSON file.
This JSON file will be downloaded by my iOS app. (Some kind of authentication is an added bonus)
How would I go about doing this? Should I create a "Mobile Service" or should I create a "Website" or something else like "Cloud Services"?
As far as I have researched, I think the only way to do this would be the old school website way. Any input on this will be really helpful. Thanks.
Mobile services are great if you want to create a quick CRUD layer for an app with a backend cloud storage such as Azure SQL DB. It also provides support for scheduled tasks and push notification. But for what you're after (producing a JSON file), you may find it easier to go with Azure Web Sites or Azure Cloud Services (PaaS). Azure Web Sites has a model that you'll likely find easier and with the free/shared tiers, provides a lower cost point for many models. If you want something that gives you a bit more control, then Cloud Services might be a good alternative as well. But given the simple example you've provided, you should be able to accomplish this fairly quickly using Web Sites.
I have one .php web site and I want to put it in iPad application "web application".
I mean create UIWebView and load files in WebView, so my First question is, is it possible to create this webApp and can I run it on Xcode simulator?
What do I need for implementing this application (Apache, MySQL) inside ipad outside?
Basically I want to have all my .php class inside of app and run it via iPad app, it means that if I hadn't any internet I can run the application.
Since I want to run it in both iPad and XCode simulator.
Would you please give me some hints for implement this application?
A few points you need to think about:
App Store Approval - if you intend to market this app (i.e it's not for jailbroken devices via Cydia, or an in-house corporate app) then you will most likely run in to issues with the approval process.*
You're intending to bundle in a scripting language with your application. Now this may not be an issue depending on whether or not this is exposed to the end-user; but you do run the risk of Apple finding out and pulling the plug.
The alternative to bundling in a scripting language (PHP in your case) is going to be loading the code off of an external server. This is a no-no straight away, as Apple requires your application to have functionality offline - or atleast they did. Where this leaves all the Social Networking and other network-dependant apps... Well, I guess there are exceptions!
Device Performance - you're essentially intending to run a small web server on a mobile device; a tablet in this case. This could be very resource intensive, so is probably not wise. I personally wouldn't want my battery being drained because someone has decided that they want to bundle in a web server with their application.
Your implementation idea itself is sound, in the respect of using a UIWebView. You should probably check out the Apache Cordova/PhoneGap framework, and that should satisfy your needs and provide an off-the-shelf way of packaging up your web app. If you do need custom functionality then it's worth looking at anyway; plugins are relatively easy to develop, there's a wide range available already and the plans for cordova now are to allow developers to implement it into native applications. (Say, if only one view requires PhoneGap functionality etc)
Personally, I fail to see what requires PHP that can not be done via HTML5 and PhoneGap. There are storage options available, SQL options, you're using web technologies so can easily query external web services. It's also a lot safer with regards to app approval - as it's tried and tested; there are many applications build using such solutions already in the store.
I think you need a serious re-think. Otherwise, perhaps you could post some more details?
Please note that PHP is a server-side language. So do you want to run a server on your iPad? If so, you can develop PHP applications on a proper desktop/laptop and then view them on iPad Safari browser over Wifi.
Otherwise you can install LightHTTPd server with PHP libraries, MySQL, CURL and all from Cydia app store on a jailbroken iOS device to get a full environment. For Android there is this app PAW server available which can run an Apache server in such devices.
If you just want to check your website is working fine on small devices, or you want to check responsiveness of your website. Go to:Ipad Peek and run your website on given devices/simulators using url.
A simple google search pulled up this free framework: http://www.ipfaces.org/
I've never used to before, but it might do what you need.