Support for other ORMs such as Sequelize or Mongoose

[lgants]

Does anyone know of a fork of this project that uses Sequelize or Mongoose? I love absolutely everything about this project with one big exception: knex. Knex itself lacks support for more advanced relations (i.e. belongs to many). This functionality can be added with Bookshelf, but neither knex nor Bookshelf library to seem to be very actively maintained (as of when I created this post last merge for both was 3 months ago; compared with 5 days ago for Sequelize and 4 days ago for Mongoose). I've created a fork with Sequelize, which is getting close, but I've become stuck: https://github.com/lgants/apollo-universal-starter-kit-sequelize. Is it possible to add support for another ORM?

[larixer]

@lgants knex is well maintained. The last commit was 21 hours ago. The question is how to maintain both Sequelize and knex in the kit? How Sequilize can be added to the kit to minimize maintenance cost? And who will maintain Sequilze-related code in the kit?

[lgants]

@vlasenko Those are good questions. I'd like to contribute to the project. Unfortunately, in the process of implementing Sequelize in my fork it's become clear that it'd be difficult to maintain both. What are your thoughts on adding BookshelfJS instead? That would provide support for polymorphic associations. I could look into the implementation.

[larixer]

@lgants Yes, bookshelfJS looks better. @mairh @mitjade Ujjwal, Mitja, what do you think guys?

[mitjade]

@vlasenko I have looked at bookshelfJS before and do see some advantages, but ended up using just knex, since it offers more flexibility with what I needed.

[larixer]

@mitjade Can you use bookshelfJS for 90% code base and just go down to knex in 10% when you need flexibility. Is this possible?

[mitjade]

@vlasenko It’s been a while since I looked at this, so I am not sure right now, can take a quick look tomorrow.

[lgants]

@vlasenko it's probably worth noting that the BookshelfJS build is failing (and has been for at least a few days). There's also a notice in the docs about the library undergoing some "changes." I found an interesting article about JS ORMs/ODMs that was fairly critical of Bookshelf: https://medium.freecodecamp.org/a-comparison-of-the-top-orms-for-2018-19c4feeaa5f.

I'm going to continue implementing Sequelize in my fork - I'm hoping to finish migrating all of the existing knex models to Sequelize sometime in the next week or two. The interface for Sequelize V4 (latest) seems pretty similar to knex and bookshelf. So, that might be an option ¯_(ツ)_/¯

[larixer]

@lgants Thats happens in JS world :) However the question is still open - how to maintain multiple ORMs. Well, one option is to use some ORM abstraction layer. Similar to UI library abstraction layer, that we now have to support multiple UI libraries, such as Bootstrap, Ant Design, Ant Design Mobile, Native Base. This is just an idea, I'm not sure whether it will be practical

[cloudkompute]

https://github.com/typeorm/typeorm

[larixer]

@lgants Did you have a look on our https://github.com/sysgears/domain-schema set of packages? We are using them in cli CRUD branch now. Perhaps using domain-schema definitions plus domain-schema/knex helper will be able to do what you are looking from ORM? Because ORM solves only part of a problem. We want to have a full solution - e.g. single source of truth via domain-schema definitions and various generators - to graphql types, to SQL tables creation and queriyng via knex, UI forms generators from schema defs, object validation via schema defs.

[lgants]

@vlasenko I hadn't seen those packages. They're impressive. I especially like the ability to choose a combination of those packages. Although I fully support auto-generating sql models with graphql, I'm a bit hesitant to combine frontend UI form generation with the backend - Django's model forms caused me many headaches over the years.

Unfortunately, I'm still concerned about knex. It's definitely ubiquitous and I've personally had positive experiences with it on small projects in the past. But, the fact that so many major libraries are built on it (e.g. Bookshelf, Objection.js) suggest it's lacking some basic out-of-the-box functionality; also, that fragmentation could hurt it long-term. It's popularity also seems to be stagnating at time when node use is growing rapidly.

btw it's not my intention in anyway to be critical. I love your open-source projects. Honestly, the architecture is brilliant. And, I'm hoping to contribute in some way.

[larixer]

@lgants The popularity seems to be 60/40 in favor of Sequelize. Which is a good indicator that ideally we should support both.

[igo]

Whatever ORM will be used it's a major step forward. knex is just too low level. Adding support for Objection.js would be a simple step forward since it's built on top of knex and it could significantly reduce amount of code by removing your knex helpers. Starting with Objection is generally easy but when I tried to add it myself in packages/server/src/sql/connector.js I got error which I was unable to solve. Please try it.

[lgants]

I was able to get Sequelize working in the app on my fork (https://github.com/lgants/apollo-universal-starter-kit-sequelize). I haven't tested file uploads and I've commented out the existing code to help ppl compare the differences, but it's otherwise working. I just haven't found a good way to integrate Sequelize while also keeping knex.

[larixer]

@igo Objection.js looks interesting.

[clodal]

Coming from a Sequelize world in another boilerplate project and I wouldn't go near it as it is not well-maintained. Reading this thread had me hunting for a better alternative and it does seem like Knex + Objection might make a promising solution in my opinion

[larixer]

@clodal Great. We will start adding Objection.js as soon as we will have free hands. Feel free to contribute if you have time

[beingtmk]

@vlasenko, hi i am using objection.js in one of my projects, where i have converted the user module using objection, so i want to know how should i work on this, should i convert all the modules then create a pull request?

[larixer]

@beingtmk The way I would like to proceed with conversion to objection.js is to convert some small module first, for example counter or other small module that uses database. Then, we should review the Pull Request and make sure we do not break compatibility with existing projects and then convert all the other modules. I want to make sure we stay compatible with existing projects based on knex all the way, while we gradually move to objection.js