reke592 · June 11, 2023 09:36
diff --git a/web-notes.txt b/web-notes.txt
 -- Disclaimer: not a standard rule. just a collection of ideas/experience while doing a fullstack development task --

 identify the configurations that can affect the application restart, put those dynamic configuration in database. (eg. email config).
 identify the common functions and store them inside `commons` folder.
 create commons/errors to contain all the possible application errors we can throw, include the http status code.
 avoid returning plain text in api response, much better to use a JSON object eg. { message: 'foo' }.
 centralize the route definitions in one file, so we can see the possible conflicts when using route params.
 when using external libraries always create a wrapper function, so we can inject our custom feature.
 always propagate the error by throwing, centralize the catch so we can easily control the application output.
 run heavy task in background (separate process), configure (optional) a socket endpoint to monitor the status.
 never include any business logic rules in controller, always have a use-case builder function, it is more readable with DI pattern support.
 never put everything in controller, implement a message bus, emit the event after business logic call to all subscribers.
 folder by feature is great for low-coupling high cohesion source codes, but we also need to consider how big is the project.
 folder by feature is great for UI development
 store access token in memory, use cookie for refresh token, on page-reload revalidate using the refresh token
 on specs gathering always ask how the client want to receive the results, is it immediate (realtime) or eventually (on specific schedule).
 when dealing with repositories, we need an object mapper to freeze the results, also to have a finite domain model schema.
 when overriding response value, we need to put them in controller.
 never use a websocket library alone, always use a redis store so it can run in cluster / load balancers.
 avoid relying too much in SQL ORM libraries, we can use them for normal select and update, but for complex queries, use stored procedure.
 apache,nginx,express,php etc... anything in server configuration, always hide the version / server details.
 use pm2 to monitor nodejs service, it can also run node process in cluster, auto-reload the service when it crash or reached the memory limit.
 always configure log-rotation, archive them properly.
 search for updated list of security headers
 when using reverse proxy setup in nginx/apache, we need to upgrade the connection for websocket endpoints, in normal http it close the connection after transmision, having it not upgraded the client will use http everytime we emit on socket.
 when assigning server hostname, we can use the hosts file to test the name resolution in local eg. 127.0.0.1 sample.domain.com.
 use separate file for each host configuration, store them in directory ./sites-enabled.
 always test the new configuration before restarting any service. unless you want some adrenaline rush. jk. ALWAYS test before restart.
	-- Disclaimer: not a standard rule. just a collection of ideas/experience while doing a fullstack development task --

	identify the configurations that can affect the application restart, put those dynamic configuration in database. (eg. email config).
	identify the common functions and store them inside `commons` folder.
	create commons/errors to contain all the possible application errors we can throw, include the http status code.
	avoid returning plain text in api response, much better to use a JSON object eg. { message: 'foo' }.
	centralize the route definitions in one file, so we can see the possible conflicts when using route params.
	when using external libraries always create a wrapper function, so we can inject our custom feature.
	always propagate the error by throwing, centralize the catch so we can easily control the application output.
	run heavy task in background (separate process), configure (optional) a socket endpoint to monitor the status.
	never include any business logic rules in controller, always have a use-case builder function, it is more readable with DI pattern support.
	never put everything in controller, implement a message bus, emit the event after business logic call to all subscribers.
	folder by feature is great for low-coupling high cohesion source codes, but we also need to consider how big is the project.
	folder by feature is great for UI development
	store access token in memory, use cookie for refresh token, on page-reload revalidate using the refresh token
	on specs gathering always ask how the client want to receive the results, is it immediate (realtime) or eventually (on specific schedule).
	when dealing with repositories, we need an object mapper to freeze the results, also to have a finite domain model schema.
	when overriding response value, we need to put them in controller.
	never use a websocket library alone, always use a redis store so it can run in cluster / load balancers.
	avoid relying too much in SQL ORM libraries, we can use them for normal select and update, but for complex queries, use stored procedure.
	apache,nginx,express,php etc... anything in server configuration, always hide the version / server details.
	use pm2 to monitor nodejs service, it can also run node process in cluster, auto-reload the service when it crash or reached the memory limit.
	always configure log-rotation, archive them properly.
	search for updated list of security headers
	when using reverse proxy setup in nginx/apache, we need to upgrade the connection for websocket endpoints, in normal http it close the connection after transmision, having it not upgraded the client will use http everytime we emit on socket.
	when assigning server hostname, we can use the hosts file to test the name resolution in local eg. 127.0.0.1 sample.domain.com.
	use separate file for each host configuration, store them in directory ./sites-enabled.
	always test the new configuration before restarting any service. unless you want some adrenaline rush. jk. ALWAYS test before restart.
No results found