About your back-end stack (typeORM, type-graphQL, postgreSQL), is there a particular road you'd encourage (or discourage) one should take to set up a easily maintainable, scalable and stable back-end?
I've experimented with using custom typeORM-repositories, and defining the datamodel in a single place (so a single file), to be used by both typeORM and type-graphQL using TypeScript decorators. I'm not sure if this level of abstraction is still maintainable in the long term, for larger production-grade applications.
Any other advice to give?
Thanks in advance.
edit: The goal of the thing I'm trying to set-up is a side-project, so experimenting is perfectly fine.
Some time ago I thought to myself "mhh, all of these repositories with the same bland crud options are getting old, why not just DRY it with generics" - a thought I wish I never had. Right now I am sitting on top of a project built using generics repositories to all my entities, I also have generics resolvers for graphql.
It is all good until the data model varies just a little bit and the relationships become more advances.
So I would suggest trying generics out - but do not rely upon it.
My own structure is this
entities
inputs
types
Entities are classes that use both typeorm and typegrapql decorators for creating the queryable and the domain models.
My inputs are my "DTOs". My own rule is that any mutation must not have an entity as input.
Types are the home of my more general return types, inputs, and scalars.
For example, I have created a Generic paging result that takes in an input extending an entity. The purpose of being able to have a method for all my queries with the same structure when it comes to paging, sorting, and filtering.
Like I said in my main post - I hope to soon provide some code as examples, I just need to have something that isn't for a client. Aka my boss needs to give me some free hours :3
So far I haven't tried out generic repositories, since I already experienced that having a custom repository for every entity is much more powerful than having a single repository usable by all entities.
I'm a real fan of customizability over reusability, something that is a pain in the rear to set up and maintain, but really rewarding in the long-term, to prevent that a piece of software totally lacks freedom and susceptibility to change. All the testing frameworks that exist nowadays will perfectly keep an eye on any breaking changes, if set up correctly.
And I sincerely hope your boss acknowledges your need and gives you some time to prepare some code examples, I would love to look into those!
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.
About your back-end stack (typeORM, type-graphQL, postgreSQL), is there a particular road you'd encourage (or discourage) one should take to set up a easily maintainable, scalable and stable back-end?
I've experimented with using custom typeORM-repositories, and defining the datamodel in a single place (so a single file), to be used by both typeORM and type-graphQL using TypeScript decorators. I'm not sure if this level of abstraction is still maintainable in the long term, for larger production-grade applications.
Any other advice to give?
Thanks in advance.
edit: The goal of the thing I'm trying to set-up is a side-project, so experimenting is perfectly fine.
I will say this - generics MIGHT be a solution.
Some time ago I thought to myself "mhh, all of these repositories with the same bland crud options are getting old, why not just DRY it with generics" - a thought I wish I never had. Right now I am sitting on top of a project built using generics repositories to all my entities, I also have generics resolvers for graphql.
It is all good until the data model varies just a little bit and the relationships become more advances.
So I would suggest trying generics out - but do not rely upon it.
My own structure is this
Entities are classes that use both typeorm and typegrapql decorators for creating the queryable and the domain models.
My inputs are my "DTOs". My own rule is that any mutation must not have an entity as input.
Types are the home of my more general return types, inputs, and scalars.
For example, I have created a Generic paging result that takes in an input extending an entity. The purpose of being able to have a method for all my queries with the same structure when it comes to paging, sorting, and filtering.
Like I said in my main post - I hope to soon provide some code as examples, I just need to have something that isn't for a client. Aka my boss needs to give me some free hours :3
So far I haven't tried out generic repositories, since I already experienced that having a custom repository for every entity is much more powerful than having a single repository usable by all entities.
I'm a real fan of customizability over reusability, something that is a pain in the rear to set up and maintain, but really rewarding in the long-term, to prevent that a piece of software totally lacks freedom and susceptibility to change. All the testing frameworks that exist nowadays will perfectly keep an eye on any breaking changes, if set up correctly.
And I sincerely hope your boss acknowledges your need and gives you some time to prepare some code examples, I would love to look into those!