File organization and structure of mobile & web app

Continuing the discussion from Structuring Cordova + web app:

Hi, newbie here. Apologize for the length of this post in advance or messing up any tech details :smiley:

We are planning to build a B2B SaaS application using Meteor that has the following requirements and I’m looking for feedback on how to best structure the application and file layout. I’ve also read the the topics listed below as they are related, but still not clear to me what is the likely best approach.

We will have a Cordova/Meteor app that is integrated with phone features such as GPS, contacts, maps, etc. We would like to support hot code pushes to mobile app without going through app store. Users should be able to register and login to our system from the mobile app. Assume UI is built with something like Meteoric. This is the primary way users interact with our system.

We will have a web version of the app that supports a slightly different set of functionality like admin and analytics type features (let’s assume 60% functional overlap with mobile) and will have different routes and UI flow than mobile app. If a user tries to access the web version of the app at http://app.company.com from a mobile browser they should be directed to download the cordova mobile app. Users may register and login to our system from web app and both apps should share the same DB. Assume the web app UI is built on Bootstrap or Semantic UI or the like.

In addition, we will have a static B2B website at http://company.com and blog at http://company.com/blog and in the future maybe a few other static CMS pages. Our original thoughts were to use a CMS like Wordpress for this part of the site and Meteor for our app. However, we would prefer not to have a completely separate code base and not muck around with different language, UI, etc. Also, looks like some nice packages to add blog/CMS GitHub - orionjs/orioncms: [Old] Orion is an open source framework built on Meteor that makes complex as well as simple apps possible with minimal effort. and GitHub - meteor-blog/meteor-blog: Gives you a basic, out-of-the-box blog at /blog

The CMS would be accessed by marketing folks to change copy, do landing page a/b testing, write blog posts, capture leads, etc. We would have admin roles/users set up to access the CMS. In fact, static site could potentially be on separate DB from mobile/web apps as when a user wants to login/register/use web app they will do so from http://app.company.com. Our concerns with static website are load time and SEO. We would probably prefer not to load entire web app when someone first comes to our site as most visitors won’t be registering or logging in on their first visit.

Therefore, any feedback from experienced users on the following proposed file structure or other thoughts on how to deal with our specific requirements? Thanks so much!

  • ourapp
    • web - Meteor application 1
      • client - Web specific client
      • server - Server code which works with web and mobile client
      • lib - Lib code which works with web and mobile client
    • mobile - Meteor application 2
      • client - Cordova specific client
      • server - Symlink of ../web/server
      • lib - Symlink of ../web/lib
    • staticweb - Meteor application 3
      • client - code that can runs on desktop or mobile browser
      • server - Server code which works with desktop or mobile browser
      • lib - Lib code which works with desktop or mobile browser

OR should we combine static web and web app in one application folder?

For the static site, you might consider going with another platform.

I’m also looking into structure my app. Having a separate web and mobile app seems to make the most sense at the moment.
One thing I’m confused about is the mobile app that uses the web server. How does the mobile site get updated? Do you need to have two server apps running? With the mobile server merely serving the client files?

Ah. You use the --mobile-server flag to connect to another server.

Did you decide on a solution?

I’m grappling with this design issue at the moment.
I’d prefer to use meteor for the SaaS website as well, but unsure of the mechanics as mentioned above.

Initially I’m just going with a web app for mobile (native later) and the main website.
But even with a web app it seems most saas switch to a subdomain app.website.com when the user logs in, and back to the main website.com when logged out.

I haven’t come across any meteor examples of this.

We are focused only on mobile app development right now so have deferred the decision. Most likely web version of app will be a separate meteor app with symlinks to /server and /sharedLib directories and we will use --mobile-server flag when building mobile app to point to the same production server we use for the web app.

1 Like

I’m trying to avoid the app store review process, at least initially.
Shipping multiple Unity apps through there has given me sever review process fatigue;-)
It’s not super complex so I think I can get away with it.

Most likely web version of app will be a separate meteor app with symlinks to /server and /sharedLib directories

Could you explain this a little more, or point me to a link?

ty

Edit:
Found some good discussion here:
https://groups.google.com/forum/#!topic/meteor-talk/ku7kvNJp8ek/discussion


What’s the latest on this @skirunman? What Could you share what you folks finally did with the design?

Timely question. We are still focused primarily on our cordova mobile app, which uses Blaze/Meteoric for the UI. We started moving to a Meteor “all package” approach , but this was about the time Meteor 1.3 was announced with support for ES6 modules and import/export.

Right now we are in a major refactoring of our app to move to Meteor 1.3, React, and ES6 modules. We have not yet settled on a final directory structure for our apps, but we are taking inspiration from both Mantra and Meteor Guide v1.3, but we are not really happy with either approach as is.

Our requirements are that both mobile cordova and web app talk to the same server and users can authenticate across both clients. Our client apps use different UIs, but share about 60% of the same business logic.

Mobile and web apps are currently being built as separate Meteor apps, but in the same git repo for now. We share server and common/lib code using symlinks between the two Meteor apps. We still have Meteor packages for shared code between the two apps using a common local /packages directory using PACKAGE_DIRS . We are not sure if we will update the Meteor packages or move code to private NPM packages or just use shared imported modules.

Bottom line is things are in flux and we are still testing what is going to work best for us in the long term.

Interesting. Thanks for the links. The Meteor 1.3 guide specifically. It is
very similar to answers from devs across the 'net on this question, but
it’s great to have it all summarised in one place :slight_smile:
skirunman forums@meteor.com schrieb am Fr., 11. März 2016 um 02:40: