Upgrade deps - #258

This has been published as a new major version, sorry it all took so long. Any interest in being added to this repo so you can do things like this yourself? It looks like you folks are using this module more than me (which is not at all 😄 ).

Thanks for merging all these! And yes, I would love to be added to the repo and help maintain it and keep it up to date. We are still actively using this pkg and are planning to do so for the foreseeable future. We might have a few more tweaks in our local fork since I've put these PRs in, I'll explore if anything could be upstreamed.

Great, I sent you an invite to the organization. Let me know what username you would like me to add on npm. I'll definitely help with getting these updated to v5 and setting up the new infrastructure where hopefully things like making releases (and creating dependency update PRs) will happen automatically but it always help to have another set of eyes on it.

I am also still not sure if this adapter or Sequelize would be the better default for v5 generated apps 🤷

Same username on npm - kidkarolis.

Good question re knex vs sequelize. I suppose it's a bit of a personal choice, and I believe sequelize is probably more popular, people find ORMs like that generally easier, but personally I don't think I'd ever go back to that an ORM like that anymore, too much complexity and too many pitfalls in trying to abstract the DB that way. And in fact, I'd go as far as saying that Feathers in a way abstracts the DB already through it's services. You can find/get/create/patch/remove records and you don't really need an ORM at that point. Ofc, when things get a bit more advanced, you do need to think about validation schemas, joins, ocasionally using raw SQL for filtering bits (things that sequelize might provide, where in knex you have to build your own bits). But perhaps, feathers-knex would be a simpler choice for a generated app? Unlike sequelize, you don't need to define any schemas or anything upfront to get started, just create a bunch of knex services mapping to your tables and you're good to go, the crud just works, and you can start layering other things in as you need to. Just some thoughts.

Exactly, especially since I found ending up to always make separate queries in Sequelize as well once the tables got sufficiently large because the joins it created were too slow. That's what Feathers schema resolvers would do by default, too (and maybe improving related fetches with the more generic batch-loader). If you really wanted your own optimized SQL query then just run it in a custom service or hook.

It does feel like feathers and ORM like sequelize overlaps in a way that makes the ORM redundant (and in a good way, since feathers is not an ORM, yet it removes the need for one). Ofc, I haven't used sequelize in this context, but I did have great success with knex so far. I do think knex is more of the "feathers" way. Maybe it should be the recommended and documented option, with FAQs or examples of common use cases (or a series of blog posts I suppose). I'll need to think a bit more about it. Might be worth seeing what the peeps on the Slack might say of why they use sequelize and see if actually the same things might be even easier with knex.. (validation schemas is one thing that comes to mind that sequelize does out of the box, but again the feathers way is more to do it at the hook level, and again with the upcoming schemas that will make sequelize further redundant).