AngularJS websites: single SPA vs multiple SPA apps/components [closed]

Question

This question has been bugging me for some time now.

If you are building a website with multiple functionality using Angular, is it better to build a huge SPA or break down the website into functional "apps" and build an SPA for each app?

For example, we have a social media website with notification feed, user profile, reporting, and groups. Would you build all these features into a single SPA, or build 4 different SPAs and let a backend framework route to the correct SPA?

e.g.

www.mywebsite.foo#/profile/12345/education

vs

www.mywebsite.foo/profile/12345#/education

I'm personally more in favour of the latter method because it reduces the size of the apps, but it does require the page to reload when navigating between apps.

Answer 1

Mark Collings has talked about a thing at your article:

https://markwillcollins.silvrback.com/7-things-i-wish-i-knew-about-angularjs

"3. Structure is critical..."

He suggests to plan each page before init the job.

And then, I believe, you will discover what best approach for your specific need.

I prefer to isolate in small services, because I don't see advantage to share small bits of javascript in a complex hierarchy of load, using require.js or similar approach.

Answer 2

So, here's what I learned and what I did:

My server has a default route:

  var express = require('express');
  var router = express.Router();

  ... 

  router.get('*', function(req, res) {
    res.sendfile(path.resolve(__dirname + '/../../../build/index.html')); // Send index.html for HTML5Mode
  });

  return router;

So, I can have multiple SPA's on my site, because I just send different html templates for them. An HTML5 style app will need to pick a default app like above.

What belongs in a single SPA?

All the state that is inter-related in the user experience. It will be complicated to share state between apps (e.g. authentication). Of course, they can all access the full state of your server.

When is it useful?

If you have mockups that show clearly different use cases e.g. two kinds of users with different logins. Or two different 'places' they'd login.

What's to be gained?

• If you're "dashboard" app loads a bunch of graphing code, but your "landing page" app doesn't need it, you can make a better experience for end users.
• If the user experiences are different, storing the different code in different places is easier to manage.
• In my case, there was also a SEO benefit rendering "landing page" templates on the server.

You might not know what you really need till you try it out. So I'd recommend collecting everything that depends on a login into the same app. And the default app should include the 'anonymous visitor' experience.