Is there any way to limit handlers to the development server only (in App Engine)?
My scenario:
In dev, I have my js and css split into many files, and it's easy to debug and watch the flow like this. I have a small script which compiles these resources into 2 files (1 js and 1 css) and creates a copy of index.html which includes only these 2.
There are different paths to the original vs. compiled HTML and resources, and I'd like the production version to only include the compiled ones. Any ideas?
In the app.yaml you could skip some files and prevent them from being uploaded, while they are still accessible when working locally.
Now if you want to check if your app is running locally or in the production server you should check the SERVER_SOFTWARE variable:
import os
PRODUCTION = os.environ.get('SERVER_SOFTWARE', '').startswith('Google App Engine')
DEVELOPMENT = not PRODUCTION
Then depending on which templating language you are using you will have to pass one of the above or both of them, and based on them load either the minified versions or the actual sources.
You can examine the environment at runtime to determine what mode you're in. (Lipis posted the details.) And you can use that to dynamically construct array fed to WSGIApplication to maps requests to handlers. If you're in development mode, add development-mode-only entries to that array.
Related
So I get the difference between next build && next export and next build && next start from here.
In short, next build && next export generates a fully static app which does not require a server to host, whereas next build && next start starts a server which renders and serves content.
My question is then, how is next build && next export different from just using React? Seems both approaches generate static files (html, css, js). If I want to optimize SEO, is next export better than using react?
There are many ways to create a React web app. And there are many types of them as well.
Client-Side Rendering
Noticeable toolchain: Create React App
Everything is done on the client side. You send a blank HTML file and various JS bundles to the browser. And the browser parses the bundle and renders contents on the HTML and presents it to the users.
It takes less effort to set up so it best suits small projects.
This is properly what you were referring to when you said: "just using React".
Server-Side Rendering
Noticeable Toolchain: Next.js
Most of the works is done on the server-side. When a user requests to view a page, the server generates the need HTML file dynamically with static contents in it. Then, it sends the file to the user together with JS bundles for interactive content. The browser then attaches those JS to the HTML and present it to the users.
It requires far more effort to set up compared to Create React App. It best suits mid to large projects.
Static Site Generator (Prerender)
Noticeable Toolchain: Gatsby
Similar to Next.js, but instead of generating the HTML dynamically. It generates ALL OF THEM at build time and just sends it to users upon being requested.
This property has the best performance overall. But it can become a nightmare when the site is growing bigger and have hundreds of pages. Building a large, static Gatsby site takes ages to complete.
p.s. Next.js is also capable of generating static sites, but why don't you pick the right tool which is designed and optimized for generating a static site in the first place?
Answering my own question after I tried the following:
Launch a create-next-app then do next build && next export
Launch a create-react-app then do yarn build
Compare out/index.html in the next app and build/index.html in the react app
I found out that out/index.html actually contains all the static contents, whereas build/index.html contains nothing but <script> elements in its <body>. Everything including paragraphs (<p> elements) are later generated (or hydrated) when opened in the browser.
So in conclusion, even though both Next and React can be used to generate static site (SSG), Next is still better for SEO purposes since the contents are already in the html file.
Next.js can be used as static side builder (in the case you are referencing) which means it will generate all of you html at the time of build and along provide some performance features.
React(if not used on server) will always just have 1 HTML page which then loads of all your App(or chunks if you are code splitting) when the client requests it.
If you are not familiar about the concept read more on Static side building.
For SEO purposes using Next.js with either static or server side rendering would be the best approach since everything is prebuilt and easily accessible by robots(Although Google bot should already read javascript apps as well).
I am new to Next.js and I was looking at the Next.js deployment options https://nextjs.org/docs/deployment and I run into the following (and I guess most commonly used) options:
deployment using a Node.js server: https://nextjs.org/docs/deployment#nodejs-server
deployment using Static HTML Export: https://nextjs.org/docs/advanced-features/static-html-export#how-to-use-it
I am wondering, what is the actual difference there and how to better detect which approach should be used?
I believe Next.js' official documentation covers this properly: Advanced Features: Static HTML Export
Still some of the points that I feel should be highlighted:
Statically exporting a Next.js application via next export disables API routes (because they can't be prerendered to HTML).
next export is intended for scenarios where none of your pages have server-side data requirements (you will have to fetch all data client side or during build).
next export causes features like Incremental Static Generation/Regeneration to be disabled.
I18n routing is not supported (in static HTML export) as it requires Next.js' server-side routing.
what is the actual difference there
As the name suggests, when you are statically exporting your app, you are simply building it into a bunch of HTML, CSS, JS files, which can be hosted with ease anywhere.
On the other hand, when you are deploying on a Node.js server, you can use some more features (as mentioned above). Although ultimately HTML, CSS, JS will be sent to the browser, but before sending you can specify your logic.
You can define your APIs without a need to write the backend of your app separately. You can server-side render your page, you can fetch data, and add it to your page so that the requests are not made from client side (a necessity if you don't want to share where are you getting data from).
Also when your code is running on a Node.js server you can use the default next/image loader, it optimizes the images that you serve. In static export you need to use third party libraries [or (generally paid) loaders], or maybe manually optimize them.
which approach should be used
This is something that you need to figure out yourself. If your hosting provider restricts you to use only static assets, then you are forced to deploy site by statically exporting the HTML.
If your provider has option to deploy Node.js apps, then you need to check various parameters, like if you actually need a server to run your app, do you have some code that cannot/should not be executed on client side, ...
Is there a way I can easily change a variable within a React app dependent on its current stage in an Azure DevOps release pipeline? As an example, say I have three stages set up (dev/QA/production) and I want a client ID within the app's auth config to be swapped out for each environment. How can I "detect" which environment is currently being used in order to select the appropriate ID? I'd prefer to only need to run a single build task and use a single artifact for each pipeline stage, rather than rebuilding at each stage (if at all possible).
If you don't want to bundle for each stage separately you’ll need a server providing the values you want to make available to the client.
This can be done by rendering the HTML on server side. Here’s a short example template:
<script>
window.valueToExpose = <%= JSON.stringify(value) %>;
</script>
The expression <%= JSON.stringify(value) %> will be executed by your server’s template engine. (Expression can look different based on your template engine)
The sever generated HTML can look like that with value = "Hello World":
<script>
window.valueToExpose = "Hello World";
</script>
In you React application you can access window.valueToExpose.
First off, I'd expect that your application is deployed to different hosts/CNAMEs depending on environment.
If you don't want to provide some sort of environment identifier at the time of deploy/build which is baked into your code, then inspecting the URL could be one approach. Downside of this is you are now hard coding URL patterns into your scripts and mapping those to environments. You decide on the trade-offs.
Second, I agree with Lucas' answer that you'll need an external source for configurations you can pull from at runtime.
If you live in the M$ ecosystem I am not sure what's available but from from other stacks I can recommend spring cloud config or configrd.io which can both externalize, serve and provide additional config management features.
When I run 'hugo server --watch', I can visit the site by localhost:1313
But this is a http connection and is marked unsecured in chrome (or firefox), hence the equation is not rendered, they remain latex codes. When upload to server, e.g. github.io, it is rendered.
Is there a way to make mathjax render equation in server --watch mode? Thanks,
There is no way of making hugo server use https at present. I assume you are using a CDN to load MathJax - instead you could install it locally in your Hugo site's static folder (Hugo docs) and edit your Hugo theme to point to your local copy of the script.
Local installation has the advantages that you will be able to run MathJax locally over http, and that your your site will be more secure. (If you use a CDN without a hash attribute in the script tag, or with a browser that doesn't support hash attributes, then the CDN can change the JavaScript that runs on your site.) However, local installation has the disadvantage that people will have to download MathJax from your site instead of from the (probably much faster) CDN.
If you want to put the time and effort into it, then you could use a tool like Gulp or Grunt to set up a build process where you use a local version of MathJax on your local machine, and the CDN version on your production servers. But this will be overkill for most people.
Not sure how to tell my point where, hopei make it as clear as possible.
I tried running some apps that are using Polymer and/or AngularDart, including:
https://www.dartlang.org/docs/tutorials/forms/#about-the-slambook-example
http://bwu-dart.github.io/users
the apps works very fine, one I run them using, "Pub serve" (Aka Ctrl+R from Dart editor), but once I run from the Dartium using the file "URL" things are not working well!!
I got an answer in Dartisans' google+ community the web server is a mus (https://plus.google.com/u/0/110229866977286723923/posts/UAH8ez51S53), is this means neither Polymer nor AngularDarrt are pure client side! by pure client side I mean can run from the file URL, without a web server.
I was thinking to make small app, for learning and testing, and packing it into 2 forms:
1. as Android APK using Android web view, but as server is required
2. as Chrome app
but having both need a web server, and the JavaScript conversion (build) is not acting similar to the output using the file URL, i.e. not completely as required, I got stuck!
Note: I'm using Windows 7, 64x, latest edition of Dart (Dev. 1.6.0), and latest edition of both AngularDart and PolymerDart.
any thought or idea pls
You need a server to serve static content because there are a lot of features with those libraries that are pulling your resources in dynamically. This isn't a Dart or Polymer issue, this is a browser security feature. By default, you can't make AJAX calls to your local machine. Pub serve is handling this for you, but you can chose any server you want to serve your local assets.
Contrary to some of what the other answers are saying, you don't need to build your Dart code when you're in Dartium. Dartium has the Dart VM built in for that very reason.
AFAIK you only need a server, but you need to generate some code, your development code can't directly go to your server, you need to do something like pub build, to make the code ready to be served directly.
You don't need a server, but you do need to build your code. pub serve does this automatically (and keeps on doing it as you change your code, so it's perfect for development), but to be able to use a file:// url, you need to run pub build first, and use the files generated in the build directory.
This is the same issue as discussed here https://stackoverflow.com/a/25248166/217408
and here I tried to reproduce and wasn't able.
After running pub build you can open the build output using a file URL just fine.
Polymer and Angular are definitely pure client side (if you want to use them this way).
That you can't run the Dart code without running pub build first is a bug in DI (used by Angular.dart and bwu_polymer_routing. DI currently requires some code generation that is done only when pub build or pub serve is run.
See also
- https://github.com/angular/angular.dart/issues/1344
- https://github.com/angular/angular.dart/issues/1276
You can try to use the workaround mentioned in issue 1276
Module.DEFAULT_REFLECTOR = new DynamicTypeFactories();