My application has two separate parts, back-end in Java (Spring boot) and front-end in Vuejs.
I can simply deploy the JAR for my back-end code where I need to, and that's it for deployment.
But when it comes to deploying the Vuejs app, I can do something similar and just put the compiled Vuejs application in the proper path in a Java Spring boot application and that will be all for the front-end too.
It just doesn't seem right to me to put that application in Spring boot when it doesn't really have to do anything with it really other than for deployment (Maybe I know nothing like Jon Snow).
Also, when its put under a Spring boot application, manual URL editing doesn't work.
This app doesn't do anything on its own, it fetches all its data from the back-end app.
So what are my options here, can someone please guide me in the right direction?
Do I just setup a nodejs server and deploy the Vuejs app in that? I am not sure how that works, or whether should I even be doing that for a production application. And if so, where do I start with setting up nodejs?
It makes sense to deploy it together with spring, and it's very common practice, at least from my experience with Angular (which I suppose would be very similar to VueJS).
You don't need to have 2 servers running. You just let Spring server your HTML/js/CSS files, which helps you avoid any problems with CORS.
I am not really sure what 'URL manual editing', do you mean by navigating the web page by editing the URL? I don't see much use cases there tbh and I would guess that is only a matter of few settings.
In gradle - I would set up a build task (not sure if task is correct word, 2 build.gradle files, each for FE/BE, the BE would depend on FE), the FE would be run when BE is run, it creates static HTML/js (in my case from angular, but it should be similar for Vue) and BE task adds the output to the classpath of the java application so that Spring can register the HTML and serve it to you.
You could use Docker to create a Dockerized version of your Vue.js app and then you can deploy this onto a cloud service provider such as AWS (e.g. EC2).
Check out this link for a basic guide https://v2.vuejs.org/v2/cookbook/dockerize-vuejs-app.html
My approach is to deploy front-end and back-end separately.
You can use web-server to proxy requests to Vuejs or Spring boot.
For example, if you use Nginx, you can use this configuration to pass requests
# pass root request to index file
location / {
root /front_files/;
index /index.html;
}
# pass requests to static files
location ~ ^/(js|styles) {
root /front_files/;
}
# pass requests to back-end
location /api/ {
proxy_pass http://127.0.0.1:8080/;
}
Related
I'm trying to bundle ReactJS and Spring Boot API together and build one fat jar. In every tutorial I read, I'm told to put the localhost API URL as a proxy in package.json of the React app like below.
"proxy": "http://localhost:8080"
As I obviously don't have PROD deployment experience with this, is this the way to go when you are deploying in PROD? Else, please guide me in the right direction. I couldn't find the answer anywhere.
Also, any cons in doing so in a medium sized project with two developers? Appreciate any input.
The "proxy" field should only be used in development environment when the Webpack dev server is first in line(to enable the Hot-Reload feature)
Here is a guide from 2018:
spring + react guide
regardless there are two main way of hosting the react app:
inside the spring boot Jar a static resource(you can use frontend-maven-plugin to run yarn/ npm again see the guide),
the advantages of this method is security, you don't need CORS enabled to serve the page.
the disadvantages is convenient this solution require more code, also the spring boot server handles UI serving to the client that requires extra calls to the server(spring first approach)
the other option is to host it in a hosting service like amazon S3 and then it will be hosted not in spring but in s3 and will be the first in line(UI first approach), you will need to enable CORS in spring boot app, but this is a more continent solution.
ps. I would read some guides first, it would help you with general understanding
We're using Websphere to host a series of applications for us:
We have an API that's hosted at the root, written in Java
We have an Angular application hosted at /admin
We have another Angular application hosted at /marketing
My concern is about deep-linking. If a user is at /marketing/products/1, and they refresh their browser or share the link, I need the server to send that route to the correct Angular application so it can be generated correctly.
In a simpler setup, where the Angular application is living at the root, I would use the Java application's web.xml file to redirect traffic to "/". But in my current scenario, I need traffic for the marketing site to go to "/marketing", not just to "/". Just like a deep-link from the admin site would need to go to "/admin".
Furthermore, the base URLs for these Angular applications are subject to change, and we also plan to add additional Angular sites to this same server. So I'm really looking for a solution that can work dynamically and have the server redirect to the first "slug" in the URL rather than matching specific directories.
Any ideas? (And please excuse and correct any misconceptions I've demonstrated above -- I currently know very little about WebSphere)
I can see a couple possible ways forward.
You could still use the error-page directive in web.xml, but specify the URL of a servlet in your application that could do the inspection manually and issue a redirect as appropriate. How the list of context roots is provided to your app will differ based on how it's packaged, but it could be done using files, environment variables, or JNDI entries in server.xml.
If the URLs could be changed, the Angular apps could be changed to use HashLocationStrategy in their routers which would sidestep the error page. It doesn't seem likely that that's the case but I'll put it here to get it out of the way.
You could consider splitting each Angular app into its own .war file and configuring the context root in the webApplication element in server.xml. Then redirecting to / in web.xml would work since that / is relative to the context-root.
We ended up combining those separate Angular applications into 1 so that WebSphere could direct everything to "/" and Angular routing could handle everything from there.
Encountered a requirement in our team when trying to migrate a WebSphere application into Tomcat and deploy onto Pivotal Cloud Foundry to have same application to connect to two different databases which have entirely same schema with different data, essentially having same application code deployed in different paths and be able to connect to the databases based on the URL being called for accessing the application.
Currently, we handle this situation in Websphere by using the deployment script to deploying the application into two servers and give the different database details in JNDI and access the application using the server names.
We use Jenkins to deploy the application onto PCF.
Tried to use maven to deploy on to different context paths which did not help and have ended up in the loop, Have anyone encountered a situation like this, Any thoughts would be appreciated.
I think there are a number of ways you could handle this.
Modify your application so it's aware and let's you pick. Perhaps have a query parameter to select or /dev/blah goes to one DB and /test/blah goes to another.
Push the same application twice, but bind different databases and routes to each app.
Attempt to run two instances of the same app code inside Tomcat in one app on CF.
Of those, #1 is fine but would probably require code changes. #2 would be my choice as it's very quick to do, #3 would be a lot of work because you'd be fighting against the Java buildpack, which is not recommended.
To accomplish #2, you would do the following:
Push your app code as app-A.
Bind the database service.
Map a route with a context path like my-cool-app.example.com/app-a.
Start your app.
Repeat the same for app-B, but use a different database and route/path (i.e. my-cool-app.example.com/app-b)`.
If you are deploying a WAR file, you will need to tell the Java buildpack to deploy your app on a context path (it should match the route context path you set).
cf set-env my-application JBP_CONFIG_TOMCAT '{tomcat: { context_path: /app-a }}'
https://github.com/cloudfoundry/java-buildpack/blob/master/docs/container-tomcat.md#common-configurations
If you're using Spring Boot and a JAR deployment, you'd need to set server.contextPath=/app-a.
Hope that helps!
I have no idea if it is possible but I heard that the best practice is to create a frontend project and a backend project as two independence projects. To do that, I should use Nginx, right? But how exactly do that and how exactly is it works?
I just create an angular2 project with node.js and start the server to listen to for example 80 port.
Then I create a java project with jetty and start the server to listen to for example 90 port.
Then, should I in some way create Nginx project to merge frontend and backend? I need help cause I'm afraid I can't understant how to do that.
It looks like you're mixing up a few things here:
In general it would make sense that your project is either written in JavaScript, and is running in Node.js, or written in Java (or a JVM language) as a Servlet, in which case it will run inside a Servlet Container like Jetty or Tomcat.
A web server like nginx or Apache httpd can be placed in front of the backend service in order to handle static content, provide caching, security, load balancing etc.
I'm trying to figure out how to deploy an Angular.js app to a Weblogic server and am getting stuck. The goal is to have a Java Servlet running a REST API to communicate with the weblogic server while the Angular app serves up the front-end.
Typically, I used a gulpfile to build my Angular application and bower to manage the dependencies. I can't figure out how to fit the Java Servlet into the build though, and what to do about deploying the app to the weblogic server.
I read that grunt and bower can be used to generate Maven files which would then be installed as artifacts on the local repository, but it isn't making much sense to me. Has anyone done something similar to this before and have advice?
Oops. all right!?
I'm currently having to develop applications in AngularJS to be used in an application server. Specific tasks that the Gulp can provide, I will be flawed if i try to say something as use Grunt (grunt-contrib-war), but on the issues architecture're, i created e install 2 aplications to the weblogic, usually with CrossOrigin defined between them. therefore its development is separated, Service layers and consumption layer.
In a larger scope could consider using:
Service-web
Service-oauth
Service-rs
ApplicationA
ApplicationB
P.S .: Searching in npm to found: https://www.npmjs.com/package/gulp-war