I'm looking for a solution for a bit of an odd situation. Let's take a quick look at the angular2-seed project so I can better explain: https://github.com/mgechev/angular2-seed/tree/master/src/client/app.
In that project, we have 3 isolated modules - about, home, shared. What I am looking for is a way to isolate development of these, so we're ultimately able to release each piece independently. For example, say Team A is working on the about section, and Team B is working on home. Work is complete for each, and we're ready to release, however we realize the about section is missing a critical piece of functionality, however we still want to release the change to the home section. What we're looking for is a way to achieve this.
Here are some solutions already explored, but I'm not really happy with:
Have completely different applications for home/about (in my eyes, this eliminates many of the benefits of a SPA).
Have each module (about, home, shared) roll up into it's own NPM package. When we go to deploy, we would have some way to orchestrate pulling in all the published NPM packages for these modules.
Orchestration:
Have each team build a component library (NPM) and pull those into a single Angular 2 application. That way, the teams can develop using microservices principles, but you can deploy a SPA monolith which reduces complexity.
Large component libraries should have multiple bundles and modules so you can be selective about what you pull in.
Communication between microservices:
If necessary, the component libraries can communicate over a back-end message bus.
If direct client-side integration is required between the component libraries, then you need a 3rd component library that about and home depends on, which contains a light-weight injectable message/event service. You can implement that service using RxJS Subjects.
A javascript meta-framework could work for you.
Here this interesting project
It takes inspiration from React component lifecycles by applying lifecycles to entire applications.
Some features:
Use multiple frameworks on the same page without refreshing the page
(React, AngularJS, Angular, Ember, or whatever you're using)
Write code using a new framework, without rewriting your existing app
Lazy load code for improved initial load time.
I hope it helps you to go in the right direction.
Related
Problem
Well, start with the problem at hand. Several systems support several functionalities, whether they are applications or pages, and most of them independently.
But for lack of planning, this system becomes a single and complicated project, being difficult to install or update.
The proposal would then be to modulate it, making parallel development, easy, and effective, since a change in an independent module would not impact the update of the entire system.
This concept is already well defined, but I am clearly looking for how far this is possible, and if it's worth it.
structure
The images above describe well what we intend to do in the system.
We intend to divide the system into independent modules, but that can share some things with each other, such as dependencies, interface design and global states.
Possible solutions - Pros and Cons
Here begins my question in question.
At the end of the construction of this project, we should have a system that can be developed separately for each module.
some solutions
Micro Front-End - React
Monorepo - React
Well, we know that there are several ways to configure a react project and launch it, and here begins another challenge.
Another important point is the generated build, it is interesting to keep the react pattern, in which several .js and .css files will be generated in a build folder, making it easy to launch it into production.
All modules would be using the same language (javascript) and the same framework (react).
Well, what would be the best alternative given this project scope? I read several articles demonstrating how to implement monorepo or micro front-end, but most were simple or didn't show the entire process, how to build etc.
A simple demo containing the above idea would also be interesting
I would go with monorepo approach specifically: https://turbo.build/
With this, I can have multiple packages in same repo as well as web apps at the same place.
I would structure them like this:
apps
- mainApp - App with module federation
- module1 - app hosted at /app1
- module2 - app hosted at /app2
- module3 - app hosted at /app3
packages
- app-container
- app-requests
- app-translations
- app-logs
- app-tracking
- app-state-management
With this approach, you can add more packages quickly and can have common utilities shared across multiple web apps. You can add multiple packages as your needs grow and quickly use them across the different web apps quickly specifically configuration-related things like sentry/datadog.
Later on, you can separate the apps and packages into multiple repositories if they get bigger and publish them as packages separately.
Additionally, you can have one main app that implements module federation and can use other apps independently deployed at their respective URLs. You can read more about module federation here: https://webpack.js.org/concepts/module-federation/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 months ago.
Improve this question
We have an large application spread across multiple teams, built with Java Server Pages. The goal is to migrate to Angular. A monolithic migration/launch was deemed not practical, so a gradual migration is preferred.
The idea is to use a Webpack 5 Module Federation app shell to load Angular micro frontend remotes into the existing JSP app. The question is whether to load the remotes as Angular apps or Web Components. The thought is that Web Components might allow them to embed a reusable microfrontend fragment into the JSPs in cases where they can't migrate an entire page at once, or they have components that will exist in both the unmigrated JSPs and the new Angular pages.
After the migration, they'll either keep the micro frontend architecture if it's justified, or abandon it and merge the remotes into one Angular app.
Another alternative might be lazy loaded modules rather than opening the pandora's box of micro frontend architecture. Just informally split the app up into lazy loaded modules per team. Downside here is possibly more teams stepping on each others toes in the repository, but that's no different than how they've been operating. Their concern about lazy loading modules is they don't think they'll be able to do something like this:
<!-- my ancient JSP site. LOL page load with every click -->
<JSP-header></JSP-header>
<myAngularComponent></myAngularComponent>
<script type="text/javascript" src="https://lawlcats.com/myAngularComponent.js"></script>
<JSP-footer></JSP-footer>
All in all, the proposed solution is incredibly complex. These teams are brand new to Angular and are already considering combining different frameworks within a micro frontend architecture, AND implementing web components. Sounds like a huge lift to me. I'm also unsure if they've considered how they'll manage the repository across teams.
Does anyone see room for improvement or flaws in this plan? I'd love suggestions for the micro frontend remotes being Angular vs Web Components, vs abandoning micro frontends altogether in favor of lazy loaded modules.
Well, it would be good if your team first fully grasped what are the implications of MFEs or WebComponents as tools.
Micro Frontends are self-contained, stateful, full-fledged, and fully black-box applications. Maybe it would help your team to think about them as iframes.
You stick a MFE app somewhere on your page, and that is it. It does its own thing. The host app just hosts all the MFE apps on all the different http ports, but it doesn't know anything about what's going on inside of them.
In the simplest classic example, there is no communication between the host and the apps, and the apps also never ever talk to each other. AFAIR, if you wanted them to communicate, it's theoretically possible to do that via http (since they do actually live on specific ports), or wild shenanigans like utilizing LocalStorage. But it's generally not easy.
WebComponents, on the other hand, are just raw components that do one specific thing. They are also black boxes, but usually super tiny and thin. You can think of them as something like input.
An input knows how it should be styled, it knows which raw browser Web APIs it should talk to, it knows that it should render text in response to the user typing on their keyboard, and how to expose a couple values and events to the external world. But ultimately, an input in itself is pretty dumb and can hardly be called an "application". It's just a small building block of the actual modern JS app.
inputs also don't talk to each other - why would they - but they expose clear, native html APIs for input and output, so the host app can very easily talk to them and make use of them. The host is still responsible for actually knowing how to do that though.
As for your use case, your options depend on your team's technical and business needs.
MFE Federation is a pretty strictly defined type of architecture. It might work in your use case, but you'll need to consider that trying to organize any kind of communication between these separate apps later on is asking for trouble.
On the other hand, if you really want to just have a bunch of modern JS components that you could stick anywhere in your existing JSP code, then WebComponents might be your best bet. IIRC, Angular components can be built and used as WebComponents like in your example, so it could be viable to write them in Angular (and then possibly migrate the entire app to an actual Angular SPA sometime later). The problem is that these components won't do anything by themselves, they still need the host page to actually use them.
It might also viable to write just one application with a bunch of lazy-loaded modules - which the standard straightforward case in modern Angular - and let it live under some specific routes. You would then just start rewriting pages in Angular one by one. Nobody likes that, but sometimes it's just what has to be done. As an upside, in that case at least you would have an actual modern Angular app as the host for all the JS components, instead of whatever JSP thing you currently have.
In theory you can mix-and-match approaches 2. and 3., with some pages only partially using the new shiny WebComponents, and some pages fully rewritten. It's probably what will have to eventually happen, but I'd try to initially stick to just 2 or just 3, to make the first steps of the migration simpler for your inexperienced devs.
Whether you choose Webpack MFE Federation, JS/Angular WebComponents, or a simple Angular SPA, I would strongly recommend looking into NX, which is a very powerful, framework-agnostic JS monorepo toolset. Among other features, it should help you solve the problem of managing the code between teams.
With NX, you can add arbitrary tags to all of your modules, and make the linter track and ban the dependencies between specific tags. As a simple example, your could say that modules tagged team-a cannot be used by team-b or team-c, so that Team A can safely do whatever they want in them without breaking anything that other teams actively use.
I am going to create a big application, SAAS type.
Laravel & Angular has been decided to be used in the project. But I am new to both of these as I am cakephp background.
Now I am trying to take this decision. Whether should I keep both angular and Laravel a completely seperate projects. where Laravel is behaving purely as an API Or should I mix these both. I have seen people serving angular templates from laravel.
I'll have a mobile application for the same later, so that's another thing I have to keep in mind.
I am not sure if that's ok to ask such question here but I'll still appreciate any guidance on this here.
I would recommend separating them altogether. In this way, your projects/repos only contain one "environment" or context, which in my opinion makes everything cleaner. It also helps reusability, in that your API becomes completely app agnostic. You can of course still serve them from the same server.
Separating the components also make them easier to test in CI, because you'll only have to test one component at a time.
I'd recommend versioning the API, especially during early development, so that versions of the app can target a specific version of the API. Developing "API first" in iterations minimizes problems with compatibility between the two components as long as there are few breaking changes from the API side.
I'm studying a bit of ember and I like it so far. The problem I have with ember (and most frameworks I saw, both server and client side) is that almost all tutorials and guides are designed for small apps (as TodoMVC). I'm interested about how to handle huge administrative apps (like 30 or 40 pages, or more). That reason made me go for framework-less apps many times. What I saw is that you can use Yeoman or another tool to build a single js file and html. Most people focus in how to split the code in development and it's okay. I want to ask you how to divide the code that is downloaded at runtime. I think (maybe I'm outdated) that the users of administrative apps don't have to wait for the load of the whole app. They use 4 or 5 pages of the whole stack most of the time. I read briefly about require.js but ember doesn't advocate using it. What I need is a way of lazy load templates and javascript code like routers, controllers, etc.
How do you guys manage apps like those I mentioned?
There is a great blog post from #mixonic on this topic. It explains how you can use a before hook in the router to lazy-load scripts for one or more routes in your application. This technique can be used to lazy-load any application code including routes/controllers/models/templates or third party libraries.
http://madhatted.com/2013/6/29/lazy-loading-with-ember
I have begun to play with Knockout recently and I must say it is truly awesome and the power that it can bring to web applications.
However now I want to do something real world and architect my solution using Knockout. Eg. How should my viewmodels be initialized. Where should they go? I am mainly targeting single page application. So, I am interested in architecting single page applications mainly.
There are a lot of pieces to the puzzle, but here is a short list for me.
DISCLAIMER: I'll make some assumptions about your app too, so some of it will vary. Also, this is just one way to do it. There are may good ways. But this should be a good starting point for you.
Assuming your app is a set of abut 5 main views in a SPA:
Create a master/shell html page to house the app
Create a view / partial page (html) for each view. Each view is hidden til you navigate/route to it.
Create a viewmodel that can be bound to each view Create a
bootstrapper.js that kickstarts everything.
Bootstrapper should crank up any routing engine you use (sammy, history, etc)
Bootstrapper will bind the views to the viewmodels Bootstrapper can
also crank up any seed data and state for your SPA
Tip: Use SoC. Have your viewmodels be models for views. Don;t have them do routing, ajax calls, ui manipulation, etc. Have separate objects for other functions. DRY, KIS, SoC ... all good stuff :-)
I use the Revealing Module Pattern for creation of my viewmodels, though standard Module is perfectly fine too.
If you ave a more specific question, happy to answer that. I tried to keep this short cuz in truth it's not a 5 minute answer. In fact, I'm writing a course for Pluralsight on one way to do this coming in August 2012 :-)
For those who need an updated alternative (2015)...
Another option (and a very good one) is to use Yeoman to scaffold a single-page-app for you as described in Steven Sanderson's blog here
It does all the architecturing you need for you so you can concentrate on writing code. Try best to harness the re-usability of the knew knockout component feature - it's amazingly described by Steve Sanderson so I won't take away the glory of his well done work.
I just open-sourced the mini SPA framework I put together with Knockout being the major component.
knockout-spa
A mini (but full-fledged) SPA framework built on top of Knockout, Require, Director, Sugar.
https://github.com/onlyurei/knockout-spa
Live Demo:
http://knockout-spa.mybluemix.net
Features
Routing (based on Flatiron's Director): HTML5 history (pushState) or hash.
Highly composable and reusable: pick modules/components for a page in the page-specific JS and they will be auto-wired for the page's HTML template
SEO ready (prerender.io)
Fast and lightweight (85 KB of JS minified and gizpped)
Two-tier bundle build for JS for production: common module that will be used by most pages, and page-specific modules that will be lazy-loaded
Organized folder structure to help you stay sane for organizing and reusing JS, CSS, HTML
Using Knockout 3.3.0+ so ready for Knockout's flavor of web component and custom tags (http://knockoutjs.com/documentation/component-overview.html)
All documentation are in the major dependencies' own homepages, so that you don't need to completely learn a new framework
Knockout http://knockoutjs.com
Require http://requirejs.org
Director https://github.com/flatiron/director
jQuery http://jquery.com
Sugar http://sugarjs.com