I'm using HDIV for JSF and Spring MVC applications to mitigate OWASP top 10 security risks. Now I have to implement the same in AngularJS.
Is there any library avilable similar to HDIV for AngularJS?
For client-mvc scenarios such as AngularJS Spring-Hateoas approach fits well with HDIV. Actually, HDIV has a module for that integration: https://github.com/hdiv/hdiv/tree/hdiv-hateoas
It’s not totally finished yet but the integration of URL resources works (see ResourceRequestDataValueProcessor) but it’s not finished the support for forms. When we started this module this data format for forms was not finished or defined, and that’s why we did not continue this work.
We think it could be possible a very integrated solution with HDIV following Hypermedia and HATEOAS
approach for client-mvc apps or also for native mobile apps. In other words, within REST Hypermedia approach all URLs or forms, excepting the first URL, are created in the server side, in a similar way of traditional server side MVC web technologies.
Please take a look to this module (hdiv-hateoas) and we can support you if you have any doubts.
Roberto Velasco (HDIV team)
Related
Context
Our project has a Java back-end that accesses a Neo4j database. The back-end is nearly finished. Previously we intended to build a Java desktop client with a JavaFX UI. Now we are considering building a web application instead. I will be building the front-end. My previous experience was mostly using Java. I will have to learn a new language. The thing I'm having some trouble with is determining which one is best suited for this project. Before we begin front-end development we also want to ensure that the web app will be able to handle all features we had planned for the desktop client.
Requirements
Connection
Send HTTPS requests (not expecting any problems here)
Keep a persistent HTTPS connection open to receive server-sent events
Data
Store and handle considerable amounts of information received through server-sent events (potentially millions of events)
UI
Create a beautiful and highly reactive UI
Create complex custom components
Drag and drop support (also not expecting any problems here)
Integrate a view of an external site into the UI
Platform
Platform independence
No need for browser plugins
Candidates
These are some candidates I have identified during my research:
JavaScript with React
ASP.NET
Python with Flask
React js for the front end. Most anything for the backend. We use Python/Flask for routing and inserting into templates. But, you will really appreciate React for its "reactive" UI. It's incredible what it can do. I see no problems with the task list you've given.
I’m working with a large company with multiple dispersed teams developing applications using the ADAL client libraries and either the React and/or Angular frameworks. Over time, the various organizations within the company have each modified/extended ADAL.js to create their own adaptations for handling different needs (for example, implementations differences for React vs Angular …or handling different versions of a framework, like Angular 2 vs Angular 5).
With this context in mind, I was asked the specific question:
"Just wanted to know if Microsoft has any plans to enhance and support
ADAL.js for newer frameworks as most UI use cases for Azure AD would be on Angular and React and these ‘solutions’ are frequently updated"
In other words, do we have guidance (and/or a roadmap) for a more abstracted way of handling the implementation with various frameworks …or across different versions of a particular framework?
Or should each org continue to create their own adaptations?
So far there appears to be updates to existing ADAL libraries but no plans to support additional web frameworks. I.e "to bad so sad" for those of us using Angular 2/4/5/6
See the following issues in the ADAL.js github repo
azure-activedirectory-library-for-js/issues/510
azure-activedirectory-library-for-js/issues/379
Also keep an eye here: Vittorio Bertocci's Blog
There are a bunch of 3rd party efforts to create wrappers for later versions of angular, but they all need to be vetted before use (that is certainly what I am doing).
We do have plans for building wrapper libraries for Angular in the Azure AD SDK roadmap. However, we are focusing the efforts on the newer MSAL.js library which integrates with the Azure AD v2 endpoint and brings additional capabilities such as support for Azure AD B2C and signing in MSA accounts. You can track this issue on the MSAL.js repo.
I have been wondering whether this combination of technologies would work. I can implement a modular web application with MVC, EF, and utilize AngularJs if I would want to play around with the technology to implement sort of a mini SPA. I would like to extend my knowledge a bit further, and I was wondering whether I could utilize node.js instead of EF for relational database communication. Can I intermingle MVC back end with AngularJs for front end (mixed with MVC), and node.js for database communications
Is it possible? Yes, technically, but it would be very bad practice.
ASP.NET's MVC does nearly everything server-side. This means that views are built within the server and sent to the user. The controller is also server side.
With AngularJS, this paradigm is flipped on its head. The controller and view are both client side. The server sends the user all of the views and controllers at once, and then from then on only serves data. This is very attractive for single-page applications, and sites that want to exchange data, but not have to constantly send a new view. NodeJS is a popular architecture to use for the server, but any server architecture will work fine with Angular.
Both systems have their pros and cons, but there is no sane reason I can think of to use them together. You can certainly use ASP.NET as the server/model for an AngularJS application, but I'd discourage you from using APT.NET MVC with Angular.
I have a app and I need develop a restfull api to be used for this app.
Is liferay a valid option to develop this (using the service builder and persistence layer of liferay) to expose my service api to be used for the app?
I have in mind the performance and availability to this services.
what another option (to develop the api rest) i should consider for this purpose
Thanks
I expect for your replies.
Regards
Liferay can act as a rest server by service buider (I'm not sure it will support any RESTful operation, but only GET/POST).
By this way you can inherit the interesting features provided such as:
- users, roles and groups
- ready scalable platform
- hibernate+ehcache already configured
Ecc... by the other hand, it will bring a great burden to you... so in my mind, if you are interested to other Liferay native features, then you can use it.
On contrary, there are other ligther frameworks for achieving your needs (just think to Spring MVC, it can implement any other restful method, like so PUT/DELETE... and it is more configurable)... so in this case it will ask you to do a bit more work by hand... but you will not "fight" with a complex platform if it is not necessary.
(In the first hypothesis, don't forget to give an eye to the "Liferay Mobile SDK")
thanks for answer.
In fact, I am interested in use the features of liferay like users, groups, profiles, persistence layer and the web content to manager some resources in the app.
My question is thinking in the performance and scalability of the services layer for this app, if is factible use only liferay to expose all the service to the app need and if her performance will be appropriate.
regards.
Context: I'm a beginner programmer, self taught in the hope of making a SPA. I've started with JavaScript, Jquery, PHP and MySQL, and now feel pretty confident with all. I've started with Ember, and am now moving away from having a PHP API to Node. Which has then brought me closer to Meteor... I'm aware I'll need to use Mongo instead, but having an integrated front and back seems to be sensible and have some advantages.
So my question is what are the advantages of having a separate REST backend API (eg Express) rather than an integrated front/back (eg Meteor).
One that springs to mind is that my app will be tablet/pc based, but in future I'll want a different mobile version, so I'd be able to use just use the same API. I'm conscious that the above question is the main concern with this stack question, but perhaps if a meteor developer could clarify whether this is indeed a concern.
Thanks in advance!
well for me you'll get a lot of advantages using a rest API, they are lightweight, extensible and overall reusable.
today it's a trend to use a vertical architecture that means having a RestFul service with a single responsibility, why because it scale better and it's easier to assign a team to an api, so that way you'll be able to manage several teams and apis in a very ordered way. This is probably how Twitter, wunderlist and other companies works, because it's a solution to scale better.
take a look to this talk by Raffi Krikorian he was the head of architecture of Twitter for a while is a little bit old but it worth every minute and to illustrate some of the advantages.
Also you can look at the diagram below, I did while ago it explains the differences between the MVC and API first type of architecture.
I've authored one rest app using angular and rest services and it has been a very nice experience to me there's no way back.
good luck
Meteor doesn't really "integrate" the front (client) and backend (server) as you describe. It still maintains them as two separate layers. The beauty of meteor (aside from the insanely awesome reactivity) is that it uses Javascript everywhere, instead of using JS on the client and some other language on the server, so you can use the same APIs on both the front and backend. Although Meteor does snazzy things like let you write client and server code in the same file, it still requires you to distinguish between the two, and server code is still stored only on the server and client-side code is still served down to the client.
Meteor is still young, but the developers and community are very active, and everything you described can be achieved with it at this point. I've been working with Meteor for about 6 months now, and it hasn't let me down yet. I'm working on a production-level application that also requires exposing a REST API for consumption in mobile apps, which I'm doing quite successfully with Meteor (I just updated a user profile using a REST endpoint from an Android device and watched it change in the Meteor app in realtime. So cool!).
I was using this great package, RestStop2, for building REST APIs in meteor, but it was unfortunately deprecated, so I released an updated version. Check it out for an example of building REST APIs in Meteor. It's available through the Meteor package manager: https://atmospherejs.com/nimble/restivus
So to answer your question, you always want to separate the REST API into it's own layer, but that is entirely possible with Meteor. To make it clear, you would never consume this REST API from within your Meteor app. Meteor uses DDP (not HTTP), which gives you a much more direct connection with your server, so you're doing something wrong if you're accessing data on your Meteor server from a Meteor client via HTTP. Of course, with Meteor, you have the advantage of being able to use existing code from your REST API.
There's a really good write-up that explains some of the considerations of writing a REST API in Meteor: http://www.meteorpedia.com/read/REST_API.
The design of a architecture separated in layers like frontend, backend (Rest Api) and DB, is for obtain a better a scalability, reusability and logic separator of features of the application. For example:
Today make a web applications separated in 3 layer (frontend, backend,
and databases), if tomorrow you wanna do a mobile application you can
develop the application like a extra project in the frontend layer,
but use all the features developed in backend. Then the frontend
application not need servers why run inside every device, but maybe
the load in the backend servers increase, and you only need add 1 more
server in the backend layer.
Its a little example, but is the most common case in this new era of mobile applications.
Remember always this in MVC architectures:
Frontend: Always call services from the backend, render the view, and capture data. Sometimes make a litle logic.
Backend: Receive the request, apply all the business logic, read and write operations in databases, and return a response preferred in json format.
Model: store data, backups, slaves, etc.
PD: If you use meteor in this example you gonna need to make a api Rest to develop the mobile application.