This is more of a general question about the future of AppMaker I guess... I have a few ideas that I would like to try out - mostly some tools that could help my clients - and I was wondering if there will be a way to deploy an app made with AppMaker to multiple domaine.
A (dumb) example would be to create a Task management app that you can centrally develop and deploy as a Saas service to multiple clients.
I would be interested to hear some insights before investing too much time in this.
Currently, App Maker applications are restricted to the domain of their owner. However, you can export an App Maker application and import it in multiple domains and possibly share the same Google Cloud SQL backend. Keep in mind that sharing the same database will be challenging when it comes to changing the schema since you will have to synchronize updating the applications in the different domains.
Related
I'm developing a project where I need two PWA apps defined on the same Firebase project, sharing the same database. One of this app is the 'producer' and the other one is the 'consumer' of the data.
So far I developed the 'producer' side and everything is ok - it writes in the database. Now I'm starting with the 'consumer' side.
Defined like now I'm not able to deploy the second one, cause it shares the same hosting so it overwrites the first app.
How can I structure the project to have two PWA apps sharing the same DB but not the same hosting (and URL)?
It sounds like you want to create a second Firebase Hosting site in the project, which you can then deploy to separately.
Pretty simple Use-case, clients buy our app and pay 20$/month.
We want to implement push notifications on both iOS and Android and are thinking of a scalable solution.
We thought of simply grouping all Apps inside one Firebase project, as we only need Push Notifications.
Google Firebase FAQ says:
A project is a container for apps across iOS, Android and web. While there is no restriction on number of apps within a project, adding an app can create one or more underlying OAuth 2.0 client IDs. There is a limit of around 30 client IDs that can be created within a single project.
You should ensure that all apps within a project are platform variants of the same application from an end user perspective. For example, if you develop a white label application, each independently labelled app should have its own Firebase project.
Would this limit us?
Do I need a client ID for each and every App inside my project?
firebaser here
What you're trying to do is known as whitelisting, and is not an intended use-case of having multiple apps in a project. To not run into the limitation you've found, you will need to create a separate project for each client.
If you create multiple technical applications for a single client that are logically the same, those can exist in a single project. For example: the Android, iOS and Web versions of an app are typically using the same Firebase project, as may be specific app you build for the application administrators of your client. By having those apps be part of the same project, they can share backend resources.
So I'm pretty green to the industry, please excuse what I'm assuming is huge swaths of ignorance. I'm looking to develop an ASP.NET webapp (with a SQL Server db) as a kind of in-house tool for our employees, accessible from anywhere. We're a company with virtually no IT infrastructure, so these employees (~100) will be accessing this application from all around the country on what are basically personal computers. I don't ever expect there to be any more than 10 users using the webapp concurrently. The web app is going to be the frame for a series of tools I've been making for the head office guys, but from a central point that's easy for me to maintain.
We have our own domain, so that's taken care of.
I'd like to find a cloud-based tool that would pretty much just involve me deploying my code to it, and that's about it. I've take a look at Azure and that seems like the way to go, but I know if I present a price too high the bosses won't exactly be thrilled.
I was hoping some of you guys had some experience in setting these kinds of things up. Here's a series of questions I'm having a hard time coming up with an answer for:
Looking at the Azure cloud-based webapp, What da heck specs do I get? Is Standard S2 too much power, or nowhere near enough?
Do I need to purchase an Azure SQL Server thingo seperate to the Web App hosting, or does it come bundled in?
How the heck do I deploy my dang code?
I've been getting off pretty easily as I used to have a team behind me, and now I'm alone at a new company, there's not many people whose brains I can pick. I've had a call or two with a Microsoft employee, and they were helpful, but not entirely helpful enough. They keep assuming I know what I'm doing - I don't. So any help from anyone would be greatly appreciated!
You need to learn two services of Azure:
1.Azure Web app service:
Azure App Service is an HTTP-based service for hosting web applications, REST APIs, and mobile back ends. You can develop in your favorite language, be it .NET, .NET Core, Java, Ruby, Node.js, PHP, or Python. Applications run and scale with ease on both Windows and Linux-based environments.
This document will teach you develop web app with Azure SQL and deploy your app to Azure.
2. Azure SQL database:
Azure SQL Database is a general-purpose relational database, provided as a managed service. With it, you can create a highly available and high-performance data storage layer for the applications and solutions in Azure. SQL Database can be the right choice for a variety of modern cloud applications because it enables you to process both relational data and non-relational structures, such as graphs, JSON, spatial, and XML.
Azure SQL database is a cloud database. If you have the develop experience with SQL server, you will be familiar to it.
Azure App Service and Azure SQL database are independent, in Azure, which service you want to use, just pay for it.
You need an Azure Web app service to host your app, and you also need a Azure SQL database. Then you can develop the app with Azure SQL database.
Each service has the different price tier to meet the performance requirements of the user. You need to choose the most suitable for your company to save the money.
Hope this helps.
I know such questions have already been asked many times, but I am here with my scenario. Kindly do not delete or vote to close.
I have an asp.net application with L2S and SQL 2008 R2 as backend
Using N-Layered architectured
Mostly normal crud operations to be performed.
Use of Sessions and View States
Manual Login / Logout(User and Roles management) , no .net Membership has been used.
No services used yet, might be a later part.
Third Party controls like Telerik or Infragistics also are in use.
I want to know:
Do i need to change entire application to Azure Web Application?
If not, is it possible to deploy it directly over the cloud , on MS or any other, as we normally do in IIS?
If not, Is there any third party migration tool available to make my plain old web application cloud-compatible, without affecting existing codes ?
I want cost effective and easy to go steps?
Thanks in advance
Yes that should be possible. You almost certainly do NOT have to change your whole application.
Linq2SQL is fine, I run an Azure site with L2S without any problems
You'll have to deploy your DB to a SQL Azure database. There are some restrictions, like all of your tables must have a primary key. A bigger list is here: http://msdn.microsoft.com/en-us/library/windowsazure/ee336245.aspx.
Also, when generating your SQL scripts, be sure to select SQL Azure as the database engine type: http://mooneyblog.mmdbsolutions.com/index.php/2011/09/22/generating-azure-friendly-sql-scripts/
What do your N-layers look like? If they are DLLs, it's fine. If they are web services, you'll need to create web roles for them. If they are windows services, you'll need to port them to a worker role.
Most crud and view state and manual authentication code is fine
For session, it depends on what you are doing (memory vs database). But you'll have the same challenges that you would have if you deployed to any web farm
For Telerik, I'm sure they have to have some support for Azure, and I don't think they would be doing anything crazy that would not work Azure. You should check out their website to verify compatibility.
Also, make sure you are not writing to the hard drive anywhere and expecting it to be there later, because instances can be started and stopped and reimaged at any point. If you're doing that, you'll need to change it to use something else like blob storage.
I have an ongoing series of blog posts that walk through some of the steps, which should help: http://mooneyblog.mmdbsolutions.com/index.php/category/azure/
Good luck!
I don't see any hassles to deploy your web application into the cloud.
You don't need to convert your entire application to anything else.
After all you can just try to deploy it now with the trial subscription in Windows Azure which is free for three months.
There is a fairly big stuff of new technology in Windows Azure such as service bus, azure storage, access control service, etc. However it's not necessary to use all them right now. It's prety easy just to move the existing app into the cloud.
You can deploy it to Azure web site.
That should be easier if you don't want to use SQL Azure and cloud storage.
How can we move our existing ASP .Net 2.0 application to the cloud platform ?
What all changes are required in existing application at code level as well as database level ?
Update: I have one ASP.Net 2.0 application with SQL 2008 database. I want to deploy it on the cloud environment with multi-tenancy support.
In that case what changes are required. Currently 'ConnectionString' is configured in web.config file. How to change the code/ database to achieve multitenancy support.
Basically I am looking for steps to move existing ASP.Net application to the cloud platform.
Please suggest resources for the same.
I am not sure what you mean by multitenancy suppport. Multitenancy usually means that you will need to work on your application and segregate the data for different organizations. Not sure what the cloud has to do with this. If you are expecting to just spin different instances for different organizations you will have to do work again with the API of the cloud provider in question. Some of them can manage applications and instances automatically.
Cloud provides scalability and elasticity (automatic scalability) it does not provide mutltitenancy by itself. To achieve maximum scalability you may need to use cloud data store (usually key/value) and let go of relational databases. This may require serious rearchitecturing of the application. Whether you need this scalability and elasticity is another topic and you may just use the cloud as infrastructure (i.e. they will manage the servers for you)