Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
Hello I am learning micro front end architecture. Consider I am working on e-commerce application where I have four verticals - Home, Account, PLP&PDP and Cart&Checkout.
My understanding is that each verticals will have their views, actions, reducers, sagas, store. Here we will have 4 redux store.
My question is there are couple of things like user profile reducer which might be useful to shared across all these micro front end apps. Here using 4 redux store is good idea ?
What is the correct way to handle this in react web app ?
There is no standard template solution for your question, its all need based. I am sharing how I worked on similar project structure and converted large monolith to Front & Back end micro services. FE is developed using different technology mix of Angular, React and Vue. We are using https://single-spa.js.org/ for management of different modules and created a parent app(container) in React and child frames as separate app using Angular and Vue. Data sharing management is done using mix of cookies/local storage and redux. Sharing of data between child and parent app is using Post Robot https://github.com/krakenjs/post-robot. We are running this structure in production from last 1.5 years and it is scalable solution.
In my experience your better off having one redux store that it managed at the framework level of your micro frontend that is namespaces for each of your micro applications. As each app is loaded in it can dynamically load in reducers, middleware and data.
The reason for taking this approach is that you will inevitably end up with some data that needs to be shared between different micro applications and this is much easier when you have a single store.
Check out this project from Microsoft that makes this a pretty simple thing to do now.
https://github.com/Microsoft/redux-dynamic-modules
Their are a number of other solutions to load different things into your store dynamically
https://github.com/markerikson/redux-ecosystem-links/blob/master/reducers.md#dynamic-reducer-injection
You have rightly divided the micro-frontends into Home, Account, PLP&PDP and Cart&Checkout and these will have their own store which will allow you to maintain them separately.
However, the catch is that they should be making service calls separately and maintain their store for that.
Now this way, the userProfile will be irrelevant to the Product Listing Page and Product Details Page. Same case with the Cart and Checkout Components. They might require a token to make some API calls, but that value can be fetched from the localStorage.
The other alternative would be to have a single Store and pass in functions to the respective micro-frontends for the actions. However, that complicates your application and moves towards a monolithic approach , defeating the purpose of a MFE architecture.
Refer to this link to checkout the basics
https://martinfowler.com/articles/micro-frontends.html#Cross-applicationCommunication
As a side-note, using Custom Events is also effective when it comes to communication between MFEs but that is preferable in cases where there is a large set of interactions required between projects.
Refer:
https://developer.mozilla.org/en-US/docs/Web/Events/Creating_and_triggering_events
If some of your redux stores needed to be shared across your application, then just create a seperate package out of that redux store using monorepo with yarn workspaces.
You can install that store as a seperate package and just use it by defined package name.
For more on this topic, please have a look at this Yarn Workspaces website.
https://classic.yarnpkg.com/en/docs/workspaces/
Also, using 4 redux store is not that bad as long as your micro frontend is supposed to be a self contained application in itself. But if the data is being used across all of your micro frontends then create a single store for single source of truth.
//add the code in componentdidmount where you want to receive the data
window.addEventListener("event-name", (datarecieved)=> {
console.log(datarecieved.detail);
}, false);
//Create an event to pass data
let send-data = new CustomEvent("event-name", {detail: "Hi Suraj here"});
window.dispatchEvent(send-data);
Pass data all across your mfes as when required in Home, Account, PLP&PDP and Cart&Checkout.
Up to my knowledge, Micro front end Architecture (MFeA) should not have any dependencies with other part of the page, it has to work independently.
Basing on that, backend service has to send the necessary information to the UI.
For user Information you can use Session and get the corresponding information from that.
For managing the User profile, it can be another MFeA module.
Related
We are looking at options to build the front end of an application we are creating and are trying to evaluate a tool that will work for us and give us the best platform to move forward.
This is a Node.js project. Our initial plan was to use Express and go down that route, but we decided that before we kick off this stage it might be best to review what is out there. Our application has several areas which we don't believe fit the single-page model in that they are related from an application perspective, but not from a view one.
We have seen a few of the frameworks we could use to build out the client like Backbone.js, Meteor, etc. and also AngularJS.
This may be a fairly obvious question, but we cannot seem to decipher if AngularJS is purely for single-page application or it can be used for multi-page applications like Express for instance.
UPDATE 17 July 2013
Just to keep people in the loop, I will be updating this question as we go through the process. We are going to build everything together for now, and we will see how well that performs. We have reached out to a few people who are more qualified with AngularJS than us and posed the question regarding splitting up larger applications that share context, but may be too large working on a single page.
The consensus was that we could serve multiple static pages and create AngularJS applications that work with only those pages, effectively creating a collection of SPA and linking those applications together using standard linking. Now our use case is very specific as our solution has several applications, and as I said we are going to try the single code base first and optimise from there.
UPDATE 18 June 2016 The project fell of a cliff, so we never got round to getting too much done. We have picked it up again recently, but are no longer using angular and are using React instead. We are still using the architecture outlined in the previous update, where we use express and self contain apps, so for example, we have a /chat route in express that serves up our React chat app, we have another route /projects that serves up the projects app and so on. The way we are kinda looking at it is each app is an aggregate root in terms of its feature set, it needs to be able to standalone for it to be considered an app in itself. Technically, all the information is out there, its just basic express and whatever flavour of client side app building goodness you want to use.
Not at all. You can use Angular to build a variety of apps. Client-side routing is just a small piece of that.
You have a large list of features that will benefit you outside of client-side routing:
two-way binding
templating
currency formatting
pluralization
reusable controls
RESTful api handling
AJAX handling
modularization
dependency injection
It's crazy to think that all of that "could only be used in a single page app". Of course not.. that's like saying "Jquery is only for projects with animations".
If it fits your project, use it.
I struggled with the "how" at first with Angular as well. Then one day it dawned on me: "It is STILL javascript". There are a bunch of examples on the ins-and-outs of Angular (one of my favorites along with the book https://github.com/angular-app/angular-app). The biggest thing to remember is to load in the js files just like you would in any other project. All you have to do is make sure the different pages reference the correct Angular object (controller, view, etc.) and you are off and running. I hope this makes sense, but the answer was so simple I overlooked it.
Maybe my experience will be useful to someone. We split our project logically. One SPA we use for feed, another one to work with the map, another one for editing a user profile and etc. For example we have three apps: feed, user and map. I use it in the separated urls, like this:
https://host/feed/#/top/
https://host/user/#/edit/1/
https://host/map/favorites/#/add/
Each of these applications has it's own local routing mappings between states in the application.
I think it is a good practice because each application work only with its own context and load dependencies that it really need. Also, it's practice very good for debug and integration processes.
Indeed, you can very easily make a mix of SPA apps, for example the feed will be url with the angularjs application, the user app with the reactjs and map to the backbone.js application.
In response to your question:
Angular not just for SPAs, Angular play good and fast for SPA applications, but no one bothers to build MPA application of a variety of SPA applications. But thinking about your url architecture don`t forget about SEO availability of your applications.
I also support the idea:
What’s the difference between a project and an app? An app is a Web
application that does something – e.g., a Weblog system, a database of
public records or a simple poll app. A project is a collection of
configuration and apps for a particular website. A project can contain
multiple apps. An app can be in multiple projects.
If all you need is a few pages with client databinding, I'd go with Knockout and Javascript Namespacing.
Knockout is great, especially if you need uncomplicated backward compatibility and have fairly straight forward pages. If you're using 3rd party components, Knockout's custom bindings are straightforward and easy to work with.
Javascript namespacing allows you to keep your code separate and manageable.
var myCo = myCo || {};
myCo.page = {
init: function(){ ... },
...
}
And in a script tag after your other scripts are loaded
<script>
myCo.init();
</script>
The key is, you use whatever tool you want for when you need it. Need databinding? Knockout (or whatever you like). Need routing? sammy.js (or whatever you like).
Client code can be as simple or complicated as you want it. I tried integrating Angular into a very complicated site with an existing proprietary framework, and it was a nightmare. Angular is great if you're starting fresh, but it has a learning curve and locks you into a very tight workflow. If you don't follow it, your code can get really tangled really fast.
I'd say Angular is overkill if you're just looking to develop a SPA. Sure, if you're already comfortable developing with it, go ahead. But if you're new to the framework and only need to develop a SPA, I'd go with something more simple with a number of its own perks. I recommend looking into Vue.js or Aurelia.io.
Vue.js uses two-way data binding, MVVM, reusable components, simple and quick to pickup, less code to write, etc. It combines some of the best features of Angular and React.
Aurelia.io, in all honesty, I don't know much about. But I've peeked around and it seems an alternative worth looking into, similar to the above.
Links:
https://vuejs.org/
http://aurelia.io/
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 5 years ago.
Improve this question
I have a few questions which I'd appreciate to have some answers on.
So I've created a backend node server with express & mongo which is running specific tasks on the net and saves it in the database in a loop. I've also added an admin page with express & bootstrap. And that works fine. What I needed then was a frontend page - for this I chose VueJS. I started that project seperate for multiple reasons. I felt that this would be easier to get started, since I didn't have any frontend framework experience before and the backend project was written in typescript and I'd rather use normal es6 JS for now.
Right now - the site has already made some pretty decent progress and is at the point where I need to establish connection with the database and also use some of the already implemented functions in the backend project.
And this created the question:
Should I create new functions and/or create and use API's? Would there be any problem with the mongodb in the form of accessing and writing to it by two different processes? Would there be security issues if I'd create "public" apis from my already existing backend logic? (Haven't written any apis yet.)
Or should I use the time and import the frontend project into the backend (meaning also either translating new to typescript or switching to normal ES6 JS)? Would this be a security risk since I'd rather not have the backend logic in my frontend site.
I appreciate any answer to that!
Thank you :)
This is a question of can you afford to run two servers? separating your front end from your back end is actually a good move considering all things microservices since it allows you to scale these things separately for future purposes. Like your backend needing more resources once you start catering to mobile user as well or once you get more api calls, while your front end server need only serve the ui and assets, nothing more. Though the clear downside is the increase in costs since you do need to run two servers instead of one, something that is difficult when you are just starting out
Should I create new functions and/or create and use API's?
For your backend? Yes. APIs are the way to do things now in the webspace as it future proofs you and allows a more controlled and uniform way to access your backend(everything goes through the api). So if your front end isnt accessing your database through the APIs yet, i suggest you refactor them to do so.
For your concerns about mongo, im pretty sure mongo already has features in place to avoid deadlocks.
As for security of your API, I suggest checking out JWT.
should I use the time and import the frontend project into the backend
should you go this path instead due to cost concerns, i would suggest rewriting one of the codebase to comply with the other for uniformity's sake, though do that at your leisure(we can't have you wasting all your precious time rewriting code that already works just fine). this isnt really that much of a security issue since backend code isnt being sent to the front end for all your users to see
Let me start by saying I've never used Vue. However, whenever I use react, I always make separate projects for the front end and the back end. I find it's 'cleaner' to keep the two separate.
I see no reason for you to transcribe your entire project from typescript. Simply have your frontend make requests to your backend.
If you're looking to brush up on your web security, I recommend you look into the Open Web Application Security Project.
Writing micro-services on back-end is not that much confusing, specially if we are building api endpoints. We can write separate project for users management, separate project for reporting, ..., and combine all their endpoint with AWS gateway api, or for smaller one acomplish this with nginx reverse proxy to provide a integrated api service.
The way I am suggesting the team for writing back-end is something like that:
localhost:8001/list <- reverse proxy to -> apiproxy.com/users/list
localhost:8003/transaction <- reverse proxy to -> apiproxy.com/transactions/create
So it seems simple, we write our projects by category in separate repos, and each team/person can work individualy on it. But here goes my question:
" How can we implement a solution, that a server rendered React app ( Or, angular, Vue ) can render, and developed with separate repositories, but in build time, they merge into each other, and their routing works well."
So, in this senario, each repository must be able to bootstrap independetly. The aim is not create a new framework.
Does anyone has any kind of suggestion?
Canopy Tax, a tech startup based in Utah that builds solutions for tax professionals, faced a similar situation about 2 years ago. They wanted to be able to implement some sort of microservice architecture in the front end, and guess what, they succeeded. The solution is not perfect yet, there's a lot of trade offs, but the objective is met and they are using this in production with their customers. I have seen it in action at some meet ups they have hosted.
Canopy Tax open sourced their framework last year, it is called Sofe. Here it is the link to the github project. Their solution, is used in production and is here to stay for a long time. They recently raised another 20 million in VC this year.
This sofe framework is what they call a Meta-framework. It is basically a main router that decides where to dispatch your routes. Then it dispatches to an angular, ember, react, angular2 app. And it gets even better, in the same page you can have pieces built in react, pieces in angular, etc. You get the idea. This allowed them to scale faster, get more talent as well as they are no longer limited to just one framework. And they can deploy anytime and their teams (squads) don't depend on each other as those pieces of the app are independent applications, like microservices in the front end.
It is still fairly new but definitively worth a look. I recently talked with them at a meet up and some other companies are using this as well in production. They also have an inspector tool an other tools that show you what framework that piece of the web app you select belongs to (e.g. react, angular, etc). Here it is the live demo of sofe in action.
Click on framework inspector there, then turn it on. It will show you.
There's trade offs on this approach, one is that this is not supported yet for mobile. It works great for their product but they are working on solutions for that as well.
Disclaimer: I do not work at Canopy Tax, I have never worked there and I do not have any relation with the company. I just like Sofe and what they are doing with the project.
Reaching out to Angular experts here, as i am pretty new with it.
What i am trying to accomplish is to build a very large app that will actually consist of multiple apps and login areas.
There will be different login areas for different types of users that have different functionality, but they will also share many sections that will be shared through all the accounts. Also some users will have custom functionalities developed just for them.
How could i build it so that the code for the shared parts is in one place only so that i don't have to update all installations mannually when there is an update and also at the same time for a user avoid loading unnecessary code that doesn't belong to them or their user type?
Note that i am building this in Angular for frontend and Laravel for the backend and they will communicate via an API.
I have a hard time figuring out how to do the Angular part, the Laravel backend will be easy to manage since it will be an API.
Thanks!
I have developed some SAPUI5 mobile apps and I'd like to merge them into a portal (with tiles) so I can switch between them as a "reputation".
Now I would like to know, what would be the "best" way to implement this case?
At the moment the apps have got a controller and views. My first idea was to build a "portal-app" which includes all the views of the other apps with an own controller but then I noticed that the performance has decreased (because all resources (OData-models etc.) load when starting the portal-app).
I also tried to link them (all with their own index.html) but this case seems not to be the right one.
So is there a way to load the views dynamicly or a whole app and how can I do that?
First of all, SAP's official solution for this problem is called SAP Fiori Launchpad. However, it's much more complex to set up (you need an underlying application server which holds SAP Fiori. You need to handle user roles and assign applications to roles). However, it's great for inspiration. (Here you can check it)
You can create a separate component which holds the references to other applications. Your applications can be referenced from Tiles.
I don't know the current implementation of your applications, but it's recommended to implement them as components (UI components if they have visual representation).
With components, you will be able to use Routing (navigating between views, or even components using hashes (urls)), which helps you to manage resources and services properly. With this you can prevent unwanted odata requests as well.
It can be a big step forward from a simple application architecture, but it's worth it.
Of course, you can implement one simple application without components. In this case you can experience the mentioned performance issues. Consider to move data intensive operations into event handlers and perform these tasks asynchronously.