When I mentioned 'defining entities', this could be an ORM entity - however it could also be a custom entity using Knex query builder under the hood - all depends on the project and the complexity/requirements.
As I mentioned above, we lean heavily on PostgreSQL (along with PostGIS), so we generally steer clear of using any ORM to 'define' our data model.
I'm a big fan of Objection (pre-TypeScript), and now MikroORM (TypeScript) - both of which are built on top of Knex (which I've been using and loving since it's inception).
I really like the use of the Unit of Work/Identity Map patterns bound to a request context with MikroORM though - certainly gives it a leg up over TypeORM/Primsa in my opinion.
And yes, we've been watching and playing with GraphQL too (PostGraphile & Hasura in particular due to their favoring of PostgreSQL and PostGIS support) - however it's a complete paradigm shift and there are certain edge cases in many of our projects that aren't very conducive to GraphQL (although things could have changed, it's been a few months since I've last used either of the above).
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Oh, my bad, with "I always start by defining a rough data model" I supposed you were working data-first, which I've to mention that this is not bad, you can profile your DB better this way and then perform migrations from DB to code instead the reverse way.
For the GraphQL and your edges... well you don't need to use the same stack for the entire project, that's the fun in services/micro-services, that you can build each one with the tools you feel better for the job :D
You can create a dataLoader for those cases and resolve pointing to a REST if this fits better to you (for example)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
When I mentioned 'defining entities', this could be an ORM entity - however it could also be a custom entity using Knex query builder under the hood - all depends on the project and the complexity/requirements.
As I mentioned above, we lean heavily on PostgreSQL (along with PostGIS), so we generally steer clear of using any ORM to 'define' our data model.
I'm a big fan of Objection (pre-TypeScript), and now MikroORM (TypeScript) - both of which are built on top of Knex (which I've been using and loving since it's inception).
I really like the use of the Unit of Work/Identity Map patterns bound to a request context with MikroORM though - certainly gives it a leg up over TypeORM/Primsa in my opinion.
And yes, we've been watching and playing with GraphQL too (PostGraphile & Hasura in particular due to their favoring of PostgreSQL and PostGIS support) - however it's a complete paradigm shift and there are certain edge cases in many of our projects that aren't very conducive to GraphQL (although things could have changed, it's been a few months since I've last used either of the above).
But GraphQL is certainly on our radar :)
Oh, my bad, with "I always start by defining a rough data model" I supposed you were working data-first, which I've to mention that this is not bad, you can profile your DB better this way and then perform migrations from DB to code instead the reverse way.
For the GraphQL and your edges... well you don't need to use the same stack for the entire project, that's the fun in services/micro-services, that you can build each one with the tools you feel better for the job :D
You can create a dataLoader for those cases and resolve pointing to a REST if this fits better to you (for example)