I am researching a project for a client that needs a custom web store build. I normally work with React.js front-end and Firebase (Node.js) back-end. There is a company out there called BrightStores that allows non-coders to build and deploy web stores with a nice admin dashboard for creating many stores and products for these stores. These stores are given a subdomain by default (clientstore.myapp.com), but you can pay more for a custom domain for each store (clientstore.com). Shopify, and other service providers have similar setups. My current React.js/Firebase setup has one code base, and stores are "hosted" with React Router on separate path names (www.myapp.com/store1) for each storefront. Where do I even start researching how to build a similar system of subdomains and custom domains within apps similar to Shopify and BrightStores? Any ideas on technologies for this setup?
Related
I have two independent App Engine projects to serve my REST API, one for my development environment and the other for production. I have the custom domain example.com and want to serve the development API at dev-api.example.com and the production API at api.example.com.
I can add dev-api.example.com and api.example.com as custom domains in each project and get the same list of A and AAAA DNS records for each (the CNAME obviously differs).
My two questions are:
Can I safely add the CNAMEs for both projects (dev-api and api) to the same DNS records?
Will App Engine be able to point to the correct project just based on those domain prefixes?
dev-api.example.com and api.example.com can be mapped to separate App Engine Projects.
You can add the same CNAMEs for both projects without any issues. GCP will be able able to route your requests to the correct App Engine Projects based on the Custom Domain config in your App Engine settings.
I'd like to get some advice on hosting solutions for my personal projects written with react and one WordPress website. Assuming I have domain named example.com:
Show WordPress on the root level, so when someone opens example.com, WordPress renders its homepage.
React website named First is available at example.com/first.
React website Second is available at example.com/second.
React websites should be able to handle their own cookies. Is this configuration possible at all or should I just use subdomains?
I currently use DreamHost for WordPress, for react websites I intend to use AWS amplify.
The most suiting thing for this I've found so far is a reverse proxy. After a few hours, the best I could achieve with AWS amplify is that it renders reacts as root website and opens WordPress at the subdirectory like /blog, so opposite of what I want to get.
DreamHost shared hosting doesn't support reverse proxies at all.
Should I move WordPress to a VPS or a managed hosting where I have full control over .htaccess and ability to use reverse proxies? Will the server with reverse proxy be required to be powerful enough to handle traffic for all websites or routing with proxies isn't a heavy task?
I need to share session between two web applications on different servers. My main web application is developed on ReactJS and some eCommerce stuff is developed on WIX. So, how can I use same session for both domains. I read lot of blogs and stackoverflow questions but not get any authentic and secure way to do that. Both web applications are hosted on different servers and using main domain i.e "example.com" and sub-domain i.e "store.example.com".
If HTML iframe is used in WIX site then session will automatically share between main domain and sub-domain. What I did for this
Created a separate component for header in ReactJs application.
Use the URL of that component in WIX site as iframe.
Sessions automatically share between for domain and sub-domain by
browser.
I am considering developing a platform in GAE.
for this to work I would like to be able to have run the same app engine instance run several 'sister' sites. This would be something similar to the way that the stack exchange sites work, so each 'sister' site would have its own users, data and theme (but may potentially be configured slightly differently - think different plugins used), but essentially would have the same function & format.
I would like to know if it would be possible to have each sister site have its own (customer defined) url, which would use the same app engine instance, and the app engine instance would be configured (by setting the site id and valid plugins for that site) depending on the url which was used to access it.
Yes, this is entirely possible. As Fox32 points out, you can use namespaces to separate different datasets. For domains, App Engine supports wildcard mappings, so you can map *.yoursite.com to your app. If you want to add custom TLDs, either you or your customers will need to create a Google Apps account for them, or add the domain as an alias on an existing Apps account, and associate it with the App Engine app - this doesn't require that they be admins of your app to do so.
You can use namespaces, to separate different websites, for many api methods. Take a look at the GAE documentation about it.
The Namespaces API is integrated with Google Apps, allowing you to use your Google Apps domain as the current namespace. Because Google Apps lets you deploy your app to any domain that you own, you can easily set unique namespaces for all domains linked to your Google Apps account.
We would like to develop and sell custom commercial GAE applications. I would like information on the deployment of GAE applications on arbitrary Google Apps domains (i.e. not appspot).
Suppose our company is abc.com and we are selling app to def.com and xyz.com. What are the steps to deploy our app on our customer's domain?
When an app is deployed on many domains:
Is the code duplicated or shared?
Is the datastore definition duplicated or shared (or more precisly the kinds)?
Any domain attribute add to the entity?
You have three options at the moment, when it comes to a 'multi-tenant' app such as you describe:
You can have a single app that your customers add to their domains. Your app will have a single datastore, but you can use the Host header to determine which customer is accessing the app, and segregate the datastore entries based on that.
Easy to deploy and upgrade
Easy for customers to install
Users have to have Google accounts, not Apps accounts, to log in.
You can deploy a fresh app instance for each customer.
Harder to deploy and upgrade
More customer involvement required to install
Provides firm separation of data
Users can log in with their Apps credentials
You can work with Google to create a new Apps Marketplace app
All the benefits of point 1 and 2, above
Requires Google involvement
No certain release date yet
This is possible but to the best of my knowledge, def.com & xyz.com will have to sign up for Google Apps.
Once the domain is registered with Google Apps by your prospective customers, they can add not only Google Apps like Gmail & Docs to subdomains (mail.def.com & docs.def.com) but also any GAE apps (fooapp.def.com).
Is the code duplicated or shared?
Shared
Is the datastore definition duplicated or shared (or more precisly the kinds)?
While the schemas (definitions) are shared, what isn't shared is the actual datastore. i.e. each instance of your app will have separate data.
Any domain attribute add to the entity?
You can figure out which domain your app is being served under using one of the CGI/HTTP environment variables. I don't remember which variable exactly but I'll update the answer once I look at some old code of mine. Once you find out what is the current domain, you can choose what to do with that info, including saving it to an Entity or simply denying access.
Another cool feature about this is that let's say company def.com is using hosted GMail and have Google Authentication for their employees. Now if your app is using the GAE provided authentication hooks, then you can automatically authenticate just their employees without any code change on your part! At least, that's the theory since I haven't tried it out myself ;-)