I was learning react and came across such technology as docker and after some done research I just cannot get the benefit it brings for react apps, that is, most of the articles are about dockerizing backend such as Node.js and the one of benefits of docker for backend technologies is that if we want to scale our project in the future then we can take advantage of cloning backend project and put put load balancer in the front. I think it is what we want for our react app. So, pls can you briefly tell me the real benefits we get from dockerizing our reaect app.
The general benefits of container technology will be available to your react app too. Chief among thrm is the extent of isolation a container provides to the config of your application. Apart from the bubble of security this isolation creates, it further simplifies the system administration by making you able to define your Infrastructure as Code.
This ushers in the concept of GitOps to your DevOps which upholds the contemporary practices of hierarchical collaboration and shared responsibility of the up time of your system. Current software development schemes and large scale distributions depend highly on these principles.
Related
I am leading a web application with a standard client-server-database architecture. My original plan was to have the client in react.js, the server in django+python, and the database in MySQL. Now, the programmer in charge of the client side is an expert in Unity 3D Engine, and he suggested to use this to implement the client. The advantges are:
Very easy to design;
Cross-platform - can be compiled to web, Android and iPhone.
One disadvantage is that the file size is larger, but for our application, it is not a substantial concern.
What worries me is that I do not know of any non-game web-applications that are written in Unity Engine, so there may be some disadvantages that I am not aware of.
Question: what are the disadvantages of using Unity 3D Engine to design the client side of a web application (versus e.g. react.js)?
I will mention some drawbacks I might think of compared to the web side of developing a web app. However I want to mention first that unity's versatility makes it suitable for any application you might think of and that the feature of compiling for the web is so huge. The times I am mentioning below are not big (it will depend on the app), but are to be considered if what is being built is a web app.
Unity webgl build size is said to be large, so the init load time of your web might take some seconds. Getting your hands dirty improving that might not be feasible as the build is provided by unity, so you would also lose that flexibility improving the load times. Also if you dont have the unity's pro version, your will have the "made with unity" splash screen on your web.
You can check that building an empty or very simple project to check these two things.
If you are not using the engines features regarding the game dev side, would not make much sense to use unity for me, meaning the physics, animations, collisions etc. It is expected a larger load time for graphic things or games, not for current webs though.
Another thing to consider. Seems that you can handle the settings of your build to work in mobile browsers, check the documentation. However the layout adaptation when you are using the app in a mobile browser might be much tougher as you renounce to manipulate easily the html and css directly yourself and renouncing to all the js and css ecosystem that might provide this work done for you. May be not renouncing, but it should take longer to integrate those in your unity builds if that is even possible.
Also, unity webgl builds take a while to be made, so for testing and so on, the compile + building + deploy time is a bit of a drawback compared to a web "live loading" + deploy which is a much faster workflow.
I'm planning to create a bunch of (2 to 3) ReactJS frontends that all primarily interact with the same existing Ruby on Rails API. Each frontend will appear on a different domain, but will use the same graphic design system and UI. Because of this I imagine that they will be sharing a lot of code.
How would you recommend organizing the code for such a project? And also how would you deploy it?
Code sharing
In my research I found the solution of creating a node package that just contains the shared components/code. My concern there is that then the developer (me) would have to be constantly bouncing from the module's repo to the repo for each site.
I also noticed bit but wondering if I want to be so dependent on a proprietary service.
These frontend sites don't really need to be completely isolated from each other in different repositories—even though they are on different domains, you could almost think of them as different sections of the same site, in the sense that they are closely related.
Deployment
If, for example, all this code is kept in the same npm project, then it's conceivable that when deploying, several build scripts could build each frontend and then push each build to a CDN. Would that be a good strategy?
AEM itself is self reliant WCMS and can be used to generate very rich digital experiences over multiple channels.
Often there is talk of using Angular as front end and moving AEM to backseat. What is point of doing so?
Using angular will add additional complexity and developer has to deal with it, increasing efforts for building system.
It will undermine core AEM features e.g. HTL & clientlibs
Multi channel experience can still be achieved without angular.
In short: there is no point in doing so when you deliver static pages, as seen in standard AEM use cases. It get's even worse: when you want to use AEM for dynamic pages, you might run into performance issues, so an external data source / index to query the "dynamic" data is almost mandatory.
I would recommend a clean separation of view and view-model using Sightly and Sling models which allow for a fast refactoring of views in case there is a good reason to migrate the frontend to a different technology / templating language.
And I am leaving out the fact that Angular will be basically replaced by Angular 2 and there are strong competitors like React, Ember etc...
AEM's core strengths are:
WYSIWYG
Multiple Adobe suite integration (analytics, target etc)
Authoring experience for MSM
Security integration from UI to db layer
There are many more strenghts along with many weaknesses. Using Angular or other similar platforms require AEM to be used as Content as a Service (CaaS) which isn't its primary strenght yet.
Organizations that invest in AEM are mostly after the core strenghts provided by it and won't normally benefit from using AEM as a CaaS platform. Unless Adobe provides plugin model for their integration suite that can work with mainstream front wnd technologies like Angular (2) and React, it would be a very uphill task for any team to get the most out of AEM suite without missing out on all the benefits provided (at a cost) by the whole of Adobe marketing suite.
In short, from TcO perspective, these platforms are not easily compatible with AEM due to the unique nature of product which means the integration is normally a challenge and sometimes counter productive when integration benefits of the core platform are compromised.
I believe it totally depends on the use case. I have done projects with AEM using jQuery and others using Angular. If developer knows what he/she is doing, adding angular is not much of a hassle. 2 way data binding, a clean way of doing Ajax and ease of Single Page Application, that pretty much sums it up. Works really well..
Angular and other front-end frameworks provide the additional benefit of SPA which if integrated the right way with AEM can work wonders!
Yes, I agree that integration is an uphill task but the page load times can reduce significantly and using features like routing we can reduce the server calls for transition across the site pages.
Why AEM-Angular integration can be a good thing?
AEM can be used as a CaaS platform in few cases where the content will primarily be loaded using SPA. In other cases, components can be a mix of HTL and Angular where HTL can provide additional security using proper context.
You can pass AEM authored content to Angular directives/components as attributes and perform the desired functionality.
Angular can be used to build reusable components and directives on the front-end which can simply be reused across AEM components.
The Angular dependencies can be made a part of the AEM client library and this ensures that Angular functionality works as expected.
Build tools like Maven and Ant are powerful enough to support the integration. Simple tasks have to be written in pom.xml.
AEM 6.4 Beta has support for front-end frameworks and I have observed how fast the content load can be!
Other AEM integrations (Adobe Target, Adobe Campaign, Adobe Analytics) can be still leveraged in similar ways as before.
Did I forget JQuery? Angular and other front-end frameworks will provide cleaner and more efficient ways of doing the same things in JQuery.
The decision to use both will totally depend on the use case and this is not recommended for all solutions though.
I have worked on AEM for more than a year. In my project, the stack was AEM, jQuery, and some 3rd party library to handle JS relevant issues(like IE support and util functions).
If you want to integrate Angular then I see the below things from your query
Good :
You don't need the headache of java related issues.
No need for more backend developers(though I am a backend developer).
If you do want to change some files in stage or prod environment, no need to go with java change directly package installation will work.
You can leverage angular strategies to build your project efficiently.
No need to worry about your project optimization. Angular will take care of JS library optimization and loading into client-side browser.
No need worry for page speed issues from google audit for your websites. That will be taken care of by Angular.
You will be able to achieve the hybrid model of clientlib and can avoid lot's of Js issues along with clientlib comes in to picture.
Testing of components will be easier.
AEM also follows Component similar to angular, so things can be merged based on good architecture.
Not Good:
sightly syntax might be underutilized.
Still, there will be cases you have to dependent on java for achieving some features.
Security issues need to be fixed as everything will be done on the client-side.
more issues if you are using etc/map related URLs.
more complexity if you follow SEO optimization standards.
More dispatcher configurations.
Needs to habituate aem structure with angular structure.
AEM structure will be more complex when merged with angular
I am quite new to Angular. I have written this answer based on my experience. I will keep updating if any edits required.
Using AEM as an integration layer is a challenging decision. AEM is a content management system and works well for static content (content is cached at Dispatcher layer).
However, it use the Jetty server under the hood. Jetty uses thread pools for handling requests. It means that when the number of users increases, it use more and more resources. The situation is the same for time-consuming operations - think about API's unavailability or delays.
Instead of using AEM as an integration layer, you delegate this integration logic to more reactive systems such as Knot.x. Then AEM may serve only static pages (templates), Knot.x would fill all required data from external APIs.
See more here.
I am working on a pet project ( web application ) and I was wondering if I should use react because it would be easy to create native apps from this code (in future if I need to).
And if the answer is yes, what are the best practices to follow for
most resuse?
If the answer is no, can you recommend an alternative?
Some more information about my situation.
I am relatively new to react and my alternative will be good ol' html with bootstrap and jquery. I am considering using asp.net mvc and web api.
Sharing app logic between a React Web app and a React Native app, while keeping the individual component rendering unique to each platform is possible!
In my opinion, it is a great option we have available. I will give you an overview of the approach and a few advices.
In an ideal world, we would be able to share 100% of the code. As far as I know, that isn't possible, but still we can share a lot of the code. Although React Native is like React, it is very important to note that the rendering code is different. Instead web things like <div> or <span>, you use React Native components like <View>, <Text> and other built-in components.
However, the business logic in most cases is just JavaScript though and that's one of the important things which we can share!
The plan
Based on the Flux architecture you are using, it would mean that your store(s), reducers, actions would be shared code, as well as most of the business logic (inside services or whatever) and the constants and utilities too.
The UI layer would then be written specifically for each native platform using React Native and for web using React. Not only because it’s necessary to replace the HTML elements with React Native components, but also because the components will probably have a very different behavior on the mobile app.
Some General Guidelines / Advices
Consider a good architecture and code structure in order to share as much code (and application logic) as possible. Try to separate the UI presentation components (which will be different for each platform).
Take a look at the JavaScript Environment specifics in the React Native docs. When using React Native, you're going to be running your JavaScript code in two environments:
On iOS simulators and devices, Android emulators and devices. React Native uses JavaScriptCore which is the JavaScript engine that powers Safari. On iOS JSC doesn't use JIT due to the absence of writable executable memory in iOS apps.
When using Chrome debugging, it runs all the JavaScript code within Chrome itself and communicates with native code via WebSocket. So you are using V8.
While both environments are very similar, you may end up hitting some inconsistencies.
Consider the different strategies for sharing the code. In order to accesses shared code, the apps you're building doesn't have to all live in the same codebase or git repository.
More realistically, you would have two or more projects hosted separately, so an npm package is one of the easiest ways to share code between them.
This is easy as making a new package and setting it as a dependency inside each of your projects. For the path to the shared project, you can use a git repository rather than pointing to a public package on npm.
Even though you're building only the web app now, you could spend some time thinking about how you could generalize some of the shared code, so it is easier to re-use it in future.
It's possible and viable. You must have a view for each platform (web/android/ios), because each one have your components..
The business logic must be out of the view. Use flux can easy your project with native, because the it move the api interaction to a data layer, letting the view be just a view.
I'm trying to develop a hybrid app which will deliver a range of simple teaching material to the user. I am planning on using Telerik App Builder in conjunction with Cordoba 3 to create the app. What I cannot decide is how best to package the actual content into the application. I'd like to achieve a separation of the content from the code, and just combine the two when building the delivery packages. (The content is being prepared by a subject matter expert.)
Is there a way I can use Cordova or Telerik AppBuilder to pre-populate a SQLite database as part of the app install process? Or am going about this in completely the wrong way? I have been researching this in the Telerik documentation but without success so far. If someone could point me towards a suitable example or even the correct places in the Telerik or Cordova docs I'd be very grateful!
I recently ran a techie webinar on the topic. The main idea is that you need a centralized system to host this content and this system needs to expose some kind of a service layer that will feed content to your app. To me this seems like a very growing market opportunity, but feels kinda the same as the web 1.0 days where all of us were trying to figure out how to feed cotnent to websites and everybody was building their own CMS in a way.
Telerik Backend Services provides an editing interface, so it can fit some requirements, but it's not a publishing system, plus you may not want to pay developer licenses to your back-end users or provide them with access. The premise of the webinar I am talking about was that we discussed how to integrate with another telerik product - Sitefinity to do this job for you instead. The first 20-25 minutes are an overview of the platfrom, so if you have seen it already, you can certainly jump to ~;0:25 to see the rest
http://www.sitefinity.com/campaigns/webinars/build-content-driven-mobile-apps
Now certainly it doesn't have to be Sitefinity or CMS for that matter, Sitefinity provides a bunch of App Builder related features that are handy, but you technically have a few options:
- Build your own applicaiton and back-end.
- Use any type of CMS or platform that will give your SMEs the back-end interface to publish and the service layer to expose to the app. In the webinar I also go through some neat tricks such as using push notifications upon publishing.
This way you get a clear separation of content and code - you can even get a separation of content structure and code, which is an idea i talk about in greater detail.
I hope this helps!
Svetla