I’m currently evaluating Meteor as a new development platform for our organization. We have a large, monolithic PHP application, which from a user perspective is really several separate apps in a single dashboard/portal style layout.
My team wants to begin rewriting portions of our app into separate applications (hopefully using Meteor, as we need real time updates and alerts). The end goal would to have our legacy app rewritten as four Meteor apps, each accessible through a single login and set of tabs. The tricky part (aside from the common login) is that alerts from one app must be visible when the user is in another app (either in the header or in ‘tabs’ as illustrated in my cartoonish mockup).
A second issue is how to serve the first few Meteor apps that get created in parallel with our existing PHP application. Since we are rewriting the app piecemeal, we would need the PHP ‘dashboard’ to include Meteor apps as they replace eventually functionality once provided by PHP.
The attached image shows what I’m trying to do. Basically there is a single header which shows the user and company logo, alerts from any of the ‘apps’, and tabs to switch between apps. Is this possible? Any recommendations?
For that you could use the same DB, sharing at least those collections that contain those notifications, and they’ll be “cross-app” instantly.
And there are alternatives, too:
a) Pass messages between the apps like you could between any apps, using some “messaging system” (message queues etc) and have a dedicated “notifications” collection in each app that is updated with each of those messages.
b) Have the browser connect to multiple DDP servers, i.e. to each app’s Meteor server.
(I’m sure there’s other ways, too, but I think those should provide the basic ideas – either share state or exchange messages.)
Ideas…
Replace the pieces of the PHP app tab by tab, so that you replace the tabs one by one with a Meteor app each. In every Meteor app keep the outer layout as if the user were still “inside the PHP app”, while allowing SPA-style interaction within that tab. Once the user clicks on something that’s outside that app’s responsibility they get directed back to the PHP or one of the other Meteor apps.
As you replace more tabs with Meteor apps you could just keep it a single Meteor app, actually, just developing functionality in packages (or at least developing with packages in mind, and only creating packages once the functionality is mostly done, for now) and keeping things modular and pluggable.
But you’ll have to know what’s best in this regard, because obviously I lack perspective on what exactly you’re trying to accomplish in the end and if trying to somehow integrate 4 apps in a single UI really is the best way to go about it.
It might be much easier to develop things separate and in packages, and then just gather all packages in the “portal” Meteor app and deploy them as one.
All the “portal” solutions that I’ve seen in other languages and frameworks tend to be not very intuitive and very messy, and I never feel like the usually much worse UX is actually worth whatever other benefits you might gain from those “portal” solutions.
It still depends on the usecase and expected load etc…
If you need scale different functionality in separate services, it should be detached to it’s own meteor instance.
To use different Meteor instances, you have 2 options in general - DDP (so you can call methods provided by that given instance) or Oplog style (when you dont use direct method calls, but observe changes on collections and react on them by some action, for example some computation).
In that 2nd case - oplog, you can create 1 frontend app which interact with users and than all the backend/data crunching delegate to separate meteor instances.
@seeekr and @shock - Thanks for the reply! Very helpful.
The backend ideas make perfect sense. In regard to scale, these will be internal use apps for our organization. Perhaps a few hundred users at most, with a few dozen connected at any given time. I like the idea of shared state and will dig into the differences between DDP vs Oplog for tracking changes between apps.
The idea of using modules rather than separate apps also occurred to me after I posted this. My other plan was to build a Node API, then have a ‘Portal’ front-end app that pulled in different ‘tabbed apps’ as npm modules (from our own repos). It sounds like a similar approach can be taken with Meteor. Our goal really is to break up our monolith codebase into smaller, more maintainable pieces.
I’m going to keep reading, but I still cant figure out how to serve all the front ends on the same page with multiple instances of Meteor. Modules pulled into one app seems to be the way to go unless I find a better solution.
In Meteor terminology “modules” are called “packages”. “Modules” usually refers to either nodejs/commonjs modules or in the future to ES6/ES2015 modules.
What bugs you about pulling everything into a single app for production deployment?
Different developers (or teams) could develop the individual pieces completely separate from each other, as their own Meteor apps, and not have to deal with other devs/teams while they’re developing.
So in the end there would be:
4 different “development” Meteor apps, with all functionality in packages, specific to each app.
1 “combined”, actual Meteor app that would get deployed to production (and testing etc).
Some core packages that are shared between all apps / depended on, providing: base layout, accounts functionality, and anything else that is shared between all apps.
Unless there comes along a way to easily render a Meteor app on the server and then “rehydrate” or “mount” Meteor onto that initial HTML inside an otherwise existing app structure, I can’t think of a good way to “merge” multiple Meteor apps in a straightforward way into a larger overarching application.
In times of server-side rendering you could pull some tricks with proxying servers and thus pulling HTML content into various parts of your page. But Meteor requires being live and active and fully working and “in control” on the client side, so… oh, wait a minute. Well, it would still be possible to just server-side render its content (with some effort; using phantomjs etc) and pull that into an overarching structure, but then its nature would be lost, it would not be live and reactive and properly functional…
Just thinking out loud, for the most part. Maybe there’s something in there for you, maybe it helps you think.
@seeekr Thanks once again for your reply. I guess my only argument against using packages at this point is a slight possibility that one of the tabbed apps might be taken out of the portal and spun off into a saleable product. However, if Meteor packages work anything like npm modules, then we could potentially refactor the tab package into a standalone instance, and include shared ‘core’ packages as dependencies.
And yes, I’m kind of thinking out loud right now, too, so no worries this is all very educational. I think you’re right, and a series of packages pulled into a single Meteor instance is the way to go.
this is all very educational. I think you’re right, and a series of packages pulled into a single Meteor instance is the way to go.
