We generally build most of our applications around PostgreSQL, so I always start by defining a rough data model (after going over business/workflow requirements with those involved) so I can start fleshing out a database schema via migrations (tables, views, triggers, functions, etc).
After that I'll create the entities to interface with the above - which are then used to construct services containing the core business logic. In most cases we're exposing a REST API, so I'll then move onto defining routers, middleware, input validation and other HTTP related stuff (e.g. cookies, output serialization, etc).
Depending on the complexity of the UI/UX, we may have someone working on specific components before the above is ready - but I've always found UI developers to be more productive when they have a concrete API to interface with.
The initial "MVP" is generally very loose in terms of validation and work flow, but will be tightened down as we iterate and receive feedback.
That being said, we're a small team that likes to spend less time planning every detail in favor of getting something functional in front of the client so we can start iterating towards where we need to be.
I've lost count the amount of times we've spec'd out projects to the nth degree (based on requirements from many meetings), only for the requirements to be switched up when it finally gets into the hands of the actual users.
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
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)
We generally build most of our applications around PostgreSQL, so I always start by defining a rough data model (after going over business/workflow requirements with those involved) so I can start fleshing out a database schema via migrations (tables, views, triggers, functions, etc).
After that I'll create the entities to interface with the above - which are then used to construct services containing the core business logic. In most cases we're exposing a REST API, so I'll then move onto defining routers, middleware, input validation and other HTTP related stuff (e.g. cookies, output serialization, etc).
Depending on the complexity of the UI/UX, we may have someone working on specific components before the above is ready - but I've always found UI developers to be more productive when they have a concrete API to interface with.
The initial "MVP" is generally very loose in terms of validation and work flow, but will be tightened down as we iterate and receive feedback.
That being said, we're a small team that likes to spend less time planning every detail in favor of getting something functional in front of the client so we can start iterating towards where we need to be.
I've lost count the amount of times we've spec'd out projects to the nth degree (based on requirements from many meetings), only for the requirements to be switched up when it finally gets into the hands of the actual users.
Are you running high performance software? If the answer is no I also would like to know why don't you use an ORM, just out of curiosity.
I used to work with data first many years ago but it seems it's all code first nowadays.
Also forget about REST and embrace GraphQL, you'll be happier (and any other involved dev too)
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)
Looks like a well-thought-out system 👍😉