I have 1 project which is divided into multiple SPA, I have 5 SPA, written in 2 in Angular, 2 in react and 1 in vue js. Now I have an integrated server which will serve the different files as per routing. I need to share the data from one app to another with least interaction of database. This is a scenario of micro frontends. Hope this clears my problem.
Any help will be appreciated.
There are three ways with which you can share data:
URL: Query Params/Path Params (Only for small data like ID, filters, etc.)
Session Storage: Use this only if you are not navigating to other tab/window
Local Storage: Most convenient and preferred way
Of course, if you are persisting state to Local Storage, then you have to handle flushing of the state by yourself when the user logs out.
This is a bit painful process to handle. You will have to write code to manage serialization and deserialization of JSON to Local Storage. To ease this, it is better if you have the same state management solution across all micro-apps. I recommend the use of Redux/MobX to do this. But if you are using Redux for React, Ng-Rx for Angular and Vuex for Vue, then you will not have any ready-made solution.
Also, when you are saving the state to Local Storage, either debounce it or do it lazily with little delay for performance reasons.
We are using micro-frontends for last two years and we use the mix of Local and Session storage to do our things. Luckily, for all the apps we use Redux, even with Vue, and that allows us to use redux-localstorage.
You can also use Cookies but it is generally better to avoid them.
1st, Custom element creation
I have worked for micro-front-end elements base architecture with #Angular/element module. As I worked, I used bellow flow
For code, I have followed build-a-micro-frontend-application-using-angular-elements.
Here it will provide you elements like native html elements.
2nd, Another good approach is to use library feature in angular. You can write your components, directive or pipe, then publish them or use them into other project directly. In this approach again you can reuse the same code.
3rd, We can use i-frame, but now days it is causing lot of security issues from browser.
Another option is to use a frontend event bus like EEV. Your application shell would be responsible for creating a shared event listener. Then each micro-frontend could emit events on that shared channel.
You could also use an RxJS Subject as a message bus within your App Shell and subscribe to it in the Micro Frontend Applications. Here's an example
I hope that gives you a couple additional ideas.
I came across same scenario where i have to pass the data from one micro-app to another.
and after lot of R&D i found that event based communication is the best , where i transfer the data in form on Event Objects.
here is some Example:
For sending data:
var event = new CustomEvent('userData', { "detail": { "id": id, ...rec } });
window.dispatchEvent(event);
and for receiving the data on other app is:
window.addEventListener("userData", function (e: CustomEvent) {
this.id = e.detail.id;
this.country = e.detail.country;
this.contact = e.detail.contact;
this.company = e.detail.company;
this.changeDetectorRef.detectChanges();
}.bind(this));
This approach does not need the DB communication.
Hope this will resolve your query!!!
Happy Coding!!!
Related
My project involves somewhat of a checklist. Initially, I used Redux to keep track of the state (whether something is checked off or not). Later I implemented a backend node server and a mongo database, and I load data from the database every time I fire up or refresh localhost. Since the checkoffs directly modify the elements in the database, there's not a whole lot Redux is doing that pre-emptive loading isn't already doing.
So my main question is that if the data is fetched from the backend the moment I start everything up, what else can I use Redux for in this case? I know my project might be too small and simple to give out a good answer, but I'd still like to know possibilities if possible.
No matter, your data is coming form backend but you still need redux for many reasons. Redux is not about just for storing data but it best for performance. Let discuss it with use cases.
Suppose you have main component of COMPANY and that is fetching data from API/backend and data cam to COMPANY component and same data is required to your ADMIN component and you again call network for data, and you know fetching data for each component from backend is very heavy and make your application slow.
So the best solution is to fetch all you data one time and save them in REDUX STORE and distribute data over your components.
MAIN ROLE:
1- Easy to manage data and state
2- Optimization and performace improvement with SELECTORS
3- Debugging is very easy
4- Easy to track data
I have developed an application which was MVC application. It has a requirement that the application will return json data for one get request.
So I have added apicontroller and created a get method to return json data.
So far so good. but then I thought, is it really needed to add apicontroller to create just one get method.
I started exploring and googling what is the difference other than content negotiation. Got lots of answers and articles but non of them were satisfactory.
So here is the actual confusion, why can't I just create a method in the MVC controller with JsonResponse and return the json data(Which I know only is need for my requirement, but other application on different domain will consume it).
Can anyone convince me why should I use apicontroller instead of MVC JsonResponse for my requirement or should I not be using apicontroller at all.
apology if there is any mistake.
If I get it right the question is Can we use MVC action to serve json content answer is yes! Is it okay to use Json Result? answer is It depends where do you want to consume it
Say I am an in a Web Environment where I have no need for the APIs (that means I am not going to serve my data to multiple clients) If that's the scenario where only your View is going to consume data returned from your Action Method you are good to go. An Action returning a Json Result is basically an Action Result and that's what it is made for.
but If you are in a REST scenario and you need your backend to serve your data to the client de facto standard is to use an independent Web API for that.
Controllers' main responsibility should be to work as an intermediary between your View and Model and whatever service layer you want to bring inside it. on the other hand, Web APIs are data-driven there only purpose is to serve data (use them if you need them)
Web APIs are good cause they give you the flexibility of serving the data to possibly any client that might need it. That's what I would pick if I am starting from scratch but if I only need to serve data to one client Controller Action methods will be way to go.
Hope this helps.
I am building a sports data visualization application with server-side rendering in React (ES6)/Redux/React-Router-Redux. At the top, there is a class-based App component, and there are two different class-based component routes. (everything under those is a stateless functional component), structured as follows:
App
|__ Index (/)
|__ Match (/match/:id)
When a request is made for a given route, one API call is dispatched, containing all information for the given route. This is hosted on a different server, where we're using Restify and Sequelize ORM. The JSON object returned is roughly 12,000 to 30,000 lines long and takes anywhere from 500ms to 8500ms to return.
Our application, therefore, takes a long time to load, and I'm thinking that this is the main bottleneck. I have a couple options in mind.
Separate this huge API call into many smaller API calls. Although, since JS is single-threaded, I'd have to measure the speed of the render to find out if this is viable.
Attempt lazy loading by dispatching a new API call when a new tab is clicked (each match has several games, all in new tabs)
Am I on the right track? Or is there a better option? Thanks in advance, and please let me know if you need any more examples!
This depends on many things including who your target client is. Would mobile devices ever use this or strictly desktop?
From what you have said so far, I would opt for "lazy loading".
Either way you generally never want any app to force a user to wait at all especially not over 8 seconds.
You want your page send and show up with something that works as quick as possible. This means you don't want to have to wait until all data resolves before your UI can be hydrated. (This is what will have to happen if you are truly server side rendering because in many situations your client application would be built and delivered at least a few seconds before the data is resolved and sent over the line.)
If you have mobile devices with spotty networks connections they will likely never see this page due to timeouts.
It looks like paginating and lazy loading based on accessing other pages might be a good solution here.
In this situation you may also want to look into persisting the data and caching. This is a pretty big undertaking and might be more complicated than you would want. I know some colleagues who might use libraries to handle most of this stuff for them.
I am working on a small hobby project, where I would really like some input and advice.
This is my first "real" node project, and I hope it will teach me a lot about node.js development. I am a .net developer by day, and have been for about 15 years professionally. I have had periods of doing Java as well. I have created small node.js projects to be used as micro services.
But this project can no longer be classified as a micro service ;-)
The purpose of the project is to sample some sensor data, and do some reporting. An idea I got from playing around with a PLC at university. I do that by sampling from a PLC, and emitting the data using ZeroMQ. My node.js server then listens for this sensor data, and stores it in a MongoDB.
I expose that data in a REST api. The REST api also exposes resources like batches and other stuff like authentication etc. On top of that I have an AngularJS app, that creates defines the UI.
The one thing that really annoys me, is that I want to globally assign what batch is running. I have a collection of batches, and one of them is the running one. There are a two ways I see to do this, and both illustrate my novice status in the node.js world. All users should be able to see what batch is running, and I want to be able to easily tell from anywhere in the code as well.
1) Set a flag on the object in Mongo. This has a number of problems. The obvious one being performance. I receive sensor data 10 times a second, and I don't want to ask the database every time what batch to save it under.
2) Save the info on the global object. I really don't like this either. I don't like global state in my code.
What is a good pattern for doing something like this? Does my question make any sense?
Thanks in advance
You can make a simple REST call to set the active batch and call it inside the batch when is started up and ready to accept requests. For example:
app.put('/active-batch', function(req, res, next){
// Make sure req.body is defined
app.set('active-batch', req.body);
res.end();
});
Then everywhere in the code you can use:
app.get('active-batch');
The app.set let you save data globally accessible in your app and app.get let you read previously stored data.
I'm using Firebase and the SimpleLogin to allow users to login via Google, Twitter etc.
I'd like to use some of the thirdpartyuserdata object to create a user profile for my application which runs on Node.
Currently I'm posting this data to the server so that I can add to it and create the profile object, but I wondered if there's a better way of doing this - is there something I can call server side to get this thirdpartyuserdata without having to post it from the client?
Start by considering that your "server" is actually just another consumer of Firebase data. Since FirebaseSimpleLogin is simply a token generator with some fancy tools for doing OAuth, and because this happens completely client-side, there is nothing to consume about this.
If you want to consume the data at the server, you will either need to POST it, as you have done, or use Firebase to transfer the information. You'll find that a queue approach can save you a large amount of code, as this allows you to use Firebase as the API, and avoid creating RESTful services in Node, and all the baggage that comes with that.
The idea of a queue is simply that you push data into Firebase at one client and read it out (and probably delete it) at the intended recipient (in this case your node worker).