Current situation
I have multiple ionic react apps for different purposes. Lets say: one is a recipe app, the second a restaurant reservation app and the third a restaurant rating app.
All apps are distributed as single apps to the app stores. They have their own splash screens, icons etc.
The situation I want
I would like to create a single base app where users can sign in to their account. The base app will show their homepage with greeting and a list of apps (modules) that are available for install.
Lets say i’m an user and I would like to use the reservation app. In my base app I click on the reservation app icon and the app is installed within my base app and ready for use. If I choose to removd the app, it will be removed from my base app.
With this concept, users can use multiple apps from one single app and with one account (all data is written to databases and connected to their signed in account).
Let’s say I host all modules (apps) on azure or whatsoever, each time I upload a new ionic app to azure, the new extra module is shown in the base app as downloadable content.
Why do I want this?
It might happen, that in the future, I have over 10 applications. I own all these apps under 1 name. It would be much more user friendly to make them available to my users via one base app rather than having 10 or more apps in the stores for download.
Also, it would be much easier to expand the content each time. In stead of making a new build, upload it to the stores etc.
Why not build all the apps in one code base?
The app simply would get too big over time. Also, i do not want to make new builds each time and add them for review to the stores. Third, the users can decide what modules / apps they want to download in app.
I can not find an existing example. Is this possible and if so, what would be the first steps?
I have not tried anything yet.
Related
Here is a question on how to structure a web app based on react.
We are planning on deploying the front-end of an app that will contain several parts like main part, a customer account part and say a backoffice part for the company staff to track customer's data etc...
The plan is to deploy this app on Netlify and use subdomains like example.com, backoffice.example.com and clients.example.com.
My question is: shall we use a single React app to handle these 3 parts or use 3 different React apps ?
Initially we thought using 3 different apps would be better in terms of maintenance and evolution but any professional feedback with pros and cons would be appreciated.
Thx a lot.
We do something similar (but with Angular). It works well as each of the teams is responsible for their own app as far as maintenance and release cycles is concerned. It is pretty scalable as well - no problems to just keep adding new apps (as we are doing).
We have the whole lot behind NGINX, and so in the code we can just refer to simple paths like /client-services, /marketing and /sales - i.e. no server/protocol configurations.
You need to keep the following in mind :
How the apps interact with each other i.e. a standard data object, or cookies/localStorage
Authentication
You will be using app/internal routing for modules within your app, and external routing to redirect to other apps
We've been burnt before with one monolithic app...
This is the first time i'm working with firebase. My goal is to have a bounch of client apps (more and more over time), all of them managed by an admin app (One app to rule them all).
The thing is that the client apps have a certain content that needs to be updated from the admin app. My best approach is to create a firebase project, put the admin app there and adding client apps over time. I'have read that is possible to have an unlimited number of apps inside one Firebase project. On addition, someone told me to create one project for each client app and connect them to the same database somehow. I simply don't know what to do.
Which would be the best solution for my problem? thank you
firebaser here
A Firebase project can currently contain up to 30 app definitions. This is meant to support variations of the same logical application. For example, having an Admin app in addition to the app for regular users, and/or having an iOS, Android, and Web version of the same app, and for example having a free and a pro version of the app (if that is allowed by the stores where you deliver them).
Adding multiple apps to a project is expressly not meant to be used for white labeling apps, where you ship essentially the same app with different branding to different user segments, as you'd be sharing the backend services between them. For some backend services (such as database and storage) this is not necessarily a problem, as you can isolate the customers with security rules. But for other services (such as authentication and analytics) this is not possible, which is why this use-case is not supported.
If you need to define a separate app in the project for each customer, the only supported approach is to create a separate project for each customer.
I'have read that is possible to have an unlimited number of apps inside one Firebase project.
In that case please provide a link, so we can either fix it, or (if it's not in the Firebase documentation) leave a comment to clarify.
How do I move instances from one project to the next?
Problem: I have frontend production instance and backend production instance in 2 separate project. I would like to have my production instances (both frontend and backend) in the same project.
How do I move instances from one project to the next within Google App Engine?
You could have the 2 apps run as 2 separate services inside the same project. To do that you'd have to deploy the app from the project that will disappear as another service in the project that will remain. Some code changes might be required, depending on how the app is coded. Typically they're small changes, though.
IMHO it would be simpler to keep the project currently hosting the frontend and move the backend over from the project to be retired. The reason is that the frontend is typically better fitted to play the default service role and it is already setup as such, changes should be smaller. Performing the move in the other direction would mean both services would need to changed.
You might need a dispatch.yaml file to route incoming packets, unless the URL mappings of the services are really well done. Not a big deal.
If you're using custom domains, with a bit of care it is possible to make the move (almost) transparent - by having the new service up and running before retiring the old project. DNS propagation time becomes rather irrelevant - both old and new services being simultaneously ready during the transition.
Note: technically you wouldn't be "moving" instances, you'd just stop the ones serving the project to be retired and start new ones for the service added to the project to be kept.
More or less related:
Change runtime from Python to Go in App Engine standard environment
Can a default service/module in a Google App Engine app be a sibling of a non-default one in terms of folder structure?
Hi I am developing a social Networking app. I have an online heroku database where i can push and pull information. According to my research i would need to do this through a web service like REST and then retrieve the any info i want through JSON to my app; in a nut shell. My question is will I need to use android's Shared Preferences if I want to store a user's info like name,password,etc which would obviously be sent to my heroku database anyway. What is the point of Shared Preferences then?
There are a few reasons. These would include:
Unless you are going to make the user enter all his credentials every time he starts the app, you will need to store some of these locally (you could potentially avoid this by just keying off the device id, but what if the user has multiple devices?)
Save bandwidth. Local preferences (what things to show, theme options, which tab to start on), should be stored locally - especially if the user may have multiple devices which use your service. e.g. I might want my tablet to show a different default page on open to my phone.
Or can it be done?
For example, I want to help a few friends to setup their shopping cart websites. They have their website domain names already purchased. But I want to pay one google app engine application at www.mywebsite.com, and I want to "forward" their domain to www.mywebsite.com/friend1, www.mywebsite.com/friend2. In this way, I want their customers see their website which could be http://www.friend1.com, but they are actually served by one single app engine application.
In my application, I know how to get the path analyzed so I can go to datastore to serve diffrent pages, html. So the question is just how or can one google app engine be forwarded from different domains. Thanks!
I'm not quite sure what is your exact meaning of "forward", but I try to answer for different situations.
If you want the browser to keep displaying www.friend1.com all the way without ever showing www.mywebsite.com, you should have friend1.com setup as a Google App account, and add their domain into your application (just like you did for your own domain). This way, all traffic to www.friend1.com (or what ever subdomain they pick) goes to your appengine app. And your App should detect the domain of the http request and response accordingly.
If you just want a "redirect"... that means, user goes to www.friend1.com will have their browser auto goes to www.mywebsite.com/friend1 and displaying it in the URL bar , well, just setup one index.html page in www.friend1.com and add meta refresh header in the file. Or use any server side redirect method.