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 the client how they 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.
 we might get confused sometimes while designing a feature,
  eg. job_post, applicant, job_application.
  - job_post and applicant can be considered as plain model
  - job_application on the other hand is more likely a service, because it has the business logic that connects the applicant and job_post
  - much better if we have separate controller and repository per each model and service.
 when designing data encryption, each aggregate entity MUST NOT share the same encryption key.
  - eg.
  - store the private key in database, we can also encrypt the private key in database, as a result there is no way to decrypt the data using the plain database record.
  - each user must have a unique key IV for encryption
  - store the decrypted value in result cache
  - just incase the user want to delete all the private details related to his account, we simply remove the key IV and cache entry.
 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.
 use Postman for API documentation and testing, most of the time we can spot the security issues by testing in plain request.
 in backend, eval is evil.
 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.
 system batch file / shell script is your friend.


 on team discussion, always consider the posibilities that someone might not yet familiar in the tech-stack that we use.
 google is your friend, avoid mastering everything, they always update the technology, look for the documentation/manual.
	-- 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 the client how they 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.
	we might get confused sometimes while designing a feature,
	eg. job_post, applicant, job_application.
	- job_post and applicant can be considered as plain model
	- job_application on the other hand is more likely a service, because it has the business logic that connects the applicant and job_post
	- much better if we have separate controller and repository per each model and service.
	when designing data encryption, each aggregate entity MUST NOT share the same encryption key.
	- eg.
	- store the private key in database, we can also encrypt the private key in database, as a result there is no way to decrypt the data using the plain database record.
	- each user must have a unique key IV for encryption
	- store the decrypted value in result cache
	- just incase the user want to delete all the private details related to his account, we simply remove the key IV and cache entry.
	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.
	use Postman for API documentation and testing, most of the time we can spot the security issues by testing in plain request.
	in backend, eval is evil.
	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.
	system batch file / shell script is your friend.


	on team discussion, always consider the posibilities that someone might not yet familiar in the tech-stack that we use.
	google is your friend, avoid mastering everything, they always update the technology, look for the documentation/manual.