Hello !
Today I need your help ! 
I’m currently working on a CMS for meteor (basically a WordPress-like).
I have a simple question about the design of this CMS.
Should I divide my CMS in two application :
-One part for the viewed content (site, template, viewer plugins) -Another one for the administration part (statistics, web mastering, post and page creation, etc)
Or
Should I make an all in one application using different routes and security levels.
From my point of view both have pros and cons.
Divide :
- Share the CMS between several servers.
- Possibility to manage different websites with only one administration application. Looks like a network.
- Using administration without the viewer app.(Headless Drupal)
- Using the full meteor potential for big application.
All in one :
- Smaller application, template more adapted to the administration panel.
- Easier to handling it.
- Blog oriented.
I’m really interested by your ideas and opinion.
Thanks.
As you mentioned, both approaches have their pros/cons, so it really comes down to your specific requirements. One more thing to add to your list however; If you develop both the public site and admin site as one combined application, you’ll be sending the client code for both sites to anyone accessing the system (public or admins). This is because Meteor doesn’t currently support code-splitting - all client JS code is bundled and sent down the wire, no matter which part of the application you’re accessing. This might not be a big deal, but if you have a fairly sophisticated admin, with lots of reporting capabilities, graphing functionality, etc., you might be needlessly hitting your public site users with a large javascript payload. If you’re interested, take a look at the Building an Admin App as a Microservice with Meteor.js article that @joshowens put together a while back, for a really simple approach to maintaining 2 separate apps while sharing the same database.
5 Likes
Thank you for your answer
I will choose to split my application in two part.
Lot of feedback talk about the non code-splitting of the framework.
And you are right it’s an important point.
Apologies on jumping in, but can you explain code splitting a little bit. I think i’m missing something pretty basic.
Isn’t the whole point of modules and import { package } to reduce the amount of code that goes down?
Thanks so much,
tat
In fact when you make import in your project they are not imported separately but all at the same time.(When it’s done it’s call code splitting). By example if you make a page home and contact with different imports they will be imported in both.
Yes and no.
In pre 1.3 (pre ES2015 module support) Meteor, all javascript code in your application (that isn’t marked as being server side only) is bundled and included when someone loads your application client side. This means that if you have javascript files included in your application that aren’t being referenced anywhere, they will still be bundled and included when someone accesses your app. This is what many people refer to as “eager loading”.
In 1.3+ Meteor, you can still follow this eager loading approach (for now anyways), but you can also use the newer ES2015 module based “lazy loading” approach. This means client javascript files stored under the /imports directory will not be automatically bundled and made available client side, unless they are referenced somewhere in your app via an import. So if you have a bunch of javascript files stored under /import that you don’t use in your application anywhere (don’t reference via import), they won’t be included in your client side JS bundle. So in one sense yes using modules could help reduce the amount of code sent over the wire to the client.
What isn’t currently supported with Meteor however, is the option of only sending code down the wire to the client when it’s actually needed. So let’s say you have a public site made available via a route of /public, and an admin site made available via a route of /admin. Let’s say you’ve built a monster reporting module for the admin side or your application. Ideally you wouldn’t want people accessing the /public side of your application to download the admin reporting module.
Some tools allow you to split your codebase up into separate chunks of functionality, that are only loaded when they’re actually needed. Webpack does this for example. Here’s a quick snippet from their docs explaining this further:
For big web apps it’s not efficient to put all code into a single file, especially if some blocks of code are only required under some circumstances. Webpack has a feature to split your codebase into “chunks” which are loaded on demand. Some other bundlers call them “layers”, “rollups”, or “fragments”. This feature is called “code splitting”.
It’s an opt-in feature. You can define split points in your code base. Webpack takes care of the dependencies, output files and runtime stuff.
To clarify a common misunderstanding: Code Splitting is not just about extracting common code into a shared chunk. The more notable feature is that Code Splitting can be used to split code into an on demand loaded chunk. This can keep the initial download small and downloads code on demand when requested by the application.
Just to clarify: in reality this is never the case, since if you don’t intend the clients to have the code, you simply don’t write it.
Actually, package authors can write good-to-have features which will only be sent to clients if you explicitly import them. If this actually has been practise yet I don’t know (last time I mentioned it I was encourage against it).
@hwillson/@Peppe_LG - thanks so much. I understand it now.
I am using the imports modules strategy, so pretty happy.
Tat
While usually true, I just came across an app that had a large utility library stored under /imports/utility, that wasn’t actually used in the app. Some lazy dev named @hwillson forgot to remove it during a recent round of refactoring …
1 Like