2 ms·

> in an endpoint I can do much more than just interrogating the database. And I usually do. Like what?

by dventimi 2y ago

Alifatisk 2y ago
In my case, it wpuld be to execute business logic, like complex calculations, validations, or workflows that go beyond simple database operations. Another case is integrating external services through API calls, interact with other systems or services to fetch or send data. Format and transform data to prepare data for presentation in JSON before sending it back to the client.
- dventimi 2y ago
  Thanks! I ask because I tend to put business logic into a few broad categories: input validation, data transformation, sequencing, integration. The database can usually handle the first three out of these four well. That tracks with your "complex calculations, validations, or workflows" as well as "format and transform to prepare data for presentation in JSON." PostgreSQL is as good as or better at these tasks than any general-purpose programming language, in my view. Where it gets tricky is with "interact with other systems or services to fetch or send data." While I personally would be cautious about this for purely architectural reasons that go well beyond how it's implemented, "the customer is always right." If I were consulting for a customer who wanted to integrate with external systems, I do have a few tricks up my sleeve. What I hope you'll take away from this is that "business logic" isn't the show-stopper that people tend to think it is when considering building applications in the database. Pretty much all of it can be done. Some kinds of business logic can be handled quite naturally. Other kinds perhaps less so, but it can be done. People may still choose not to do so for various reasons, and that's fine, but there usually aren't technical barriers to putting business logic in the database.

2 ms·

> in an endpoint I can do much more than just interrogating the database. And I usually do. Like what?

by dventimi 2y ago

> in an endpoint I can do much more than just interrogating the database. And I usually do. Like what?

Alifatisk 2y ago
In my case, it wpuld be to execute business logic, like complex calculations, validations, or workflows that go beyond simple database operations. Another case is integrating external services through API calls, interact with other systems or services to fetch or send data. Format and transform data to prepare data for presentation in JSON before sending it back to the client.
- dventimi 2y ago
  Thanks! I ask because I tend to put business logic into a few broad categories: input validation, data transformation, sequencing, integration. The database can usually handle the first three out of these four well. That tracks with your "complex calculations, validations, or workflows" as well as "format and transform to prepare data for presentation in JSON." PostgreSQL is as good as or better at these tasks than any general-purpose programming language, in my view. Where it gets tricky is with "interact with other systems or services to fetch or send data." While I personally would be cautious about this for purely architectural reasons that go well beyond how it's implemented, "the customer is always right." If I were consulting for a customer who wanted to integrate with external systems, I do have a few tricks up my sleeve. What I hope you'll take away from this is that "business logic" isn't the show-stopper that people tend to think it is when considering building applications in the database. Pretty much all of it can be done. Some kinds of business logic can be handled quite naturally. Other kinds perhaps less so, but it can be done. People may still choose not to do so for various reasons, and that's fine, but there usually aren't technical barriers to putting business logic in the database.