We Keep Coding

How to speed up react app being sent to the client Azure

In my application i have the client in one folder and the server in another. I successfully deployed the application to azure web apps, this can be found at: https://wulfdevpage.azurewebsites.net/ However, it takes nearly 15 seconds for the page to respond and render the client, (this is just the basic react-app client for now, but ill build this out further soon.) my problem is simply that it takes way to long for the server to respond with the application.
here is my folder structure
--client
- build
// - (other parts of the react app)
--server
- [other folders, like controllers, models etc.]
- server.js //entry point
in my server.js file this is how the build folder is served up.
// Set static folder
const __dirname = path.resolve();
app.use(express.static(path.join(__dirname, "public")));
if (process.env.NODE_ENV === "production") {
app.use(express.static(path.join(__dirname, "/client/build")));
app.get("*", (req, res) =>
res.sendFile(path.resolve(__dirname, "client", "build", "index.html"))
);
} else {
app.get("/", (req, res) => {
res.send("API is running...");
});
}
This works, but again, it's taking nearly 15 seconds from the initial request to the client reaching my computer to make this work. I know a simple solution would be to just move the client to something like azure static web apps but I really don't want to go this route, I'd rather keep them all in one place for convenience's sake. There simply must be a quicker way to serve up the client.

The major cause of performance of initial load issue is adding too many components into a single bundle file, so it takes more time to loading of that bundle files. To avoid this kind of issue, we need to structure our components in an optimized way.
To solve this react itself has a native solution, which is code-splitting and lazy loading. Which allows splitting bundle files into a smaller size. Refer here
The performance issue fix with some configuration changes. If you haven't done this already, please check below once
Enable HTTP/2
HTTP/2 brings major changes to our favorite web protocol, and many of the changes aim to improve performance and reduce latency on the web
Turn Off the Application Request Routing Cookie
Turn off the routing cookie in the Configuration blade to improve performance and resiliency.
Keep the App Service Always On
To prevent the idle shutdown, you can set the Always On flag in the App Service Configuration blade.
Use local cache
In App Setting create the app with a key of WEBSITE_LOCAL_CACHE_OPTION and a value of Always. You'll then have a d:\home folder pointing to a local cache on the machine and populated with a copy of your site content.
Use App Service diagnostic to fetch more details on the issue
Refer here for more info

Bokeh: change the endpoints for /static

Is there a way to change the endpoint that static JS files get served up from in Bokeh?
I have a number of bokeh dashboards that are accessed from behind a load balancer
Any request to https://myloadbalancer/{dashboard_name} is sent to the load balancer
The loadbalancer then routes the requests to the correct dashboard server based on the value of /{dashboard_name}
For any given dashboard, bokeh then attempts to access static javascript via https://myloadbalancer/static
For this to work, I need to create a new bokeh server just to serve up static files and then configure the loadbalancer to route requests to https://myloadbalancer/static to the new server
This approach is fine, until you start getting different javascript dependencies in the different dashboards
Does anyone know of a way to change the /static path of a bokeh dashboard. So that for example it reads static files from https://myloadbalancer/{dashboard_name}/static?

You can run your bokeh serve command with the option --prefix <base_path>. This will put <base_path> behind every resource requested to the Bokeh (Torando) web server, this applies also for /static resources.
Here you can find the official Bokeh documentation page.
Kind regards

Real URLS with Single Page Applications?

I was using react router for one of my projects, so react is frontend library and routes are managed by react router and backend views are in django and apis in django rest
So i was going through the react-router documentation and I came across this:-
Configuring Your Server
Your server must be ready to handle real URLs. When the app first loads at / it will probably work, but as the user navigates around and then hits refresh at /accounts/23 your web server will get a request to /accounts/23. You will need it to handle that URL and include your JavaScript application in the response.**
I was wondering how would this work with django views.

On the development server, you simply set up a route for everything that doesn't start with api/ or static/ to return your basic app.html file. Example
class AppHTMLView(View):
def get(self, request):
fn = os.path.join(settings.BASE_DIR, "app", "app.html")
with open(fn, 'r') as fh:
return HttpResponse(fh.read())
And on your production server, you configure Nginx accordingly. Something like this
...
location / {
root /var/www/example.com/static_files/;
try_files '' /app.html =404;
}
But that's not in any way specific to React, but common to all single page apps.

Why use NGINX with Meteor?

As far as I understand, Meteor is a full-stack web server, meaning you don't need another web server such as Apache or NGINX to makes it work. But from reading the guidelines on deploying Meteor, it seems like they use NGINX to serve Meteor.
Why is this?
Edit: Will there any impact if I just use the Meteor without NGINX or apache? Is it significant?

Meteor is not a web server. Especially, it cannot terminate SSL/TLS. That's why you might want nginx running in front of meteor.

Nginx placed in front of the Node.js build of your Meteor app tends to double the throughput of serving static assets (images, media files etc.) and reduce latency - see these benchmarks by #Stephan at Do I really need nginx with my Meteor/Node.JS app?
See also the recommended nginx configuration for Meteor.

Confusion about web-application ports

I have a project that is already deep in development, and there is a problem with the ports.
The Client is SPA written in backbone, that uses Sails as a server.
Problem is in the fact that Client is running in Express on port 80, while Sails is run on 1337.
I would like to host this backbone application within the Sails, not ouside the sails.
A bit more details:
When I fire the Fiddler, I am seeing requests being made to localhost:1337/get/user.
I need it to reside on port 80 as well.
Backbone is written using standard. I have app.js and main.js with all of the common folders (JS, LIBS, CSS). In other words, I have index.html that has data-main using require.js...
I have not problems running the client in separate node.js... how to run it within Sails.js?
Where do I put my index.html???

Trying to serve index.html as a static file won't work. Instead, try the following:
1. Serve your index.html from Sails
Just serve index.html as a combination of views/layout.ejs and views/home/index.ejs, which are mounted to the root / for default newly created Sails project.
2. Set up a catch-all route
In config/routes.js put something like this:
module.exports.routes = {
'/': {
view: 'home/index'
},
'/:unknownRoute': {
view: 'home/index'
}
}
This way you'll be able, for example, to use simple one-level pushstate routing within your SPA: routes like /products or /news will still give you your index.html (if you are using something more complex though, you may want to play a little bit more with your Sails routes).
3. Serve your API with a prefix
In your config/controllers.js put, for example:
module.exports.controllers = {
...
prefix: '/api',
...
}
This will let you serve your API with a prefix and have both /api/products (JSON API) and /products (your SPA) routes available.
4. Use any port you want
You can change the default port via config/local.js, even to 80 (if you don't have anything else running on 80, of course).
In production though, it would probably be a better idea to just proxy to default Sails' or any other port with Nginx, for example.