I am trying to make two Angular apps and i want an event emitter to listen events commonly in between two different application with Single-spa otherwise known as MicroFrontend for multiple js framework but i am unable to find any possible solution .
Please see this link for better understanding Visit http://single-spa.surge.sh/
https://angular.io/api/core/NgZone
This NgZone will act like publish and subscribe event emitter mechanism for communication from one ng2 applicaton to any other application out of angular framework .
Related
We have Android and iOS (Objective-C) mobile applications.
Our Business Intelligence team is interested in receiving the following parameters with each data event:
the app version
the user session id
We use gRPC for both the mobile-backend communication and also for communicating between the different microservices on the backend.
I am considering sending this information using open tracing spans that are started on the mobile app and pass the app version and session id trough the Baggage.
Can anyone advise if open tracing is suitable for this scenario or if there is a better alternative?
We are also considering using LinkerD on the backend
I'm not sure baggage is really what you want. OpenTracing also offers the possibility of adding tags to a span, which would probably be sufficient for your use-case.
A baggage item is sent downstream along with the span context, whereas a tag is "local" to a span. If you need access to the app version on a span downstream, then you indeed have to use a baggage item, but if all you need is to have the version information within the span, you should just tag it.
About OpenTracing being suitable or not: I'd say that's exactly the purpose of OpenTracing. Not only you'll potentially get "automatic" spans from the frameworks you are using (using the "framework integrations"), but also you can relate that to your business information. We have an example on Hawkular APM where we add both "operational" and "business" data to traces.
Instead of using flux/redux architecture, how react components should communicate with services?
For example:
There is a container having few representational (react) components:
ChatBox - enables to read/write messages
AvatarBox with password changer - which enables to change user's password
News stream - lists news and apply filter to them
Thinking of them as resources representation, I want each of them to access Microservice API by itself (getting or updating data). Is this correct?
It will provide clean responsibility managing models, but it gives performance doubts using http requests to load each component's content
This question also reffers to: How to execute efficient communication for multiple (micro)services?
When you opt for not using Flux/Redux, here is what you do:
Create an outer component that should wrap all the other components. This component is also known as a higher order component or a controller view. This component should use an HTTP library to communicate with your microservices (I personally like Axios). I would recommend that you create a client API object that wraps Axios. Your higher order component can reference this client API so it is agnostic of the HTTP library and whatnots. I would also put a reference of this client API on the window object in dev mode so you can do window.clientApi.fetchSomething() in the Chrome console and make debugging easier.
Make all the other components (ChatBox, AvatarBox and NewsStream) controlled. If you are not familiar with this concept, it means they receive everything they need through props and they avoid keeping state. These components should not call the microservices themselves. This is responsability of the higher order component. In order to be interactive, these components should receive event handlers as functions as props.
Is this correct? It will provide clean responsibility managing models, but it gives performance doubts using http requests to load each component's content
You can avoid performance issues by not allowing each component to directly contact the microservices. If your higher order component compiles all the information needed and make as little as possible HTTP calls, you should be perfectly fine with this approach.
It's generally recommended to use Flux/Redux, but if you opt out, this is how to go about it.
According to: https://facebook.github.io/flux/docs/overview.html#content
Occasionally we may need to add additional controller-views deeper in the
hierarchy to keep components simple. This might help us to better encapsulate a
section of the hierarchy related to a specific data domain.
And this is what I am thinking about responsibility of particulary component's domain (three of them was described). So could it be reliable to make three controller views (or stores) that can access dependent API to manage resource's data?
I am trying to build a mobile application and i am using navigation and routing for switching between my views.
since my app has many view using single component becomes bulky.So i want to modularise that by loading additional routes to my component when needed.
I went through the developer guide which shows how to extend the components (page no.306-308),by doing so i was able to get data of my parent component but could not add additional routes to it..
So i thought of having two different components,please see the attachment in the link my SCN posting
problem is i cannot directly navigate to the view corresponding to my subComponent since every time the browser loads my application it starts main component and not my subComponent and my main component cannot recognize the routes of my subComponent.Hence bookmarking doesn't work.
Is there any way how to communicate between components???
my goal is to modularise my component...
It would be a great help if any one knows or understands my problem and solution for it...
Also suggest if there is any problems in my application structure and any changes to be made...
I am sorry for my long question
Regards,
Ajaay krishna
To communicate between components you can use events, in your case you can also create a function that will act as a service that your sub-component registers to and in the callback receives the routes.
To understand UI5 events you can see this reply
Click here
Regards,Saar
I own a Play 2.1 application.
Initially, I used the default template mechanisms from Play 2.1 until I .. learned AngularJS.
Now, I clearly want my client side to be an AngularJS app.
However, while surfing the net, I find there are no clear way to achieve it:
Letting Play behave as a simple RESTful application (deleting the view folder) and making a totally distinct project to build the view (AngularJS app initialized by grunt.js).
Advantage: Likely to be less messy, and front and backend teams would work easily separately.
Drawback: Need another HTTP server for the AngularJS app.
Try to totally integrate AngularJS app with the traditional Play's workflow.
Drawback: With a pretty complex framework like AngularJS, it would lead to a confusion of templates managementfor instance : scala.html (for Play) / tpl.html (for Angular) ... => messy.
Making a custom folder within the play project but distinct from the initial folders created by the Play scaffolding. Let's call it myangularview instead of traditional view for instance. Then, publish static contents generated by grunt.js into the Play's public folder, in order to be reachable from browser through Play's routing.
Advantage: SRP between components is still fairly respected and no need to use another light HTTP server for the client-side like in 1.
I pointed out my own views of advantage and drawbacks.
What would be a great way to achieve the combination of Play with Angular?
Yes, I'm answering to my own question :)
I came across this way of doing:
http://jeff.konowit.ch/posts/yeoman-rails-angular/
Rails?? No matter the framework is, the need remains exactly same.
It advocates a real separation between APIs (backend side), and front-end side (in this case making AJAX calls to backend server).
Thus, what I've learned is:
During development phase, a developer would use two servers: localhost on two distinct ports.
During production phase, the front-end elements would be encompassed into the whole backend side (the article would deal with a kind public folder, aiming to serve static contents: HTML, angular templates (for instance), CSS etc... Advantage? => dealing with a one and unique serving server's APIs exposition as well as static assets for the UI.
With this organization, some tools like Yeoman would be able to bring some really awesome handy things to developers like for instance: the livereload feature. :):)
Of course, during development phase, we end up with two different domains, (localhost:3000 and localhost:9000 for instance) causing issues for traditional ajax requests. Then, as the article points out, a proxy may be really useful.
I really find this whole practice very elegant and pleasant to work with.
There was an interesting discussion on the play mailinglist a couple of days ago about frontend-stack/solution, could be something in it for you, quite some people using angular it seems: https://groups.google.com/forum/#!searchin/play-framework/frontend/play-framework/IKdOowvRH0s/tQsD9zp--5oJ
We have a GWT application specifically designed to handle mobile clients and built with MGWT.
Now, we need to build a frontend for classical web clients, probably building it with GWT-Bootstrap and I'm wondering what's the best solution to achieve this.
How should we proceed with modules, gwt.xml configuration, client type detection, etc ...
What are your suggestions ?
Check this question for how to tell what platform the user is on.
Beyond that, GWT uses only HTML and Javascript, so unlike Flash applications, it actually works fine on mobile devices too; most events (such as clicks) are translated by the browser, so a touch becomes a click, you don't need a separate handler or anything.
Basically what I would suggest is you have a single GWT regardless of platform, and only for certain Widgets, add separate options for Mobile and Desktop, as necessary.
I don't know the architecture of your app and if you use the MVP pattern but GWTP with its Form-factors feature allows you to share almost all of your business logic (your presenters) across the different platforms. You have just to write the view depending on the platform you want to support.