i try to host my application on AWS S3 and the static file can export to the S3 folder by export command in next.js, but when it goes to ISR, I don't know how to make it happen, i don't use vercel, i want to update the static html when the revalidate option is in our code, how to write the pre-render function and host it to a seperate serverless service, is there any way to make this happen? better have a simple example here! after set the serverless service up, how to config my next.js app to make it know that it will call the service when ISR is configured?
when i set locally in the next.js app, and run it locally, the ISR is good to go, meaning i put the pre-render function together with my ISR code, this is the way next.js document want us to do, i guess, but now, i want to host my static file in aws s3, just don't know how to set the config to make it call my pre-render function, because i want the pre-render function to host in a different servie endpoint
Related
My project with Nuxt JS is set with target:static and ssr: false.
This app need to connect to a local endpoint to retrieve some informations.
I have multiple endpoints and I need multiple instances of the app, every app must read only his endpoint.
The question is: how change the endpoint address for every app without rebuild everyone?
I tried with env file or a json file in the static folder (in order to have access to this file in the dist folder after the build process).
But if I modify the content of the env/json file in the dist folder and then reload the webpage (or also restart the web server that serve the dist folder), the app continue to use the original endpoint provided at the build time.
There is a way or I have to switch to server side rendering mode (which I would rather not use)?
Thank you!
When you use SSG, it will bundle your app at build time. Last time I checked, there was no hack regarding that. (I don't have the Github issue under my hand but it's a popular one)
And at the same time, I don't really see how it would be done since you want to mix something static and dynamic at the same time.
SSR is the only way here.
Otherwise, you may have some other logic to generate dynamic markup when updating your endpoints (not related to Nuxt) by fetching a remote endpoint I guess.
With the module nuxt content it's possible to create a folder "/content" in project directory and read json files from that directory.
After, when creating the dist with nuxt generate command, the "content" folder it's included in "_nuxt" folder of the dist and if you modify the content of the json file and refresh the webpage that read it, will take the new values.
I have some react code (written by someone else) that needs to be served. The preferred method is via a Google Storage Bucket, fronted by their Cloud CDN, and this works. However, due to some quirks in the code, there is a requirement to override 404s with 200s, and serve content from the homepage instead (i.e. if there is a 404, don't serve a 404, serve the content of the homepage and return as a 200 instead)
(If anyone is interested, this override currently is implemented in CloudFront on AWS. Google CDN does not provide this functionality yet)
So, if the code is served at "www.mysite.com/app/" and someone hits "www.mysite.com/app/not-here" (which would return a 404), what should happen is that the response should NOT be 404, but a 200 with the content being served from index.html instead.
I was able to get this working by bundling all the code inside a docker container and then using the solution here. However, this setup means if we have a code change, all the running containers need to be restarted, and the customer expects zero downtime, hence the bucket solution.
So I now need to do the same thing but with the files being proxied in (with the upstream being the CDN).
I cannot use the original solution since the files are no longer local, and httpd can't check for existence of something that is not local.
I've tried things like ProxyErrorOverride and ErrorDocument, and managed to get it to redirect, but that is not what is needed.
Does anyone know how/if this can be done?
If the question is: how to catch the 404 error provided by Cloud Storage when a file is missing with httpd/apache? I don't know.
However, I think that isn't the best solution. Serving files directly from Cloud Storage is convenient but not industrial.
Imagine, you deploy several broken files successively, how to rollback in a stable format?
The best is to package your different code release in an atomic bag, a container for instance. Each version are in a different container and performing a rollback is easier and consistent.
Now your "container restart" issue. I don't know on which platform you are running your container. If your run it on a Compute Engine (a VM) it's maybe the worse solution. Today, there is container orchestration system that allows you to deploy, scale up and down the containers, and to perform progressive rollout, to replace, without downtime, the existing running containers by a newer version.
Cloud Run is a wonderful serverless solution for that, you also have Kubernetes (GKE on Google Cloud) that you can use with Knative for a better developer experience.
in a current project I have a problem understanding (and configuring) routing within my vue.js app.
Our Setup
We have a setup, where for each Pull Request in our repos a new Snapshot Environment is created. This environment is one namespace within a kubernetes Cluster. All services in a current develop state are deployed with the new "snapshot" version of the service that triggered the CICD pipeline. To have a clear route for each snapshot environment, we use the namespace as part of the URL (https://HOST/NAMESPACE/APP/paths)
Our Problem
As you can see, the URL is highly dynamic, but currently, we could just build the container with the path and be happy. Thats our current setup. Unfortunately, we want the possibility, to deploy each and every container image on every HOST as well as every NAMESPACE, those parts are only known at runtime, not in the CICD Pipeline.
Is there any way to handle such a scenario with vue.js. I have basically every freedom to edit the app as well as the container, but can't change the way we want to host our app. Currently we build the App on the cluster and inject the NAMESPACE, which was the "easiest" way to do this. But if there is any other way, I would love to not have the build and run step together.
Thanks in advance.
I'm currently developing a simple webapp with seperated frontend (Vue) and backend (quarkus REST API) project. For now, I've setup a MVP, where the frontend is displaying some simple data which is called from the backend. To get a working MVP i need to setup CORS support. However, first i want to explain my setup:
Setup
I'm starting developing environment of my frontend with npm run serve and of my backend with ./mvnw quarkus:dev. Frontend is running on localhost:8081 and backend running on localhost:8080.
Heroku allows to run your apps locally aswell with the command heroku local web. Frontend is running on port 0.0.0.0:5001 and backend on 0.0.0.0:5000.
To achieve this setup i setup two .env files on my frontend which are pointing to my backend api. If i want to work in development mode the file .env.development is loaded:
VUE_APP_ROOT_API=http://localhost:8080
and if i run heroku local web the file .env.local with
VUE_APP_ROOT_API=0.0.0.0:5000
is loaded.
In my backend I've set
quarkus.http.cors=true
in my application.properties.
Now I want to deploy those two projects to heroku and use it in production. Therefore I setup two heroku projects and set a config variable in my frontend project with the following value:
VUE_APP_ROOT_API:https://mybackend.herokuapp.com
Calls from my frontend are successfully working!
Question
For the next step, I want to restrict it more and just enable my frontend to call my API. I know i can set something like
quarkus.http.cors.origins=myfrontend.herokuapp.com
However, I dont know how i could do this on quarkus with different environments (development, local and production)? I've found this link but I don't know how to configure heroku and my backend app correctly. Do i need to setup different profiles which are applied on my different environments? Or is there another solution? Do i need Herokus Config Variables?
Thanks for the help so far!
quarkus.http.cors.origins is overridable at runtime so you have several possibilities.
You could use a profile and have everything set up in your application.properties with %prod.quarkus.http.cors.origins=.... Then you either use -Dquarkus.profile=prod when launching your application or you use QUARKUS_PROFILE=prod as an environment variable.
Another option is to use an environment variable for quarkus.http.cors.origins. That would be QUARKUS_HTTP_CORS_ORIGINS=....
My recommendation would be to use a profile. That way you can safely check that all your configuration is consistent at a glance.
I'm having trouble setting up a development workflow that will do both of the following tasks simultaneously:
Recompile static assets (js, css) on file change. Serve these static assets. Notify the browser that the page must reload whenever assets are changed. Use react-hot-loader.
Use express to run a server which serves an API which the static assets will "consume". Have this express server restart any time my server files change.
Is the best practice to have webpack-dev-server serve the static assets, and have a separate web server serve the API on a different port? If so, the API calls in the javascript will need to specify the host and port, and will need to be changed before going to production. It seems all the tutorials online focus on #1, and don't set up an API server. Can anyone point me in the correct direction?
I'm not opposed to using gulp and browserify or SystemJS instead of webpack, but it seems that if I want to use react-hot-loader, I need to use webpack.
You can do something like this:
Create an express() proxy
Create a webpack-dev-server
Link the assets with absolute url
Start both servers.
Note: Make sure to have different ports to run both the servers.
var proxy = require('proxy-middleware');
var express = require('express');
var url = require('url');
//----------------- Web Proxy--------------------
var app = express();
app.use('/assets', proxy(url.parse('http://localhost:8000/dist/assets')));
app.get('/api/url', function(req, res) {}
app.post('/api/url', function(req, res) {}
// ---------------Webpack-dev-server---------------------
var server = new WebpackDevServer(webpack(config), config.devServer);
// ---------------Run both servers-----------------------
server.listen(config.port, 'localhost', function(err) {});
app.listen(8080);
We have been using gulp+webpack for the last year and it has been great. We have an API Gateway which only serves up one static html file(the index.html) and everything else is just REST end points. Then in the index.html we reference a css file or two and a couple scripts that load from our CDN(Cloudfront).
If you run that way in production, your local setup just needs to use the webpack dev server as your "local CDN". You are correct, your javascript will need to know what the api url is since that will change local vs production. We actually have local, dev, stage, and production - once you have it setup to work in 2 environments its not hard to add more(which is good!)
Now our index.html has some template variables that get filled in by the API Gateway when it serves it up. Similar to this:
<script>
var siteConfig = {
apiBase: '<%=apiBaseUri%>',
cdnBase: '<%=cdnBaseUri%>'
};
</script>
<script src="<%=cdnBaseUri%>/assets/js/bundle.min.js"></script>
Then you just pull in siteConfig when your react app is starting up and prepend those variables to any api/cdn calls. Swap the variables depending on your environment, and bam, you're done!
A slightly simpler approach is instead of filling in those vars when the page is served up you could do it at build time. Thats how we started but as things evolved it turned out easier to manage at run time.
BTW, I am pretty sure you can accomplish all of this using just webpack - gulp probably isn't necessary but it was easier for us at the time to use gulp for running unit tests, linting, etc.