I am build an application using Angular2 as front end framework and spring boot as backend framework.
One of the seniors in my team insisted on using JSP as templates for my components in order to avoid rendering any unauthorized views.
Is that really nessecary? I saw many applications which are implemented using angular or other front end frameworks but it did not render the templates in backend, is it a good practice? isn't authenticating the requests is enough?
Also would not that be a problem for performance?
From my point of view I think JSP will prevent us from using the potentials of Angular, any help or documentation on that subject would be much appreciated.
Short: No, JSP is not necessary.
Long: One has to realize where which part runs. JSP on the server, Angular in the browser. I assume your senior colleague is concerned about displaying unauthorized data - but that is not the concern of Angular. Angular is basically just the View, and, perhaps, Controller. But it has to get the data from the server - which is usually done over some REST service. And it is the duty of that service to serve only data the user is allowed to view. So you can implement your View/Controller part in Angular, putting all the views (event the restricted ones) in, and then implement proper security into your server-side data service.
No, it's not necessary to use JSP in Angular 2.
It's correct that JSP allows you to protect the template itself from unauthorized access, but in our case it's not really a bad thing to happen from the security point of view, as access to the template without the data itself is not something dangerous; The data of course must be protected w/ your own security/authentication to prevent unwanted access to it.
Related
I have an application in which UI is rendered on the server-side using Thymeleaf and the backend is in Spring Boot.
Now, we have a requirement to combine this application with another react application. So, it should be like micro frontend architecture.
For this, I am evaluating the framework Single-SPA and seems like a good option when we have separate frontend projects and we need to combine them in one.
Is it possible to integrate the existing SSR pages with Single-SPA?
This should be possible with single-spa-html as long as there is no JavaScript that is dynamically created. Another limitation is that single-spa-html doesn't process <script/> tags due to browser security. If your application can meet those requirements, it should be able to interop with single-spa-html.
single-spa-html allows providing a template asynchronously, so a fetch or ajax call could retrieve the microfrontend template from the backend. Then the corresponding JavaScript is included in the microfrontend instead of script tagged in.
You can also see an example of enhancing a static html mfe with JS here: https://github.com/filoxo/single-spa-html-with-js-example/
Note: I believe we discussed this on the Slack channel but I want to share here for the benefit of the wider single-spa community.
I've been studying the difference between single page apps and multi page apps, and I think I have good view how they differ. Single page app starts by loading a single html page, and then it does never again fully refresh the page or override the original, unless the application is otherwise refreshed (browser refresh etc.) For example, the angularJS seed project: angular-seed has an index.html file. This file is the single page, that the server would send to front-end, and after that, all the other (possible) pages will be send asynchronously under the hood by using AJAX. So if you create app just with the angularjs seed, it is always going to be just a SPA application, am I right?
How in practice would you then create a multipage application with angularjs? Wouldn't you need multiple angularJS applications then? Would you have to have a separate routing for each of those angularJS applications? And why would one want to make multipage application for angularJS? Because one could always use the first index.html just as a shell, without real content, and then have separate container-pages for different pages. Could it be said that angularJS multipage app would be an application, that would just contain many SPA angularJS applications? In SPA, can you use the browsers' back-button, in order to go back to last view?
Yes, you've got the idea of SPA and MPA right.
Angular.js enables you to create SPAs but does not force you. In an MPA, I would not speak of multiple Angular applications since you would have just spread Angular.js modules over multiple HTML pages. The page flow or routing logic would then be in Angular.js controllers, in plain hyperlinks or in the backend on the server.
There might be reasons to not put a whole application under Angular.js. Maybe the authentication part of a web application might be Held separately for some reasons...
In SPAs you definitely can use the browser's back button. You just have to implement that somehow. Twitter solves this Problem by coding the state of its web application into the URL - if you're using Twitter, you might have noticed the symbols (#!) in the address bar.
im trying to create a Single Page Website with DurandalJS in the frontend and Laravel as the Backend. Do you think this is a good Idea?
If yes how would I do the following:
What would your recommendation for the basic interaction between both frameworks be?
Would you rather have all the computation done in JS instead of Laravel sending calculated and styled returns?
How Do I setup Laravels controller in order to only get dynamic Data for, say a Div, instead of a whole page?
How can I adjust the browser URLs?
I hope I was specific enough, thank You in advance.
Laravel does not actually care about what framework you use to build the Frontend. Laravel is just a framework that helps you build your application with. It gives you great advantage with respect to the time spent and effort.
You can use any frontend framework that you want to build your app with. I have actually not used Durandal, but from the first look of it here is my opinion.
Durandal is built on top of jQuery, knockoutJS and requireJS. It also has a MV* architecture in place with support for eventing as well. So you could basically define routes on Laravel and initiate the communication between both the frameworks through events and ajax. Again this completely depends on the functionality that you are building.
In the overall flow of your app, consider Laravel as a Model that just gives data from a source to your app and Durandal as your views and controllers. This way, it will keep your data flow cleaner and easier to build. Computation of your functionality depends on how important and secretive the app is. If there are functionalities/implementations that you need to be secretive about, you can keep it on Laravel and just send computed data to Durandal. If its a web app that you are building, then keeping all implementation on the JS is just a right click away from knowing what and how you have built it. One can just see how the implementation is done just looking at the Javascript source of the web app. If you are building Mobile Device App, then the case is different.
Take a look at Restful Controllers. Will give you an idea on how to setup controllers to return only data. But if you need to return the div itself, then you can make use of the Basic Controllers of Laravel to perform them.
You can setup cleaner routes for the browser URL's. Take a look at Laravel Routing
I am developing a RESTful backend using Spring framework. All the services are accessible through HTTP request methods (GET, POST, PUT, DELETE).
Could you please tell me what can the best combination of frameworks for front end?
Is it best to use SpringMVC or some other framework like Backbone is good enough?
If I am using SpringMVC for REST backend and also SpringMVC for front end then won't it be extra work doing same things again first for backend then for front end?
And most important I am confused about how can do the session management using front end?
Any help will be appreciated!
If you are looking into to make a SPA (Single Page App) make sure that you take a look at AmpersandJS -> http://ampersandjs.com/
Templates
Since you said "server-side" GUI, maybe you are thinking more along the lines of a template engine for creating HTML? This isn't really restful, but can be MVC like if you are forwarding from your Controller classes.
But PLEASE keep in mind that it would be a very BAD idea to try and generate XML or JSON data for consumption by RESTful clients (ajax) with either of these. Just say no to JSON creation from a template engine!
JSP is pretty much the standard for Java EE at the moment, or is most widely used. All you need is a compliant server, such as Tomcat/Jetty.
http://www.oracle.com/technetwork/java/javaee/jsp/index.html
Thymeleaf It looks a lot cleaner than JSP, and has the added benefit of not allowing all the pitfalls that can happen with a JSP (and there are a lot).
http://www.thymeleaf.org/
JavaScript:
When you say you are creating a RESTful backend, most people would make the conclusion (and rightfully so) that you are trying to develop a JavaScript MVVM client/GUI.
Kendo UI has a complete set of GUI widgets and MVVM framework that is specifically designed to work with a RESTful backend. But it's a paid for API.
http://www.telerik.com/kendo-ui
YUI3 (Yahoo User Interface) has a variety of widgets as well, and I've seen a lot of jobs requesting this. It has the advantage of being free/OSS as well. Older version are deprecated.
https://github.com/yui/yui3/wiki
knockout.js has been my favorite for MVVM engines that I've actually had experience working with. And it's simple to learn, in my opinion.
http://knockoutjs.com/
Angular.js Also free/oss, and works well with other GUI APIs.
https://angularjs.org/
I would suggest you to consioder Sencha Ext JS for front-end, it is one of the best framework and will work with RestFul back-end.
this is a good question, but I don't think there is a server-side framework out there specifically built to use a REST server backend. I think you could use Spring-MVC / Spring-Boot to get a good headstart, but you might also want to look into Rails or other Ruby any other modern web framework technology.
I used to utilize MVC 3 Razor engine to render pages. Sometimes I had to use AJAX calls to transfer Razor-rendered HTML and inserting it into the page using JQuery. As new project is starting, we do consider to utilize MVC 4 Single Page Application framework which is new to us. I took the first glance at it which left me with mixed feelings:
On the one hand it implies all your data are transferred by JSON and client does all the job to render them and encode some UI-related logic which is great for server and network performance. On the other hand the client (HTML+JavaScript) becomes much more heavy with a bunch of magic strings and hidden relations inside it which seems to be hard to maintain. We got used to VS intellisense, type-safed .NET server code to render pages which we have to exchange for client scripts and Knockout binding statements in case of SPA.
I wonder are any prons and cons of using SPA comparing to Razor, other that this obvious one I've mentioned here? Thanks
Razor is a server based technology where SPA (Single Page Application) is an architecture approach used on the client (web browser). Both can be used together.
From a high level, SPA moves the rendering and data retrieval to the client. The web server becomes a services tier sitting in front of the database. An MVC pattern works best when using SPA. Frameworks like Knockout.js and Backbone.js can be used for this. The net results is a rich responsive desktop like experience.
To achieve this you'll need to be a descent javascript programmer or be willing to learn javascript.
Yes it's moving business requirements from C# into javascript. In Visual Studio there is limited intelli-sense for javascript. To have confidence in your javascript you'll need to lean on unit testing. The up side is the rich user experience (think gmail or google maps).
I think it sounds like you are already fairly well apprised of most of the trade-offs here; you'll have reduced network load with SPA, and will shift a measure of the processing to the client. You will, however, increase the complexity of your code, and make it slightly harder to easily maintain the system (simply because of the increased complexity - not due to any architectural problems inherent in SPA).
Another thing to keep in mind is compatibility. The reason I mentioned a "false choice" in my comment to your question is that to keep the site usable for folks with Javascript disabled, you will still need to provide regular, whole-page views. This is also a good idea to do for the sake of SEO; a crawler will browse your site as a user with JS disabled, and can then index your site. The site should then handle such incoming URLs properly so that those with JS enabled will find themselves in your SPA looking at the same content (as opposed to being dumped in the "no JS" view unnecessarily).
There's something else I'll mention as a possibility that might help with the above, but it breaks the ideals of an SPA; that is, using Ajax-loaded partials in some places, rather than JSON data. For example, say you have a typical "Contact EMail" form on the site; you want that to load within the context of the SPA, but it's probably easier to do so by loading the partial via AJAX. (Though certainly, yes; you could do it with a JSON object describing the fields to display in the e-mail form).
There will also likely be content that is more "content" than "data", which you may still wish to load via partials and Ajax.
An SPA is definitely an interesting project, and I'm about to deploy one myself. I've used a mix of JSON and partials in it, but that may not be your own choice.