Echo JS 0.11.0

<~>
rgxdd 159 days ago.
Hello guys,I just created a boilerplate that intergrates PostgreSQL with create-react-app through an API made with node.js/express.js and node-postgres.
If you are using PostgreSQL I would love to get your feedback in order to improve it and If the boilerplate makes it easier for your to create your applications I would appreciate if you star the repo!

https://github.com/Malldoror/react-postgres-boilerplate

tracker1 159 days ago. link 2 points
Only comments initially would be:

* rename the `.env` file, and add to git ignore file.  

* Add unit tests

* Add database initialization and versioning boilerplate logic.
rgxdd 158 days ago. link 1 point
Hey tracker1 thanks a lot for the suggestion, it's very helpful.
As I am also new to databases could you tell me more about database initialization and versioning boilerplate logic or provide me an article? 
Thanks
tracker1 158 days ago. link 1 point
I don't have any boilerplate or an article to show, but my approach is usually as follows.  These are regardless of the specific dbms, I've done it with MS-SQL and MySQL, I'd presume it should be an adaptable approach for Postres as well.

Have a directory for DB versions... this directory will then have a .js file for each version, it will export a default and optionally a rollback.

When the application first loads, it will run a pre-init db script that will first create an AppSettings key/value table, if it doesn't exist, where the key is nvarchar, and the value is json.  It will then check for a current version, setting it to 0, if there isn't a record.

The current version is compared against the directories, and if the current version is less than the directories indicate, it will get/set a *LOCK* record (mutex) in the database, then check again.  The *LOCK* will retry in a loop to set the mutex/lock record to its' own id, and after finished, delete that record.  After comparing again, it will run through each update script.

Each update script will be run, if no errors, then the version record will be updated to the current version.  If there is an error, and a rollback export exists, it will be run, and the application will log an output, and terminate.

After all updates have ran, and the lock record is cleared, the application will continue to start.  Optional: If it's a service, start the service, but return 503 responses until the database is updated.

This approach allows any number of deploys of the application/api to get the database to the current version, and the locking prevents more than one instance from trying to run updates.

It's worked out really well for me in applications I've built.  It's a bit of manual work for the setup, but after a few DB versions/releases tends to become more than worth it.  It also tends to be simpler than using some of the DB/version management tools.