8 ms·

You use an api-gateway in front of this and send those requests to your application server, generally though you should try to keep your business logic in trigg

You use an api-gateway in front of this and send those requests to your application server, generally though you should try to keep your business logic in triggers and stored procedures.

deleted 5y ago
[deleted]
lenzm 5y ago
Writing all of my business logic in triggers and stored procedures seems like a high cost to avoid writing crud. All the value comes from business logic. Making the business logic easier to read and work with is usually my top priority.
- throwawayboise 5y ago
  Databases tend to outlive front-end applications. How long has Postgres been around? How long has your currently fashionable front-end framework been around? I avoid triggers but put as much of my applications into stored procedures as I can.
  - IceDane 5y ago
    First of all, you usually don't put your business logic in your frontend. This makes your entire argument fall flat on its face. If we then take your argument and instead just apply it to, say, using JS on the backend.. well, JS is not going anywhere any time soon. pl/pgsql is absolutely awful and it is a disservice to other programming languages to call it a programming language. Writing actual, complicated business logic using this and maybe some mix of JS(because why not pull that into the databse?? great idea) is just going to make every single person who has to maintain this in the future hate your guts. I'm truly glad I don't have to work with anyone who genuinely thinks such a design would be a good idea.
    - sigstoat 5y ago
      > First of all, you usually don't put your business logic in your frontend. This makes your entire argument fall flat on its face. the comment makes sense if one interprets "frontend" as "all the shit in front of the database". which is a reasonable interpretation in the context of something like postgrest, if not perhaps satisfying to you. > pl/pgsql is absolutely awful who cares > Writing actual, complicated business logic using this and maybe some mix of JS(because why not pull that into the databse?? great idea) there are a number of other languages available for writing postgresql procedures, and you can add new ones
- ratww 5y ago
  Wether it makes sense to put business logic in procedures really depends on what's involved in "business logic". For data-heavy apps with very complex schemas, your code can actually get more readable inside stored procedures. I used procedures for a content creation pipeline/headless CMS app that had flexible workflow templates (those also lived in the DB). It works quite well, and is simpler and more readable than most common backend code and much faster to develop. If you need to trigger async stuff, like network access or data processing, one pattern I enjoy is writing to a log-ish table that gets picked up and processed later by a separate service. This is nice for emails and other types of notifications: your users get a log of sent emails, and you can very easily do it inside a transaction. If the complexity is on the querying side, then you can get a lot of mileage from views. If you need caching for that, materialized views really help. However: If you're doing complex numeric/algorithmic stuff, rely on external libraries, or has just plain too much business logic... then doing things in a separate service is definitely better, no question about it. Triggers, I'm personally not a fan.

You use an api-gateway in front of this and send those requests to your application server, generally though you should try to keep your business logic in triggers and stored procedures.

deleted 5y ago

[deleted]

lenzm 5y ago

Writing all of my business logic in triggers and stored procedures seems like a high cost to avoid writing crud. All the value comes from business logic. Making the business logic easier to read and work with is usually my top priority.

throwawayboise 5y ago
Databases tend to outlive front-end applications. How long has Postgres been around? How long has your currently fashionable front-end framework been around? I avoid triggers but put as much of my applications into stored procedures as I can.
- IceDane 5y ago
  First of all, you usually don't put your business logic in your frontend. This makes your entire argument fall flat on its face. If we then take your argument and instead just apply it to, say, using JS on the backend.. well, JS is not going anywhere any time soon. pl/pgsql is absolutely awful and it is a disservice to other programming languages to call it a programming language. Writing actual, complicated business logic using this and maybe some mix of JS(because why not pull that into the databse?? great idea) is just going to make every single person who has to maintain this in the future hate your guts. I'm truly glad I don't have to work with anyone who genuinely thinks such a design would be a good idea.
  - sigstoat 5y ago
    > First of all, you usually don't put your business logic in your frontend. This makes your entire argument fall flat on its face. the comment makes sense if one interprets "frontend" as "all the shit in front of the database". which is a reasonable interpretation in the context of something like postgrest, if not perhaps satisfying to you. > pl/pgsql is absolutely awful who cares > Writing actual, complicated business logic using this and maybe some mix of JS(because why not pull that into the databse?? great idea) there are a number of other languages available for writing postgresql procedures, and you can add new ones
ratww 5y ago
Wether it makes sense to put business logic in procedures really depends on what's involved in "business logic". For data-heavy apps with very complex schemas, your code can actually get more readable inside stored procedures. I used procedures for a content creation pipeline/headless CMS app that had flexible workflow templates (those also lived in the DB). It works quite well, and is simpler and more readable than most common backend code and much faster to develop. If you need to trigger async stuff, like network access or data processing, one pattern I enjoy is writing to a log-ish table that gets picked up and processed later by a separate service. This is nice for emails and other types of notifications: your users get a log of sent emails, and you can very easily do it inside a transaction. If the complexity is on the querying side, then you can get a lot of mileage from views. If you need caching for that, materialized views really help. However: If you're doing complex numeric/algorithmic stuff, rely on external libraries, or has just plain too much business logic... then doing things in a separate service is definitely better, no question about it. Triggers, I'm personally not a fan.