I am currently studying how to make cross-platform mobile apps (with xamarin forms), and I have heard that the "correct" way to connect to a database in a non-locale server (in my case located in Azure) is by using Rest Services (or rest APIs, or however is called), instead of connecting directly to the database with the server explorer option of VS like you would do in windows forms for example(using the SQL connection, dataset, etc. Which I think they are not necessary in the first case, I am not sure).
The only answer that I have received about this is that in mobile apps "They are not permanent connections. It connects, gives you data and disconnects. They are Asynchronous connections.", and that this is done "For optimization of connection resources. The mobile is suspended or the user passes the App to the background.".
But I still don't know if this is the actual reason, and if it is I don't understand how it optimizes the connection resources. So if someone has time to explain this I would appreciate it.
Thank you for your time, I hope I have explained myself correctly, and that you all have a great day.
As Jason said,the Security issues，with proper authorization having mediator is definitely much more secure than giving a user direct access to the database, because you restrict him to the end points which run only the queries you want to.And from the platform independence and maintenance,if the apps are developed in different languages and on different platforms,it may have benefit to create a common REST interface to allow sharing of data model, caching etc.For performance and scalability，that HTTP layer of your REST API provides another valuable caching mechanism. Your servers for your REST API can put caching headers on their responses, and these responses can be cached at the network layer, which scales exceptionally well.
you could read this link Why do people do REST API's instead of DBAL's?,I think the answers are pretty good
I want certain data from a iot endpoint or desktop implementation of app to be seen on mobile version of an app and visa versa. All endpoints should be able to access and change data as they see fit.
What are the ways that you can make data available to all endpoints? For instance I have a list of tasks that i make on the application on my desktop. Then I leave my house turn off my desktop and pull up the mobile version of the application. I want to see that same list. What are the ways to do this? I have considered a cloud hosted database but it kinda seems like overkill to have a database to store maybe 10kb of data as well as the cost associated with using their service.
Things I have considered but discarded because they dont fit-
google drive with a shareable googlesheet
The issue is that it is read only. Also speed and functionality is limited.
database running on desktop that syncs to mobile app.
The issue is that mobile app needs to be running at same time as desktop. also any changes the mobile makes to the data will not be saved to database if desktop version is not on.
Is there a way to do this without having a personal server running all the time to serve out data? Is there any database hosting that is free? Or is there something more lightweight than a database that would allow me to access and modify the data from any endpoint that has internet?
Depends on many factors so a little hard to give you the "This is clearly the best option" answer.
Easiest? Probably kick up a hosted database in a Cloud provider. I'm partial to Firebase/Firestore (Google) for mobile. They're extremely low latency, so any changes are reflected pretty much instantly, and they have an awesome SDK that makes it really easy to get up and running quickly. It's equally as easy on mobile and desktop. It does require a Google Cloud Platform account to use it, but the free tiers are super generous, so unless you're doing a ton of updating, it's probably free to host it (and you get $300 free credits for the first year of GCP).
https://firebase.google.com/
Im developing a 'Multi-User' app and considering using the new(ish) chrome packaged app platform but I have a local database question.
As I understand it (correct me if im wrong), I can store data locally with IndexedDB, but this is exclusively run on the users browser so is only relevant to that user, any changes can only sync when the user is on-line (needing an internet connection).
My app must adhere to the 'offline first' model but as each local user is located in the same physical office on a local network, id like these users to be able to share and sync the applications data without an internet connection (in case its gone down). Meaning we don't bring the whole office down if internet fails, a sort of 'off-line multi user' model.
Is there a way for a chrome packaged app to store data on an internal local database, or am I going about this the wrong way?
You could use sockets to interact with your local network, but if I had to do it, i would use a local web server as a fallback when the internet connection is offline.
That would be a pretty neat feature. Unfortunately, there aren't any web APIs (or Chrome Apps APIs) that specifically facilitate peer-to-peer communication. As xmarcos says, the primitives are there for you to build it yourself, but it would be a pretty big undertaking.
Also one correction to your question: IndexedDB doesn't sync unless you build a syncing infrastructure on top of it yourself. You might be thinking about chrome.storage.sync. However, even in that case, the syncing is replicating only a user's own data, not doing a collaborative merge of multiple users' data into a single repository. You seem to be wanting the latter, and for that you're on your own.
You might be interested in reading more about distributed version control. Here's one concise description of a complicated topic.
how do you get the list of all the computer names/ip address on your network using the Silverlight framework? Thank you!
Doing any time of local network scan with Silverlight 3 is just not really possible. Silverlight 3 simply does not have that type of low-level network support. Well, it kind of does, but there are some severe restrictions. Silverlight 3 can open up a socket within a restricted range of ports to any address in the cross-site policy, or obviously to its origin site. This really doesn't help trying to find local machines.
Silverlight 4 will allow a relaxed networking sandbox which would allow you to open sockets (or web service calls). I guess you could then try to do some sort of search of addresses in the client machine's subnet to look for "local" computers. Silverlight is going to have to play with the same networking rules as any other device on a network, so if traffic is segmented out with switching technology then you are pretty much SOL trying to do anything too advanced, unless you can authenticate and use some network appliance or server that would give your Silverlight app the required information.
Since Silverlight is a client technology that is heavily sandboxed (for the most part, though you can create elevated trust environments and COM interop), I don't think that Silverlight alone is going to be able to survey the network to see what computers/ip devices are on it.
Most likely, you'd want to create a web service on the same domain from which the Silverlight app will be served. This web service could be built to survey the network on which it resides (and not the network to which the client is downloaded...that would be a security concern). The web service could then relay information down to the Silverlight Client to provide data about the network.
I am asking this in very general sense. Both from cloud provider and cloud consumer's perspective. Also the question is not for any specific kind of application (in fact the intention is to know which type of applications/domains can fit into which of the cloud slab -SaaS PaaS IaaS).
My understanding so far is:
IaaS: Raw Hardware (Processors, Networks, Storage).
PaaS: OS, System Softwares, Development Framework, Virtual Machines.
SaaS: Software Applications.
It would be great if Stackoverflower's can share their understanding and experiences of cloud computing concept.
EDIT: Ok, I will put it in more specific way -
Amazon EC2: You don't have control over hardware layer. But you can take your choice of OS image, Dev Framework (.NET, J2EE, LAMP) and Application and put it on EC2 hardware. Can you deploy an applications built with Google App Engine or Azure on EC2?
Google App Engine: You don't have control over hardware and OS and you get a specific Dev Framework to build your application. Can you take any existing Java or Python application and port it to GAE? Or vice versa, can applications that were built on GAE be taken out of GAE and ported to any Application Server like Websphere or Weblogic?
Azure: You don't have control over hardware and OS and you get a specific Dev Framework to build your application. Can you take any existing .NET application and port it to Azure? Or vice versa, can applications that were built on Azure be taken out of Azure and ported to any Application Server like Biztalk?
Good question! As you point out, the different offerings fit into different categories:
EC2 is Infrastructure as a Service; you get VM instances, and do with them as you wish. Rackspace Cloud Servers are more or less the same.
Azure, App Engine, and Salesforce are all Platform as a Service; they offer different levels of integration, though: Azure pretty much lets you run arbitrary background services, while App Engine is oriented around short lived request handler tasks (though it also supports a task queue and scheduled tasks). I'm not terribly familiar with Salesforce's offering, but my understanding is that it's similar to App Engine in some respects, though more specialized for its particular niche.
Cloud offerings that fall under Software as a Service are everything from infrastructure pieces like Amazon's Simple Storage Service and SimpleDB through to complete applications like Fog Creek's hosted FogBugz and, of course, StackExchange.
A good general rule is that the higher level the offering, the less work you'll have to do, but the more specific it is. If you want a bug tracker, using FogBugz is obviously going to be the least work; building one on top of App Engine or Azure is more work, but provides for more versatility, while building one on top of raw VMs like EC2 is even more work (quite a lot more, in fact), but provides for even more versatility. My general advice is to pick the highest level platform that still meets your requirements, and build from there.
This is an excellent question. Full disclosure as I am partial to Azure but have experience with the others.
Where I think Azure stands out from the others is the quick transition from on prem to the cloud. For example -
SQL Azure - change connection string, upload DB, go!
Queues work a lot like MSMQ.
Blobs are pretty much blobs any way you shake them but they scale like crazy.
The table storage component is good because it provides incredible scalability for name/value pairs - but takes some getting used to.
Service Bus is my favorite of the services because it allows for a variety of communications paradigms. Two SB endpoints first try to connect to each other, if they cannot, then they route through the cloud - makes for very secure and scalable processing when firewalls tend to get in the way.
Access control list - paired typically with the service bus to make sure the right people access the right things - think SAML in the cloud.
I hope that helps!
My cloud experience is currently limited to Salesforce.com
For standard business operations and automation it provides a significant number of features that allow us to get apps up and running very quickly. We are particularly benefitting from the following:
Security (Administrators can control access to objects and fields)
Workflow & Approvals
Automatic UI generation
Built in reporting and dashboards
Entire system (including our custom changes) is accessible via web services
Ability to make the data in the system available through public sites (e.g. eCommerce)
Large library of third party apps to solve standard problems
The platform does NOT solve every problem.
I would not use the platform to model a nuclear power station or build the next twitter.
The major points of cloud computing is to save on costs by paying for usage and enable immediate deployment of computing resources.
The costs are not purely x amount of cents per instance per hour. The costs include maintenance, development, administration, etc. The huge benefit of cloud, in my mind is to liberate the customers from having to manage anything that is not within the realm of their core business competency. If I am an insurance business, I want my developers to concentrate on my insurance problems that help solve needs of my claims, rates, etc. I would rather avoid dealing with problems of email servers, file servers, document repositories, and administrating OS patches, service packs, etc.
Thus, in my opinion, the biggest benefits are derived from the SaaS and PaaS cloud offerings. One should go to IaaS only when PaaS or SaaS have serious restrictions to specific needs (i.e. I need to install a set of proprietary COM components and Azure does not support them).
SaaS is good for commodity type of applications that are not the core line of business for the client, but are more of a utility. These are your typical Messaging systems, Portals, Document Repositories, Email systems, CRMs, ERP's, Accounting, etc. etc. etc. Why reinvent the wheel by writing your own when you can customize a well supported third party product.
PaaS is great for core line of business software that supports companies' main business offering. Abstracts clients from having to deal with OS management and lets clients concentrate on the business system development - something that noone else can do for the client.
One can also take advantage of the benefits of PaaS (let's say, Google App Engine) and extend it, at times and if necessary, by pulling out some virtual machines from IaaS providers (e.g. Amazon) to do some number crunching then just send back the output to Google App Engine.
This way, you get the best of both worlds -- you can rapidly develop scalable apps in GAE, then you can always augment it by running any program you want from Amazon virtual machines.
This keeps changing, now Windows Azure also supports VM, so it is also an IaaS provider now.
Now how about Free Amazon EC2 for a year to do a better comparision. Check this out.
http://www.buzzingup.com/2010/10/amazon-announces-free-cloud-services-for-new-developers/