I've been ramping up on Azure Mobile Services over the past week. There are definitely some PROs and CONs in using them over a standard Azure Web Site where I can write APIs that hit SQL DB, etc.
One of the biggest negatives I see is developing the server side code and DB structures ON THE SERVER. I've watched lots of videos from launch and beyond, read lots of blog posts about tips and tricks around WAMS, but nobody seems to talk about the downside of developing the code (server scripts) and database structures on the server, at your live URL.
This is all great for developing the first version of your mobile app and associated mobile services. But once it's all deployed, how do you ever build version 2? Real apps hitting real APIs and data, but now I want to develop/change/play with the server scripts and database schema?
With Azure Web Sites, I can develop locally and only publish code and DB changes to the server on my schedule.
Have any of you seen or heard of the "v2 development story" around Azure Mobile Services?
Only thing I can think of would be to create another set of tables and APIs around them, most likely "virtual tables" that allow me to write APIs against the original set of data. Seems like a huge hassle, since the client code would now have to know about the original set of tables and the new set of tables... that's only for v2...
Thanks for any thoughts / insight.
You should have two services, one dev and one production and use scripts to promote your code from dev to production (pretty similar to how most workflows go, in moving from a test setup to a production one).
http://channel9.msdn.com/Events/Build/2013/3-511
Related
I need some help with deciding on the architecture of my project (a web app for unlocking discounts). I am first planning on creating the website (React for the front-end & Django for the back-end, PostgreSQL database). In the future, I may create a mobile app too for Android & iOS (unsure what front-end framework yet).
So I have decided I want the front-end and back-end to be completely separated so the back-end is a REST api. This will allow me to not have to create multiple back-ends for mobile apps.
But, after researching, I have found that this could be quite expensive in terms of server costs. This is a new business and I am the only developer so funding isn't high. So I was thinking that I could deploy the front-end & back-end on the same server but as separate apps that talk via nginx?
I have 4 questions about this:
If I do this, would it still be possible to reuse the back-end as a REST api for the mobile apps or is that a no because it's linked to the web front-end?
If it is possible, would I be able to host the mobile front-end in the same server (so have everything hosted on 1 server)?
Is this a stupid idea - would I just be better off deploying everything into separate servers in the long-run (to reduce load)?
Should I just worry about this in the future? And for now just deploy the separated web front-end & back-end to the same server.
I have never really deployed anything into a real life production environment so I'm sorry if my questions seem silly. I haven't started development yet but I want to think about scalability & future extensibility before I start. Thank you.
Nowadays I'd go with a serverless approach. Instead of having servers to maintain you can focus on your app functionalities.
There are a lot of options. You can check, for example, AWS Amplify (https://aws.amazon.com/amplify/) or Netlify (https://www.netlify.com/) for a more "full-stack" approach.
In AWS, you also can keep separated projects, having your backend in lambdas and your frontend served through S3 + CloudFront. You also don't have servers to care about.
There are only examples of how you can solve your problem without servers, but answering your questions:
You can reuse your APIs regardless of the way your app is deployed. It will be more related to how you designed them;
Yes, you can host everything in a single server if you want, but I really don't recommend that;
If you don't want to pay for 24/7 servers, you can go for a serverless approach;
As I told you before, you can do what you want without worrying about servers.
Your main point of focus is to keep the cost lower and to implement a good solution also. My suggestion would be to look for AWS Lightsail. Lightsail offers fixed price VM which you can configure yourself, and it starts from $3.5 / month at the time of writing this answer.
My answers to your questions
If I do this, would it still be possible to reuse the back-end as a REST api for the mobile apps or is that a no because it's linked to the web front-end?
Yes, it's possible. Keep the frontend and backend in different repo, and you can deploy it as docker instances on the same server. You will have 1 frontend docker container and 1 backend docker container, and they can communicate with each other.
If it is possible, would I be able to host the mobile front-end in the same server (so have everything hosted on 1 server)?
For mobile, you will develop a mobile application which you can publish to playstore or deploy to smartphone. Your app can then call the backend service and get the JSON in response. So you have to design your backend in such a way that it can serve data to both requests.
Is this a stupid idea - would I just be better off deploying everything into separate servers in the long-run (to reduce load)?
For long term and design perspective, you need to consider factors like scalability, maintainability, security etc.., so its always better to have multiple server to avoid single point of failure.
Should I just worry about this in the future? And for now just deploy the separated web front-end & back-end to the same server.
My advice to you will be to think carefully now, so you don't get nightmares in the future. Invest your time now and design a stable solution which could help you in long-term. As you mentioned that its a small business, but your solution should be able to easy handle growth.
My suggestion
As suggested by the Paulo, S3 + CloudFront looks good for frontend. You can get 1 year free CDN using Lightsail.
For Backend, you should at least have 2 (I will suggest minimum 3) servers and deploy backend docker containers. You can use docker compose to automate the deployment. If you want to orchestrate then Docker Swarm Mode is best. With this you will avoid single point of failure. You can get very affordable servers from Amazon Lightsail
For database, you need to make it scalable. To ensure scalability and High Avalability we should have replicated DB. Minimum 3 DB instances will be good starting point. MongoDB is a good choice. With simple configuration you can enable DB replication. 1 Master 2 slaves instances.
1 Load-balancer in front of your servers to distribute the load. To save the cost you can configure the Load-balancer yourself but this will add learning curve and you will have to spent time and understanding the details. The better solution is to use a managed load balancer. Lightsail offers Load Balancer for $18 / month at the time writing this answer.
The above mentioned solution is cost-effective and will give you long-term benefit and also you can estimate the cost based on your solution.
Obviously, this can still be improved but I tried to cover the necessary aspects of the question asked.
We have a python based server that uses mongodb database. Our server programs uses RabbitMQ to exchange request/reply packets with many Android apps and perform actions accordingly. In addition to this, now we also need to create a web portal for the admin staff to let them manipulate the database, upload/download files, view data/statistics and trigger actions for android clients. So, the database is going to be common for the portal and the existing server programs.
For the web portal development, I got a recommendation for using Plone. We are comfortable in using traditional Node.js. Could anybody guide me on the use of Plone within this context. Is plone able to communicate with mongodb and existing server side programs?
Plone is a CMS designed around managing web based content and is tightly integrated for storage of its data in the ZODB, a NoSQL database. If data is very custom and isn't all about webpages and website nagivation etc, or if you have a need for the data to live in a different kind of DB then Plone probably isn't the right tool for you. This isn't to say it can't be made to do these these things but you would have to learn a lot about it's internals to make it do these things.
I'm trying to build an API which can be used to update some master data in my app. It contains various drop-downs for city, country etc. Whenever I add new data in these drop-downs, I need the apps to hit this API once a day and get the latest data. Also, if the API is requested older data (from older apps), it should be able to return such data based on some date query parameter.
What's the best way to create such an API?
Also, the API needs to be RESTful and will be exposed to Android/iOS environments.
API should be able to return so based on some date query parameter.
You can use two columns created_at and updated_at in you tables schema. So how can this will useful for your situation:
Whenever some one hitting api without date parameter, you are return all data which are created before current time.
Whenever some one hitting api with date parameter then you can return data which are created before value of date parameter.
Obviously you have to write complete logic for this at server side
end.
Please explore one of the Mobile Backend as a Service (mBaaS) products for your long term needs.
Here are some players:
BaasBox: Open source backend
Backendless: Allows
developers to have an instant backend without writing server-side
code.
Apigee App Services: provides a lot of free storage, push notification, analytics etc.
Appcelerator: An BaaS targeted at the Enterprise audience.
For the short run you may want to try https://www.webscript.io/ to embed some quick javascript code to return the JSON response for you.
I would put a spin on #Santanu's suggestion of using BaaS. I would recommend using a BaaS during the development phase of your project.
When the iPhone and Android Apps have been developed and tested, replace the Baas-based server components with a in-house built RESTful server.
This approach has a couple of benefits. It lets you divide the effort into two distinct parts: the client changes to your product, and the building of your server component.
I assume your company's current expertise lies in App development, so it should be easier for you all to upgrade your applications to use the BaaS-based APIs.
It will also be much easier to reiterate and refine your data components and models using a mature BaaS server.
With Apps using data requests to populate the drop-downs from a BaaS-based RESTful API, and stable working data models and data sets hosted in the BaaS servers, it will be much faster to start building your own RESTful service.
When you run into issues, you will be confident they are in the server side code. You can run A/B tests with the same Apps against two versions of the server and ensure the client experience is the same.
You could continue to use the BaaS Server for rapid prototyping and developing API extensions.
I'm writing a mobile application, and this mobile application will be talking to a server in Azure to get data, and possibly push some too.
Now, I always had it in mind that I was going to write a simple RESTful web service that was going to deal with all this, and host it on Azure in a website - however, I've since discovered their Mobile Services, and I'm not entirely sure I understand what it's for.
Looking at it, it seems that it's about extracting away the code running on the server from you, and what you push to it, is what you get back? So it wouldn't be much use for me, as my web service is going to be returning data dependant on logic etc. However the ability for the Mobile Services to deal with push notifications directly is nice (how hard is it to use Azure Websites to send push notifications through mobile services?)
However, I wonder if I'm missing something? I'd rather not have to go re-invent the wheel as such, is Mobile Services will do what I need, especially as I'll be using Xamarin and there is a nice component to talk to Mobile Services...
Thanks
I am facing the same question: Should I use Azure Mobile Services or roll my own REST service. Below are some discoveries I have made so far.
With Azure Mobile Services there is a backend running a set of assemblies, which your code ultimately depends on. This is fine until you start using versions of other assemblies, which are not compatible with the versions Microsoft hosts. To me this is a major pain. This problem alone makes me question whether I want to use Azure Mobile Services. If you make your own REST service, I do not expect you to face these problems. See this link for details.
You should note that an Azure Mobile Services is tied to a single Azure region: If your Azure region fails, you need to manually migrate to another Azure region. This might not be a problem for your project. If you want to run in more than one region, I think it will be easier to roll your own REST service.
Regarding push notification, you could do that without using Mobile Service. See these links:
http://msdn.microsoft.com/library/azure/jj927170.aspx
http://weblogs.asp.net/scottgu/broadcast-push-notifications-to-millions-of-mobile-devices-using-windows-azure-notification-hubs
Auto-scaling is supported out-of-the-box in Azure Mobile Services. You would need to make your own scaling logic if you make your own REST service. You can scale VMs using Azure’s REST API, but it will be more work than using Mobile Services.
Authentication is supported in Azure Mobile Services. You would need to look into a separate framework to do this if you make your own REST service.
If you use Mobile Services you will probably create ASP.NET Web APIs through the Visual Studio wizards. There are examples and tutorials, which is great. However, even if you roll your own service, you could build on other frameworks. One example is ServiceStack, which I would strongly consider if you want to make your own REST service. I think ServiceStack could also help with authentication.
If you use Mobile Services you will tie yourself stronger to Azure. By rolling your own REST service it will probably be easier to move to another infrastructure later.
I wanted to make a web application through which :
user(end user) can create his own
web application online.
which will be integrated with the
databases and application/web
servers
and user can also publish that
application withing that application
only...
Doing some research i come to know it goes under category of PaaS(Platform as a Service)
But i am confuse how can i do that ?
I want to build that application using Java/J2EE.
Can any one explain me from where should i start ?
Or which framework / technology is better to implement it in Java ?
Waiting for your helpful reply....
There are several options as far as choosing a PaaS - each PaaS vendor has its pros and cons, so you need to consider a range of issues:
Language support - Do you want just Java or maybe additional languages/frameworks?
Hosting - Are you going to use a cloud computing provider like Amazon Web Services? Or are you using your own hardware? Or do you want multiple options?
DB support - You mentioned using a central DB. Do you plan on installing/administering this DB yourself, or use a hosted DB service? Do you need the PaaS to support the particular DB you want? Perhaps you need multiple Databases to provide scalability and separation among clients?
There are several good comparisons of PaaS vendors out there. This might be a good place to start: Looking for PaaS providers recommendations
Full disclosure: I work for Cloudify, an Open-Source PaaS provider.
I think while choosing a PaaS you should think of the below points.
It should be easy to deploy, scale and manage
Scaling
Flexible topology
Data safety
No vendor lock in
Open software stack
I suggest you, before going to any big vendor try a new player in town Jelastic. I recently used their services and continue to do so and they are just awesome. Their web UI is best in class and has no drama of API, SDK or downloadable software. Let me know if you use them so that I can also have some feedback before I migrate all our apps to them.
Surya
As far as i understand, you are looking for a solution that Viravis is currenlty implemented.
But believe me it is not an easy task to build that kind of platform. i strongly suggest you to look at some PaaS providers to get involved and build a business relationship to achieve your goal. They are just exists for this purpose. Provide platform for people who just want to develop a single online application or some professional who want to build an SaaS business.
I think it is better to hire the platform rather than build it from scratch (ofcourse if you dont have to...)
A web application consists of language, framework, database and Web-server.
If you want to make a web application in java, you should try GRAILS framework.
Its fast and web development is very easy and you can use java code as it is, in it.
Secondly you can choose database from MySQL, PostgreSQL etc or if you want to use No-SQL dbs, you can choose from MOngoDB, CouchDB etc.
Web-Servers can be tomcat, jetty etc.
After creating you application, you would like to host your application on web, Here PaaS comes to play. It helps you to deploy and host your application on web. So what you have to do is only to focus on your application and then deploy your app on any PaaS providers.
There are many PaaS providers in market, you can choose any.