I have the current configuration:
a GUI team develops the Angular app in a separate project and builds all TypeScript stuff to produce the final UI app.
another team has Vert.x java library in the server app to do REST service and produces a final fat jar.
I wonder what's the best approach to deliver GUI and backend in one shot:
Is is ok to have 1 jar for backend and Gui (say a directory call "app") both in the same folder? Can vert.x access resources outside its jar?
Do I have to put GUI in the same maven project where my vert.x REST services are developped, run the "ng build" commands from maven, and package all in one jar?
I'm a bit confused here.
Any of you are in the same situation, what's your advice on this?
Thanks
All it's upto you how do you wanna deploy it on production ;)
First approach
You can create one fat.jar to deliver everything in it -> so it will include angular static build files (under webroot) and then all your vert.x related code.
Second approach
You can create one fat.jar just with angular static files exposed using vert.x and also you can integrate authentication (cas/saml) in the same and another fat.jar will have rest implementation (connecting to database or WebService consumption ). So you will have two fat.jar and it will be best if you are planning for clustering and for hazel cast structure.
We have already tested both approaches and both are working great but Right now we are following second approach !!
Related
I am a Spring Boot newbie. I'd like to initialise a project which consists of:
A console application that acts on command line arguments so the JAR files could be later used in scheduled tasks.
Consumes a RESTful service
Logging
Which package dependencies should I choose in Spring Initializer? Apart from the necessary packages, are there any libraries that are optional but make development easier?
Depends on how you want to consume the restful service, but you may not need any extra starters, the core spring-boot-starter that you get when you just hit "Generate Project" and is usually implied with all the common starters like -web, -security, .. has logging and dependency injection and is all you need to create a jar that can easily be started with java -jar
However, it does not come with RestTemplate which is a common way to build rest clients in spring. For that you'll need to manually add a dependency on org.springframework:spring-web like you can see examples for in https://spring.io/guides/gs/consuming-rest/
But you can as well use other rest client libraries if you like them better.
There is also Feign that can be used as rest client and it's available from the initializer, examples at https://cloud.spring.io/spring-cloud-netflix/multi/multi_spring-cloud-feign.html - have not tried it and I'm not sure how much extra cloud dependencies will be added when you add the starter.
I also like having Lombok in all projects but that's preference. The obvious sounding choice of DevTools doesn't give you much benefit in a console application but is great for live reloading of web servers.
[...] so the JAR files could be later used in scheduled tasks.
sounds like you're trying to create a library / module of a larger application. You don't need an application that works standalone for that though so maybe https://spring.io/guides/gs/multi-module/ is good to read for you. Difference for libraries is that you don't need the spring boot plugin for maven/gradle which can package a standalone jar, just the dependency management.
I have a question related to best practice folder structure for a WEB-APPLICATION (Mobile compatible as well). I know this is opinion based question. But I did not find any good solution over internet. So I thought it will worth to post it here.
Since my project is Java based backend. So I created a dynamic web project from Eclipse with maven functionalities.
So my folder structure is just as follows.
SampleProkject
|
|-----src
|
|---- main
|----java
|----resources
|----webapp
|
|---- test
|---java
|---resources
My all Java backend related code goes to src/main/java
and All HTML, CSS and JS goes to src/main/webapp
Similarly all my test classes for java goes to src/test/java
From Java perspective everything is fine but problem comes when I try to places my angular files.
Since I am using npm to install all required js files and frameworks. I placed package.json inside my webapp. So node_modules is also being created inside my webapp. Which is I do not want because node_modules is just for dependency so I do not want to expose it over HTTP. So I need to place my package.json outside of webapp. But then I can not use node_modules in index.html file because it can not access files out side of webapp.
Also I do not want to place my test cases (Karma.conf.js and Jasmine test suits) to webapp. So what I did I place those to src/test/javascript.
Now the thing is I have to access all my angular code and node_modules from src/test/javascript and also from webapp/index.html file.
Please suggest a best approach. I think several Java developer who are using angular with nodejs for UI, facing same issues.
Note:
Actually I am looking for a good project structure with maven, java,
nodejs and angular. Which also include Java and Angular unit testes as
well.
There are many maven archtypes and yeoman generators available. But if want a good base application using angular as front end and spring/java as backend, go see http://jhipster.github.io/
Our team is writing a server-client application where the frontend is an Angular.js single page application which uses a Spring MVC java backend. The backend serves the application files and the REST endpoints used by the browser end. We are using Maven as the main build system for the application.
We like to take advantage of require.js and r.js to minify the app at the end, and we are also using client side dependency management. Currently we are using bower to download Javascript libraries required but it doesn't feel right to me to download client dependencies to src/main/webapp since this is a source folder. However in order to avoid rebuilding the whole frontend module each time something changes in the client files, this seems the only sensible way to us. This way we can start a web server and it will automatically pick up changes without restart, but as i said this doesn't fit Maven's folder layout.
I'm experimenting with Webjars which seems a better choice in our Maven oriented build and dependency management. Because in Servlet 3.0 containers webjar resources are provided automatically on the server container path it's very easy to use and manage them. It's also possible to create a require.js config to refer to libraries contained in webjars since they are on the webserver path the same way if they were static files, the serving is being done transparently in the client applications point of view.
My only problem is that i don't know how could we achieve r.js minification with this layout, since the source files are in jar files r.js cannot access them. Also the require.js config refers to the runtime server paths which are simply not there in build time.
I see that webjars now have some integration with Require.js + Play Framework but we are not using Play just simple Spring MVC in our case. I really hope there is a way to handle this case because i like the Webjar way of client dependency handling.
You need an asset compiler / pipeline in your build process. There are probably many options but the one I know of is wro4j: http://alexo.github.io/wro4j/
Typically on a Java project using Maven, you place client-side source files in src/main/webapp. This directory includes your html, css, scripts, images, etc.
However, many grunt projects tend to place these files on the root. It's as if Grunt was designed with the idea that your project is the client-side application, not part of a large server-side project, such as using Java with Spring.
Given a Java project using Maven, where would be the best place to put your web-related source files?
Do you place them in src/main/webapp?
Do you make another directory altogether, such as src/web, and then on a build, copy everything to src/main/webapp?
My goal is to make the client-side build tool as transparent as possible. I guess the ideal case is to simply work from src/main/webapp as I have been doing all along - this is pretty unobtrusive to the way my project is currently setup.
However, if I work from src/main/webapp, I know that I will need to distinguish between src and build directories somehow anyway. I'm sure my html files can stay where they are, but there's definitely going to be a conflict of interest here with javascript and css files, and maybe images too.
Does it make sense to literally have a 100% separate source folder from src/main/webapp? Is there a way to do continuous building/copying/syncing of the application as you modify files, from src/web to src/main/webapp? Will this be inconvenient and cause frustrations and problems? Is it slow?
I would like any advice on the subject. Thank you.
Option 1: Put UI resources in src/main/webapp:
This is a quick-n-dirty solution popular on Github. It helps to keep example projects small and concise. In this case, usually people put the package.json, bower.json, Gruntfile.js and .bowerrc in the maven project's root directory, where the .bowerrc says to install components into src/main/webapp/bower_components.
If you have a task that minifies/transforms resources, the transformed resources can go to a new directory like src/main/webapp/dist. Then use something like grunt-usemin to make your app use the resources in the dist directory.
If your application will use a security framework (like, say, Spring Security), you might want all your resources in src/main/webapp so that the security framework can regulate access to those resources. However you can still achieve this using Option 2 by having a grunt task that copies the necessary resources into src/main/webapp.
Pros
Common approach on GitHub. Keeps everything in one project.
Cons
The version of files getting served by your server is a copy of those in src/main/webapp, so changing a file in src/main/webapp isn't immediately reflected in your deployed app. To get hot reloading, you need to use something like grunt-contrib-* stuff.
Frontend and backend code is all mixed together. Harder for two different teams to work on the code base.
Option 2: Put UI resources in a separate project:
You can achieve better project organization by keeping the UI and backend in completely separate projects. In this case the UI and the maven project would likely be sibling directories.
Then when deploying to a server, you either:
deploy both projects separately (call them myproject-ui and myproject-services). The javascript in myproject-ui makes RESTful service calls to myproject-services/**.
Use a grunt task to copy necessary resources to src/main/webapp, then deploy your (one) project.
Pros
The backend and the frontend are separated as much as possible
The frontend maintains the workflow and directory structure found in most client-side example apps, as you mentioned
"Deploying" the UI is a simple matter of creating a symlink from your server's deployment directory to you UI source code. Changing any UI code is automatically reflected in the deployed app.
You can have several different UIs deployed simultaneously (maybe you have myproject-admin-ui and myproject-user-ui). You could hit either one simply by visiting
http://localhost:8080/myproject-admin-ui
http://localhost:8080/myproject-user-ui
I am working on a full-stack spring-java based web app. The app is current divided between two projects each of which produce a war file on build. One project (call it UI) serves as the front-end of the app. UI doesn't have much business logic in it. Mostly HTML templates, and JS/CSS and other resources. The other project (call it Server) carries a whole lot of weight in terms of providing auth, business logic, DB services, REST API for external world etc.
I am running into quite a few problems especially while making security work throughout the app given UI project has no direct way to authenticate a user or checking user roles etc. UI relies on invoking a REST OAuth2 password flow to Server to authenticate. So authentication itself works fine but I am having a tough time checking user access roles or any other fine grained permissions within any code in UI project.
Before I dig a whole lot deeper and try to make this all work, a couple of questions for the gurus here:
a) Is this design one of the acceptable ways to build web apps?
b) Are there any gotchas that I should be aware of if I attempt to bundle the two projects within one war?
I hope this is to the point but let me know if you need any more details, and I will be happy to add color.
Try another concept for separation:
Module 1 = core business logic -> produces jar file on build
Module 2 = web -> produces war file on build
Module 2 depends on module 1. All security stuff goes to module 2.
Hope it helps.