San Song Daddy :): May 2023

3 ways to speed up your nx react webpack app

By Errong Leng – 06 May 2023 – View online →

Photo by The Cleveland Museum of Art / Unsplash

When it comes to user experience, a website’s loading time is one of the deciding success factors. The patience of visitors is steadily decreasing. Most of them will abandon a site if it doesn’t load within 3 seconds. For a business that means lost sales, leads, and opportunities. It’s a real sales killer.

In this post, I will share you 3 ways to speed up your web site loading time if it is build via nx, webpack and react.

Lazy-loading components with Suspense

lazy lets you defer loading component’s code until it is rendered for the first time.

import { lazy } from 'react';  const LazyComponent = lazy(() => import('./YourComponent.js'));    const UseLayComonent = () => {    return <Suspense fallback="loading">      <LazyComponent />    </Suspense>  }

Do not declare lazy components inside other components.
Instead, always declare them at the top level of your module.

For example, you are using react router, you might import all the components and use them as render component per route in your entry file. You might have lots of routes. But for the first initial load of an app, header, footer and root or home content are the most import parts. All other routes, we can defer loading them. By doing so in my recent app, the main.js file reduce its size from 3.6M to 1.2M.

use CompressionWebpackPlugin

@nrwl/react set up a default webpack configuration for your app. the build executor of this package does not compress the build assets by default.

module.exports = {    plugins: [      new CompressionPlugin({        threshold: 8192,      }),    ],  };

with the above webpack config, Only assets bigger than 8192 bytes are processed. We can custom @nrwl/react webpack config like below:

