Timeline for Microservices and stored procedures
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 3, 2021 at 22:10 | comment | added | JRichardsz | Totally agree! Comments like: data separate from other devs, hotfix production issues, stored procedures are often recommended for security reasons... worked several years ago. Can someone imagine the ec2 service of aws in a monolithic application or the entire algorithm in one store procedure? If the algorithm or logic is inside of a big store procedure, what about the unit testing? | |
| Sep 21, 2019 at 14:28 | comment | added | Flater | @NateDiamond: SQL injection attacks can easily be circumvented without resorting to sprocs. The only difference is that a sproc inherently enforces data parametrization (which prevents injection) whereas code doesn't explicitly forbid you to string concatenate (which allows for injection); but like I said, there are many (easy) ways to clean up/parametrize your data and avoid injection while keeping your query in code. | |
| Sep 20, 2019 at 16:44 | comment | added | Nate Diamond | Just to be clear, stored procedures are often recommended for security reasons, along with parameterized queries, to prevent SQL Injection attacks. The less the SQL commands are made in-memory, in general the better. It also makes it easy to very clearly limit what kinds of users can perform what actions. There are definitely other ways around these limitations, but historically these are some of the reasons they have been used. | |
| Sep 18, 2019 at 16:58 | comment | added | Flater | @Chuu: You mention yourself you have data wranglers. But most developers do not have dedicated coworkers who handle the DB (you do have DBAs to keep the servers up, but they tend not to optimize your queries for you as they are support staff). As a dev team, it's generally more interesting to not also have to wrangle SQL if you can avoid it. EF is popular specifically because it makes you have to wrangle one less technology/language (on top of simplifying boilerplate CRUD code and transactional behavior) | |
| Sep 18, 2019 at 16:57 | comment | added | Flater | @Chuu: It splits your business logic. The problem is that when your domain changes, you need to update both your codebase and your sprocs (compare this to e.g. EF Code First, where you need to make the change only once). Additionally, it's easy for sprocs and code to be out of sync (version mismatch). I don't mind a raw SQL query for sufficiently complex queries (where EF cannot be performant) but even then I would advocate for storing this in your codebase rather than your database, just to keep the business logic together. | |
| Sep 18, 2019 at 15:38 | comment | added | Chuu | Dinosaur here. Why are Stored Procs considered a bad things these days? In our applications we use them extensively because they allow for further separation of implementation and interface, which also lets our Data wranglers worry about the best implementations completely separate from other devs. It has also let us hotfix production issues without touching a running application. | |
| Sep 17, 2019 at 16:13 | comment | added | Laiv | Modern is not even synonynous of "adequate". | |
| Sep 16, 2019 at 13:47 | comment | added | T. Sar | @candied_orange "modern is not the same as better" - I think I wholeheartedly agree to that. Very good point. | |
| Sep 16, 2019 at 12:24 | comment | added | Flater | @T.Sar: Hacks are timeless, and you can usually abuse any system (modern or not) to do something it can technically handle but was never intended for. Microservices urge you to do it differently (and thus reevaluate some old approaches) but they can't universally enforce it. With universal enforcement you usually suffer in the compatibility/valid fringe case department. | |
| Sep 16, 2019 at 12:19 | comment | added | candied_orange | @T.Sar modern is not the same as better. Refactoring (to microservices or whatever) means change. Change forces you to use your current ideas. We hope they are better ideas. | |
| Sep 16, 2019 at 11:56 | comment | added | T. Sar | I'm not sure if it is correct to say that microservices push you to modernize your entire architecture. More often than not, they end up being a thin layer over a behemoth of a mess of poorly planned code. They can be pretty good when well done, but they don't really push you in any way towards better coding than any other architecture. Still, good answer. You got a +1 from me. | |
| Sep 16, 2019 at 8:21 | history | edited | Flater | CC BY-SA 4.0 |
added 158 characters in body
|
| Sep 16, 2019 at 8:12 | history | answered | Flater | CC BY-SA 4.0 |