Echo JS 0.11.0

<~>

tracker1 comments

tracker1 1 day ago. link 2 points
I do think that the thunks library, and using async functions should have been included.  Saga and Observable libraries are heavy and generally take quite a bit of setup, where with thunks + actions you can often get the job done pretty easily, and have a simpler codebase.
tracker1 1 day ago. link 1 point
I think the one case for Redux missed is when you need to share the same data/state across disparate components that may be in differing routes or different sections of a screen(overlaps with prop drilling).

For example, I have common subheaders in different screens on an app I am working on.  The routes are different, but that component is sharing state across the different routes and parent components.
tracker1 1 day 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.
[comment deleted]
tracker1 3 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.
tracker1 5 days ago. link 1 point
I really like the async generator approach to streams.  It just feels more natural.  The agh composition utility is also kind of interesting for transforms.
tracker1 7 days ago. link 1 point
Axios is probably fine, however fetch is in all modern browsers, and using it directly is generally a better option.

ORM in a dynamic language is generally more boilerplate than it is worth, and doesn't integrate nearly so well at the API level for type checking or input consistency.  It adds a lot of work for almost no advantage at all.  It also creates layers of abstraction and complexity that make it harder to onboard developers and more costly to support in the long term.
tracker1 7 days ago. link 1 point
Interesting questions towards the end on potential paid/billed package solutions.  Not completely sure how this will correlate to Isaac's political ideology.
[more]