Architecture of a meteor application with 2 distinct UI's

1

An application I’m building has 2 fairly distinct UI components.

There are several option’s

Shared Server
The frontend components would both connect via DDP to a single server in order to get the data.

One application
Don’t split the application.

What suggestions do you have to avoid future headache’s due to architecture.

2

Generally use the simplest thing that could possibly work right now. I don’t see what headaches you’d run into if you were to actually split stuff up down the line.
But initially it would just be a whole lot more work to write and keep in sync all kinds of packages for all the shared stuff that’s going on on server and client.
By comparison it’s much easier to just define 2 distinct UIs with their templates and routes, and you’ll probably still be able to reuse lots, like many helpers, because the data will generally be very similar etc.

3

How would you recommend cleanly switching between the 2 UI’s?

4

Just choose 2 distinct path prefixes in the url and then organize your files in client/ accordingly as well. Such a requirement actually comes up fairly often in projects, where there’s part of the site available for everyone (users) and a different portion for the site owner(s) (admins).

Structure e.g. like this

client/
  -- public/
      -- templates/
      -- stylesheets/
      -- lib/
  -- admin/
      -- templates/
      -- stylesheets/
      -- lib/

with url prefix “/public” for the one UI (or just “/”) and “/admin” for the other one.

Does that give you ideas? Or did you mean something else by “switching between the 2 UIs”?

1 Like
5

To begin developing an app, without caring much about the performance overhead of loading anything and everything required for both UI’s up to the client on the first run, the most annoying problems usually boils down to CSS modularization and collisions.

If the two distinct UI’s don’t share a common CSS framework, the collisions begin appearing rather early on, otherwise, they may also be subtle CSS related UI bugs due to the separation later on when you find out part of your CSS rules may actually be working because of some other rule from the other UI’s CSS base.

But apart from that, template, layout and helper/event code can already be very easily kept separate in a modularized folder structure.

2 Likes