Does anyone have any idea, why these three points are introduced and how we can implement this if we decide to separately deploy spring boot and SPA?
Calls to / serve static assets (from the front-end), which should not
be cached by the browser.
Calls to /app (which contains the
client-side application) and to /content (which contains the static
content, like images and CSS) should be cached in production, as
those assets are hashed.
Calls to a non-existant route should forward
the request to index.html. This is normally handled in the backend
through ClientForwardController.
They explain how you should handle the HTTP requests that point to the static parts.
2 first points may be configured in your reverse proxy for example.
Last point is a configuration of the RP but also of the router part of your js framework.
Related
There is a stack that uses Next.js as the main dependency. Each page is an independent application. An index page uses www.domain.com/_next/*.js so its base path configured as a / root. Also, another application has a base path same as the homepage but a little difference which is using a query string in the URL.
if the URL is www.domain.com/ then it is a homepage, if the URL is www.domain.com?key=value it means it is a different page and the request will be redirected to the associated application by the Nginx and Load Balancers. So, the problem is:
the main page is serving its statics under the www.domain.com/_next/*.js
the page that parses query strings is serving its statics under the same location same as MainPage www.domain.com/_next/*.js
These applications have different statics created by different pipelines also there is a cache mechanism. Is there a way to solve that conflict just by making some configuration in Next.js?
You can use the basePath settings introduced in Next.js 9.5 (https://nextjs.org/docs/api-reference/next.config.js/basepath)
But your .next/ folder would be changed, something like yourdomain.com/yourbasepath/_next
If you want to change only the .next/ folder location assetPrefix can be used. I think you can take a look at assetPrefix https://github.com/vercel/next.js/issues/5602#issuecomment-673382891
Or we can setup the custom server, for example the Express and custom the base asset path via Express (https://expressjs.com/en/starter/static-files.html)
app.use('/static', express.static('public'))
P/s: The asker choose the assetPrefix solution
I have existing app that runs on Heroku. It's a simple web app with no background jobs or database.
Basically it has three endpoints. One of them serves the HTML, the other is POST endpoint for communicating with backend and third is GET endpoint that renders error HTML content as well.
Now the frontend is not single page application and the goal is not to be one. It's just HTML page with a form and some links. The front end can be used without Javascript.
My questions are:
Can I re-use existing ExpressJS code? I was thinking about importing route callbacks and use them inside the "functions".
I know there is Firebase hosting that can serve static content. However, as I mentioned the server can respond with HTML content so I'd need traditional routing (such as /error url for rendering HTML error). In my ExpressJS app I use .ejs templating so I'd like to load the template and render it.
Can Firebase be set up so the "backend" (functions) can be placed on my own domain? I'd like to call relative URLs from my index file (like that POST endpoint) instead of using Google Firebase URL.
I'm really just trying to find out if my use case can fit the Firebase infrastructure. I think it's a good candidate since I need the web app to respond infrequently and it's not really demanding, not many people would use it. This is also my hobby project so I'm trying to minimize costs.
To answer your questions:
Yes you can, but keep in mind some things are limited. In my case, I had tried to use multer library for multipart forms but didn't work and had to resort to using busboy instead. To use an Express app for a function endpoint, you simply just pass your app as the onRequest function parameter like so: functions.https.onRequest(app).
Docs:
https://firebase.google.com/docs/functions/http-events#using_existing_express_apps
The hosting is for static files only. You can't use that with .ejs. Unless, you're thinking to use that as a proxy to your Express app..
Yes, you can set custom domains so you can use your domain(s) instead of default ones. Reference: https://firebase.google.com/docs/hosting/custom-domain
From your project's Hosting page, enter the wizard for connecting a custom domain:
If you have only one Hosting site, click Connect domain.
If you have more than one Hosting site, click View for the desired site, then click Connect domain.
Enter the custom domain name that you'd like to connect to your Hosting site.
(Optional) Check the box to redirect all requests on the custom domain
to a second specified domain (such that yourdomain.com and
www.yourdomain.com redirect to the same content).
Click Continue to initiate the validation process.
I have a web-application using nginx as a reverse-proxy and using the express framework as my backend in node.js. I am confused which is the web server. I use react, so the application features client side rendering, and nginx holds these files should it make a difference.
according to developer.mozilla.org
On the software side, a web server includes several parts that control how web users access hosted files, at minimum an HTTP server. An HTTP server is a piece of software that understands URLs (web addresses) and HTTP (the protocol your browser uses to view webpages). It can be accessed through the domain names (like mozilla.org) of websites it stores, and delivers their content to the end-user's device.
&
A web server first has to store the website's files, namely all HTML
documents and their related assets, including images, CSS stylesheets,
JavaScript files, fonts, and videos.
Taking this into consideration, I would say that Nginx is the web-server since it holds the html file. However, I really am not sure. Is it one of the two, both or is it a grey-zone?
Web servers provide web pages(HTML) with CSS, JS files that are required to render those pages. In your case, NGINX acts as a web server since it serves with HTML files.
NodeJS has a built-in HTTP module which supports to work with HTTP. We can use NodeJS to create Web servers since they use HTTP. But in this case, NodeJS acts as an API which exposes an HTTP interface to interact with it.
I am creating a web application where I want to display hundreds of images. I am using NodeJS with the Express Framework.
How do I send images from server to client?
Edit: If I place all images in the public directory, are they automatically send to the browser if the page is rendered or are GET requests generated in time if those images are needed?
Are you required to use express? Usually, static files are better served using a proper web server (like nginx or apache) along with your node/express application or some kind of cdn. In the client you could configure how your images are requested to avoid loading all of them at the beginning, either only downloading on demand or doing non-blocking requests
So I understand the fundamentals of isomorphic rendering with React / Node, but I'm confused on how I would fit Apache or NGINX into my landscape.
Typically, with a client-side page I would just serve the static content from Apache or NGINX and the client-side page would make AJAX calls (which are reverse proxied through Apache or NGINX) to Node. Node would serve up the data and the page would change accordingly.
Looking at an isomorphic page with React, the page is initially rendered on the Node server and changes are served up to the client from the server. Can I still use Apache or NGINX to load balance and reverse proxy my requests?
As an example, I would have one Node instance serving my API and one Node instance for rendering React and serving it to the client. In this example, could I load balance, reverse proxy my calls, and serve my .js and .css bundles from Apache/NGINX? In this example the user would access www.example.com/ - that would first go to the Apache/NGINX which would reverse proxy the call to the Node server which would render the page and serve it up to the client. Then, on the page the client would click some button and access www.example.com/api/test and that would also go to Apache/NGINX and reverse proxy over to the second Node instance, which would server the data back to the client. Or should that button click go back to the first Node instance (where rendering takes place) and that Node instance calls the second Node instance to get the data, renders the new piece, and serves it back to the client?
Basically I want an isomorphic app with all the benefits of having Apache or NGINX in front of my Node servers. Is that possible and/or best practice? If not, what is the ideal landscape for an isomorphic app so that I can still maintain all the benefits of Apache or NGINX as my entry point to my webapp?
Yes, that should all work fine. The React/Node server just renders html, and is reverse-proxy-able like any other html backend.
And yes, using a reverse-proxy/loadbalancer in front of your servers is a great idea, if you're planning on running something at scale.