I’m developing web applications using Meteor & React.js. I need your advice.
The question is: how can I build a very large single-page application on Meteor?
I’m faced with problems such as performance, the weight of the js and css files (I have a lot of components).
Are there ways to separate components and load any components only when necessary (when the user performs any actions)?
There is also an idea to create a single-page application that will have several sub-applications separate from each other. For example, the user clicks on the icon of the sub-application and in the main block “content” opens the sub-application and it all happens inside a single-page application.
The idea is that each sub-application is hosted on separate servers and has an individual database, backend and frontend.
Is it possible to do this with an iframe or is it a bad idea? It is important that all these sub-applications can interact with each other through the parent application.
You can definitely leverage code splitting to help with load times, etc.
Regarding the “sub-applications”, these seem like implementation details. What are you trying to accomplish at a higher level that lead you to start thinking about these things?
If it is “important that all these sub-applications can interact with each other”, why start off by putting them in silos?
A lot of this will depend on the front-end library of your choice (pretty easy with React though).
With React there is react-lodable (in conjunction with styled-component if CSS is a huge issue) that alleviates most of the issues with code splitting and bundle size. Check out this post: https://blog.meteor.com/meteor-1-5-react-loadable-f029a320e59c
Sub-applications must be disabled on first launch and will only be enabled when the user has opened them. They should be separate because it is easier and more convenient to implement in my opinion, we will create new sub-applications and connect them to the parent application with the release of a new version. The sub-applications must be separate from each other, and they will only communicate through the parent application through the API.
I have implemented Iframes in my meteor app to allow integration of old applications into a new app using angular and meteor. Don’t be fooled into thinking this is easy and what iframes are designed to do. Modern browsers do pretty much everything in their power to prevent them from being workable in practise.
The other area that needs to be addressed are altering the old apps so that the iframe navigation is disabled and pretty much making the old app look like they are just a page in the new spa front end.then you have to think about how you would navigate between iframes.
At best, I would say using an iframe does just about work but given any other choice I would not use them. It pretty much breaks most of the built in browser navigation and you have to invent other ways of navigating between pages.
If I was you I would be looking at trying to design the spa front end to be modular so that your sub apps could be loaded directly into the spa front end using a code splitting technique. Time spent in this area is probably easier than swearing at iframes for the rest of your life hoping that the browser doesn’t break iframes for security in every update.
Why don’t you use singe sign on and common ui semantics so that the applications look like they have the same master layout and navigation?
Consider google apps, you can switch between google apps on the top right, they all share the common ui feel and primitives and logging in anywhere gets you to login everywhere.
This is perfectly achievable with meteor. I’ve already done it with different apps and even one for a multitenant saas app where users can generate new subdomains on the fly and hit a specfic app to serve that domain. You can do all kinds of things as long a you can carry your login across and make the ui similar.
And yes, iframes are going to cause you much more trouble than they solve.
Yes they are going to be separate because I thought you were asking about how to put some of the apps in separate servers to begin with.
Ideally, the “common” ui codebase that you need to share across different apps should be very small. But if you want that to be fully shared, too, what you can do is toy around with the idea of combining dynamic loading and fronting your app with a cdn that is capable of rerouting requests to some common html/js/css/image assets to a single source.
Frontend: create-react-app with apollo-client, styled components, react-router etc… use zero meteor code on the front-end, just connect to the graphql endpoint. Host it on netlify.com at like www.myapp.com.
Backend: meteor + apollo + mongodb on the backend. Use all mutations/queries. You can use apollo-meteor-accounts package. Host it on galaxy.com at something like https://api.myapp.com and have your CRA front-end looking for https://api.myapp.com/graphql. You can spin up as many front-ends as you want, host them wherever, and point them to you meteor backend.
People knock galaxy’s price, but I spend 0 hours on devops. Say your time is worth $30/hr… you can host it on galaxy for $300/year, or pray you don’t have to spend more than 10 hours rolling it from scratch and then maintaining it yourself (more than likely your home spun DIY will take10 hours of your life throughout the year).
Future: If this was a little further along, https://github.com/accounts-js/accounts, you could just use that with a vanilla express back-end. But, it seems like the mongodb + graphql connector is still being ironed out. So, a simple meteor back-end that uses very little meteor is a good bet for now.