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...
Related
I finished a part of my project and bought a webspace with a domain and a database to publish on. So I create a React-Typescript project with followed structure:
API: has my controllers
BLL: the services
Question do I have to create a Build and publish it on the webspace, with the API, BLL... or only the Web component? So that the API, BLL... are on a seperate server and the fetches from the Web-Component are via IP:Port address?
What is the common way here?
The in and outs of web hosting is massively large problem space. And the strategies and approaches number in the thousands. I couldn't hope to do justice to that in a single answer. But in short, you probably want them on the same server, and you want your backend to deliver your front end assets to browsers somehow. And your frontend makes requests without a domain like /api/mydata/ to pull data from the same domain as the frontend. This question will likely get closed now, as it's way too broad to answer.
– Alex Wayne
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.
We have a running multi-lingual app hosted in Azure written in AngularJS. For managing some of the unsecured/public pages, we are looking for hosting another app with a CMS. So our app structure is would look something like:
App: www.example.com
CMS: www.examplecms.com
What we want to achieve is that dynamic content generated by CMS (different domain) for static pages be served using urls in www.example.com. Is it possible? We are primary targeting .net based CMS solutions but are open to other platforms. The static content is not too complicated.
Since the app supports multiple languages and most of the CMS solutions available offer multi-language support via subdomain.example.com or www.example.com/language/ directory structure, we want the custom url redirection to point to our app site (www.example.com).
Looking for suggestions you opinions or best strategies to work around this problem.
This Q is off topic, nether the less...
As you would essentially be running 2 entirely different web sites, yes everything would work just fine. The requirements are vague and very generic but any application/CMS could be setup in different domains and if you wanted requests made between them, allowing cross origin requests would allow sharing content/data.
Umbraco, like many CMS's supports multilingual sites using path prefixes as you mention along with any other method you are willing to write yourself.
I'm in the process of making an app for my assessment at uni using cordova/phonegap and was just wondering if its possible for me to use data from a my unis ecom website for my app without having any back-end access to it, so like images/prices/descriptions...synced to my app?
yes it is certainly possible, because Cordova means working via Javascript and a HTML5 Rendering Engine. It is with some reservations entirely possible to load data from an webserver and use it in an App.
The only thing is to ask, whether it is also a smart-choice. If you want your app not to break when the data from the website gets changed (see https://en.wikipedia.org/wiki/Link_rot )
Also the server can somewhat prevent access of data from contextes outside of the webpage, especially if TSL/HTTPS connection is offered and content is only available after authentication.
Yet anyway its the magic of Javascript to be very good in doing things with web/online resources and displaying HTML5. Cordova and PHonegap is hence imo much better than the very challenging JAVA-Dalvik and IOs native programming that one would have to use else
Likely not,
Google and Apple frowns on using apps as wrappers for websites.
Quote Google Developer Program Policies - Spam and Placement in the Store
Do not post an app where the primary functionality is to:
Drive affiliate traffic to a website or
Provide a webview of a website not owned or administered by you (unless you have permission from the website owner/administrator to do so)
And
Quote Apple iTunes Guidelines - 2.12
Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected
Context: I'm a beginner programmer, self taught in the hope of making a SPA. I've started with JavaScript, Jquery, PHP and MySQL, and now feel pretty confident with all. I've started with Ember, and am now moving away from having a PHP API to Node. Which has then brought me closer to Meteor... I'm aware I'll need to use Mongo instead, but having an integrated front and back seems to be sensible and have some advantages.
So my question is what are the advantages of having a separate REST backend API (eg Express) rather than an integrated front/back (eg Meteor).
One that springs to mind is that my app will be tablet/pc based, but in future I'll want a different mobile version, so I'd be able to use just use the same API. I'm conscious that the above question is the main concern with this stack question, but perhaps if a meteor developer could clarify whether this is indeed a concern.
Thanks in advance!
well for me you'll get a lot of advantages using a rest API, they are lightweight, extensible and overall reusable.
today it's a trend to use a vertical architecture that means having a RestFul service with a single responsibility, why because it scale better and it's easier to assign a team to an api, so that way you'll be able to manage several teams and apis in a very ordered way. This is probably how Twitter, wunderlist and other companies works, because it's a solution to scale better.
take a look to this talk by Raffi Krikorian he was the head of architecture of Twitter for a while is a little bit old but it worth every minute and to illustrate some of the advantages.
Also you can look at the diagram below, I did while ago it explains the differences between the MVC and API first type of architecture.
I've authored one rest app using angular and rest services and it has been a very nice experience to me there's no way back.
good luck
Meteor doesn't really "integrate" the front (client) and backend (server) as you describe. It still maintains them as two separate layers. The beauty of meteor (aside from the insanely awesome reactivity) is that it uses Javascript everywhere, instead of using JS on the client and some other language on the server, so you can use the same APIs on both the front and backend. Although Meteor does snazzy things like let you write client and server code in the same file, it still requires you to distinguish between the two, and server code is still stored only on the server and client-side code is still served down to the client.
Meteor is still young, but the developers and community are very active, and everything you described can be achieved with it at this point. I've been working with Meteor for about 6 months now, and it hasn't let me down yet. I'm working on a production-level application that also requires exposing a REST API for consumption in mobile apps, which I'm doing quite successfully with Meteor (I just updated a user profile using a REST endpoint from an Android device and watched it change in the Meteor app in realtime. So cool!).
I was using this great package, RestStop2, for building REST APIs in meteor, but it was unfortunately deprecated, so I released an updated version. Check it out for an example of building REST APIs in Meteor. It's available through the Meteor package manager: https://atmospherejs.com/nimble/restivus
So to answer your question, you always want to separate the REST API into it's own layer, but that is entirely possible with Meteor. To make it clear, you would never consume this REST API from within your Meteor app. Meteor uses DDP (not HTTP), which gives you a much more direct connection with your server, so you're doing something wrong if you're accessing data on your Meteor server from a Meteor client via HTTP. Of course, with Meteor, you have the advantage of being able to use existing code from your REST API.
There's a really good write-up that explains some of the considerations of writing a REST API in Meteor: http://www.meteorpedia.com/read/REST_API.
The design of a architecture separated in layers like frontend, backend (Rest Api) and DB, is for obtain a better a scalability, reusability and logic separator of features of the application. For example:
Today make a web applications separated in 3 layer (frontend, backend,
and databases), if tomorrow you wanna do a mobile application you can
develop the application like a extra project in the frontend layer,
but use all the features developed in backend. Then the frontend
application not need servers why run inside every device, but maybe
the load in the backend servers increase, and you only need add 1 more
server in the backend layer.
Its a little example, but is the most common case in this new era of mobile applications.
Remember always this in MVC architectures:
Frontend: Always call services from the backend, render the view, and capture data. Sometimes make a litle logic.
Backend: Receive the request, apply all the business logic, read and write operations in databases, and return a response preferred in json format.
Model: store data, backups, slaves, etc.
PD: If you use meteor in this example you gonna need to make a api Rest to develop the mobile application.