const nrwlConfig = require("@nrwl/react/plugins/webpack.js");  module.exports = (config) => {    nrwlConfig(config);    if (config.mode === "production") {      config.plugins.push(new CompressionPlugin({        threshold: 8192,      })    }    return config;  };

Then after run your app build, you will a .gz file generated for the assets size are bigger than 8192 size.

use expressStaticGzip

Provides a small layer on top of serve-static, which allows to serve pre-gzipped files. Supports brotli and allows configuring any other compression you can think of as well.

in case you are using express to serve your react web app, you can use expressStaticGzip.

use optimization. splitChunks

in case the vendor.js is too big, we can think of split it into multiple small ones. Modern browser are supporting parallel resource loading. Compare a single 10M vendors.js which takes about 5 seconds, I managed to split it into 3 smaller ones. The final webpack.js code:

	const nrwlConfig = require("@nrwl/react/plugins/webpack.js");
	const CompressionPlugin = require("compression-webpack-plugin");
	const HtmlWebpackPlugin = require("html-webpack-plugin");

	module.exports = (config) => {
	nrwlConfig(config);
	if (config.mode === "production") {
	config.plugins.push(
	new CompressionPlugin({
	threshold: 8192
	})
	);
	config.plugins.push(
	new HtmlWebpackPlugin({
	template: "index.html",
	scriptLoading: "module"
	})
	);
	config.optimization = {
	...config.optimization,
	splitChunks: {
	...config.optimization.splitChunks,
	cacheGroups: {
	...config.optimization.splitChunks.cacheGroups,
	mui: {
	test: /[\\/]node_modules[\\/]@mui/,
	name: 'vendor.mui',
	chunks: 'all',
	priority: 15
	},
	fortawesome: {
	test: /[\\/]node_modules[\\/]@fortawesome/,
	name: 'vendor.fortawesome',
	chunks: 'all',
	priority: 20
	}
	}
	},
	}
	}
	return {
	...config,
	};
	};

view raw webpack.js hosted with ❤ by GitHub

use webpack-bundle-analyzer find the split points

Visualize size of webpack output files with an interactive zoomable tree map.

I found mui packages consist 45% of the build out main.js asset. so I split it out in the above code as a cacheGroup.

Notes: set different priority value for each cacheGroup, if you don't specify it in cacheGroup, it will default priority and only the last cacheGroup config will be used.

use HtmlWebpackPlugin

he HtmlWebpackPlugin simplifies creation of HTML files to serve your webpack bundles. This is especially useful for webpack bundles that include a hash in the filename which changes every compilation. You can either let the plugin generate an HTML file for you, supply your own template using lodash templates, or use your own loader.

Please push HtmlWebpackPlugin to your app's webpack configuration. Make sure you set scriptLoading to "module". @nrwl/react webpack config does not use HtmlWebpackPlugin by default. The reason why I added it because I want split vendors.js will be injected into build out assets index.html. If We don't use this plugin, even though CompressionWebpackPlugin can compress the build assets, The split vendor.js files will not be loaded in the index.html whilc would lead to your app not up.

References

lazy – React

The library for web and native user interfaces

CompressionWebpackPlugin | webpack

webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.

webpack

how to do LDAP paged search via spring-ldap?

Post, Code and Quiet Time.

how to do LDAP paged search via spring-ldap?

By Errong Leng – 04 May 2023 – View online →

Photo by Josiah Ferraro / Unsplash

When an LDAP client is accessing a server across a slow connection, or if the client suspects that the result set from a given query may be very large, the client should be able to retrieve a result set in small pieces. The Simple Paged Result extended control allows this type of retrieval by allowing a one-way walk through a result set. Options on this control allow the client to set the initial page size and reset the page size with each subsequent request to the server.

The Simple Paged Result control is also used to access all of a large results set when there is a server-side administrative limit to the number of items returned from a query. For example, Active Directory servers have a default server-side limit of 1000 entries as the maximum number of results that are returned in a single request. If the results of a query exceed this limit, the Paged Results control is used with a page size equal to or less than the server-side limit in order to retrieve all of the results of the query.

The interaction between client and server is as follows.

The client sends the server a search request with the Simple Paged Results control with an empty previous Enumeration Key, also known as a cookie, and the initial page size. The server then returns the number of entries specified by the page size and also returns a cookie used on the next client request to get the next page of results. The client then issues a search with the cookie included (optionally resetting the page size) and the server then responds with up to that number of entries.

Paged results are indicated as a control on the ldap_search_ext function call. Use ldap_create_page_control to construct this control, and then call ldap_search_ext to add the control. This control structure must then be added to the list of server controls in the ldap_search_ext call. When the server returns the first page of results, it includes the resume cookie in the controls field of the SearchResultDone message. The client must then extract the cookie from the search result by retrieving the server controls by using ldap_parse_result and parsing the control with ldap_parse_page_control. The client then uses the cookie in the next call to LDAP_create_page_control to retrieve the next page of results.

now you know why you need to do paged search. so how can we do that in your spring boot java application?

use PagedResultsDirContextProcessor

DirContextProcessor implementation for managing the paged results control. Note that due to the internal workings of LdapTemplate, the target connection is closed after each LDAP call. The PagedResults control require the same connection be used for each call, which means we need to make sure the target connection is never actually closed. There's basically two ways of making this happen: use the SingleContextSource implementation or make sure all calls happen within a single LDAP transaction (using ContextSourceTransactionManager).

show you the code:

	import java.util.ArrayList;
	import java.util.HashMap;
	import java.util.List;
	import java.util.Map;
	import java.util.Objects;
	import javax.naming.directory.Attributes;
	import javax.naming.directory.SearchControls;
	import lombok.extern.slf4j.Slf4j;
	import lombok.val;
	import org.springframework.beans.factory.annotation.Autowired;
	import org.springframework.beans.factory.annotation.Value;
	import org.springframework.ldap.control.PagedResultsDirContextProcessor;
	import org.springframework.ldap.core.ContextSource;
	import org.springframework.ldap.core.DirContextOperations;
	import org.springframework.ldap.core.LdapTemplate;
	import org.springframework.ldap.core.support.AbstractContextMapper;
	import org.springframework.ldap.core.support.SingleContextSource;
	import org.springframework.stereotype.Component;

	@Component
	@Slf4j
	public class LdapRepositoryImpl implements LdapRepository {

	@Autowired
	private LdapTemplate ldapTemplate;

	@Autowired
	private ContextSource contextSource;

	@Value("${spring.ldap.page-size}")
	private int pageSize;

	@Override
	public List<Map<String, Object>> paginationSearch(String filter, String[] returningAttributes) {
	SearchControls searchCtls = new SearchControls();
	searchCtls.setSearchScope(SearchControls.SUBTREE_SCOPE);
	searchCtls.setReturningAttributes(returningAttributes);
	searchCtls.setCountLimit(pageSize);
	PagedResultsDirContextProcessor processor = new PagedResultsDirContextProcessor(pageSize);
	List<Map<String, Object>> result = new ArrayList<>();
	// ldap connection can't keep alive
	// set single context source for each pagination search
	// to avoid connection reset
	ldapTemplate.setContextSource(new SingleContextSource(contextSource.getReadOnlyContext()));
	do {
	try {
	List<Map<String, Object>> subResult = ldapTemplate.search("", filter, searchCtls, new AbstractContextMapper<>() {
	@Override
	protected Map<String, Object> doMapFromContext(DirContextOperations ctx) {
	try {
	Attributes attributes = ctx.getAttributes();
	Map<String, Object> vm = new HashMap<>();
	for (String attr : returningAttributes) {
	val value = attributes.get(attr).get(0);
	vm.put(attr, value);
	}
	return vm;
	} catch (Exception e) {
	log.error("Oops! Map From Context Exception", e);
	return null;
	}
	}
	}, processor);
	subResult.removeIf(Objects::isNull);
	result.addAll(subResult);
	} catch (Exception e) {
	log.error("Oops! Paged Search Exception", e);
	break;
	}
	} while (processor.hasMore());
	return result;
	}

	}

view raw LdapRepositoryImpl.java hosted with ❤ by GitHub

use SingleContextSource

you have to keep the target connection never closed, otherwise you will get exception when you try to fetch the second paged objects.

avoid connection reset

I encountered a weird issue after the ldap paged search app deployed. The paged search worked well only in the first hours after it started. Then all the further paged search will got connection reset error from LDAP server. I finally figured out the root cause. The reason is that SingleContextSource does keep the target connection never really closed. but a connection to LDAP server can't keep alive all the time, it is not same as SQL database connection.

As a workaround, I used below code to make a new SingleContextSource every time when the service needs to do a paged LDAP search.

        // ldap connection can't keep alive          // set single context source for each pagination search          // to avoid connection reset          ldapTemplate.setContextSource(new SingleContextSource(contextSource.getReadOnlyContext()));