hmm. I’d say the position is more nuanced than the author alludes to. It isn’t like frameworks don’t ever have bugs, or that people don’t ever use them incorrectly or poorly.
Maybe… don’t decide to write/use your own framework, especially in a business setting, without intention and after a clear cost/benefit analysis and evaluation of available options.
Note that in most languages there are many good/decent library primitives to build upon, especially in the “web stack”. It isn’t exactly reinventing the wheel (eg. don’t write your own crypto) by using some them to make your own “framework”. (I generally prefer libraries over frameworks, where possible)
Some of the friendliest and most powerful “frameworks” I have used were home grown and locked away inside companies. Certainly some of the worst ones too…I guess, if you are going to write your own framework, make sure it isn’t a crappy one!
I agree that this post is way too black and white. My own experience with writing frameworks is that they’re really a bottomless pit of effort, and you usually end up doing a worse job overall than existing frameworks.
You’re basically reinventing the wheel. This costs a lot of effort to build and when you’re “done”, you keep pouring effort into it for ongoing maintenance. Getting new people on board is harder, because they’re definitely unfamiliar with your own framework.
Having said that, there is great benefit in being able to make things exactly the way you need them to be, and to be able to tweak things at a much higher speed than the slow pace of most “upstream” frameworks. And once you have built it, it can really increase development speed on new projects (assuming a similar type of project) if all projects benefit from the same framework.
So basically, it’s an investment, and you’d better do your due diligence to make sure you’re not investing in a dud.
This post clearly lacks nuance, but I do think that the point is valid. Unless your company has done a comprehensive cost/benefit analysis and found that the benefits of writing your own version of something that’s already been done a thousand times (like a web framework) outweighs the high costs, you shouldn’t do it. It’s not like web frameworks are something new and different; there isn’t that much to be gained by writing your own for 99% of web applications.
If you’re running a business, “letting others bear the burdens of making mistakes” is oftentimes a requirement for success.
We wrote a custom framework, there was a bug, it costed us a lot of money
What we really need in order to make a meaningful judgement is the story of the parallel universe in which they didn’t write a custom framework. Presumably it goes something like:
We used an existing framework, there was a bug, the benevolent wizards who wrote the framework came round to our workplace, debugged the issue for us, fixed it, magically updated all our servers to the latest version and were so ashamed of the bug that they didn’t even charge us.
As others have said, there are pros and cons on each side and you have to weigh them up as best you can before making an investment.
I don’t think you should set out to build a ‘framework’. Build what you need. If you do something 10 times and there’s some stuff in there you use every time, that’s your framework for that task. If your job is to build websites, build a website. Build another website, reusing the bits you found useful from the last website. Do this another ten times. At the end, you’ll have a utility library you know ahead of time you’ll always need and a bunch of scripts. Pro tip: that’s all a framework is.
Every Ruby on Rails app was found vulnerable in 2013, and the Equifax data breach was due to an outdated version of Apache Struts. Not trying to hate on these frameworks specifically here – I like Rails – but they’re high-profile examples that show that frameworks are not always sunshine either.
Lobsters for example is written in Rails, but it uses a small fraction of Rails’ features. I don’t think it would really be any less secure if it had been written “from scratch” by someone who knew what they were doing, especially not if they used existing libraries like Rack and whatnot. (there are of course many other advantages to using Rails, and I think Rails is a pretty good fit for something like Lobsters. but not because it’s more secure).
Years ago (my first programming job) there was some push to replace a very simple CRUD CMS with Joomla. I pushed back against this as the code was pretty simple (not much that could go wrong) and I also knew that after I left no-one else would be there to maintain or update it, increasing the risk of automated scanners trying to find vulnerable Joomla versions etc. I think this is a good example where using a framework would not be a good idea.
So … it all depends on what you’re doing. I think The Real Lesson™ here should be to throw as much funky input towards your code as possible, especially security-critital code. I think a fuzzer would probably have caught this error.
I don’t know what kind of websites those “200 websites” are, if they’re simple “deploy and forget” stuff then a simple custom framework with very little moving parts might be a good idea. If they’re complex sites then a standard framework would probably be better (even in “deploy and forget” scenarios). Either way, like most “which should I use” questions the answer is “it depends” :-)
Not trying to hate on these frameworks specifically here – I like Rails – but they’re high-profile examples that show that frameworks are not always sunshine either.
I believe the killer argument is “not my fault”. When you use something backed by a big community, you won’t be held accountable for its bugs, even if they cost significant money. If you wrote that bug however, that’s another matter. Especially if you had the option of using that popular thingy instead.
The real problem here wasn’t your framework. It’s the act of separating your “authorization layer” from your service running your framework while also not rewriting URLs at the edge. Both are mistakes.
Web security is hard. Really hard. There are too many moving pieces and it’s just too darn complicated. Shifting the risk to a 3rd-party framework provides the benefit of (maybe) getting more eyeballs on some of the underlying code, at the expense of fully understanding it. But that can still lead to exploits when complicated pieces of code that aren’t fully understood by anyone interact in subtle ways and open up a new exploits due to misconfiguration/misuse. Read hackerone writeups to see how, even professional companies like Twitter, Google, Facebook, (insert your favorite web service), get this wrong.
I could go off on a rant about web security, but that’s a post for another time. It may be impossible to completely secure a web service, but putting an emphasis on minimizing attack surface (by keeping things simple) and doing regular pen-tests seems to be the best way of securing an application. Not putting your faith in a 3rd party library because it has more stars on GitHub.
I agree this is a bit stark: Reminds me of one of my favorite jokes from this post:
framework — A product with the business logic removed, but all of the assumptions left in.
For every NIH mess a company can produce when they could have used an off-the-shelf component, there are just as many “avoid writing our own” horror shows around trying to build a sophisticated product around a combination of framework limitations that don’t quite fit.
Some domains are super well-understood and writing your own is probably not where you need to differentiate (e.g. web routing, core HTTP handling). But further out, IMO it can be harder to tell at the outset.
BrenDt: I’m not sure what the point of the article is. That custom frameworks have more bugs then popular, general purpose frameworks?
If so, what is the rationale behind this belief?
I can see arguments in both directions. On the one hand, more people look at popular frameworks and report bugs. On the other hand, they are more complex. Because they have a wider range of use cases to support. And the likelihood of bugs grows exponentially with the complexity of the code.
Why is URL canonicalization not outsourced to an open source library that is called from bespoke framework?
While a good question, I think the relevant question here is actually “why was the authentication code working on the unparsed URL”? Using a good canonicalization library doesn’t help if you don’t use it in the authentication path.
It’s my pet peeve that the word ‘framework’ hides a lot of information about what it is you’re actually building.
The word ‘library’ was commonly used without adjectives. Once we started to use it for software development, it quickly became the practice to qualify one as a network library, video processing library, etc.
A framework seems to be defined as a collection of things developers (working on a certain set of problems) have to write over and over again. It can consist of utility libraries, but also integration work, and something I can only describe as practices enforced by code. I don’t think it’s strange that these grow to be hairy and error-prone over time.
I find it much more expedient and informative to say that this application is built on ‘x framework’ then it is to say it is built on 200 node.js libraries and these 5 common system libraries.
As long as the other person is familiar with that framework, then yes. A non-descriptive name is a way of passing information by reference rather than by value. It’s more efficient for the caller, but you’re passing the burden of resolving the information to the recipient.
But it’s often hard to describe the scope of a framework (obviously there are exceptions) in one or two sentences. To me that’s a definite code smell.
TLDR: Using a framework means giving up a lot of control, which becomes particularly problematic when you are dealing with a discovered bug.
Long, rant-y version:
… The counterpoint to this whole framework “herd immunity” concept is twofold:
(a) Once the herd is big enough, you’re guaranteed to be a target for automated attacks. Anyone who’s ever looked at a web server log has seen hundreds if not thousands of 404’s for calls to non-existent end points that do exist under (typically php) ‘frameworks’ like WordPress or the like. As has been mentioned by others - someone discovered a serious bug in Rails several years back, and just like that every rails app in the world was vulnerable to an easily exploitable bug. Security through obscurity isn’t great security - but there is a reason “hide your valuables” is still sound advice in a car park.
(b) If you control (or arguably, understand well enough to be comfortable patching) the library/framework, you can fix a bug as soon as you know it exists. Just because a community exists doesn’t mean that a fix is going to be timely or adopted instantly, particularly if you’re at multiple levels of dependency.
To illustrate point (b), last year I came across a weird bug where some actions in a third-party Ruby web app weren’t working. After a lot of faffing about, it turned out to be a bug introduced in a patch version (2.0.5) of Sinatra, that just broke shit on versions of Ruby before 2.4.
I don’t pretend to be a Ruby expert, I can mostly read it, I tend to not write it, but even I’d heard of Sinatra framework before this bug, so let’s just say that it’s reasonably popular in the Ruby world. The timeline around the bug that I encountered was thus:
2018-12-23 Sinatra 2.0.5 is released
2019-01-11 Issue describing SNAFU status on Ruby < 2.4 is filed.
2019-02-07 Issue is closed via PR
…. Crickets
2019-08-21 Sinatra 2.0.6 is released with the fix
I’m just going to ignore that the fix was to literally add 5 characters + two spaces (literally val && ), and that the time from issue opened to PR opened was roughly the same as the amount of time then spent discussing the PR and whether or not the PR author was correct for having following their own contributing guide and updating the changing file. All of that is IMO ridiculous, but inconsequential in the grand scheme of things.
If you release a patch version that fucks shit up, and your “release schedule” is every 6 months, you either need to make sure your shit is fucking solid, or throw your fucking release schedule out the fucking window.
The current fad with “re-use all the things, don’t ever write anything that anyone might have written before” is beyond stupid. Given the sort of shit we’ve seen from this practice in the NodeJS community, I would fully expect these people to insist that they don’t need a lawyer to write a contract for a business, they have this perfectly good one their niece wrote in fucking crayon. It says “contract” on the top (although the R is reversed of course) so it must be of equal quality.
If you release a patch version that fucks shit up, and your “release schedule” is every 6 months, you either need to make sure your shit is fucking solid, or throw your fucking release schedule out the fucking window.
It might be a good idea to bank a portion of the money saved on license and support fees to be able to pay an experienced Ruby consultant to fix stuff if needed.
… Unless the “ruby consultants” you know have some magical ability to force third party projects to make more frequent releases when bug fixes are merged, what exactly are you suggesting that they could do?
We knew the problem. Short term we used a patch on the ruby file in question, and longer term we switched to installing a newer version of ruby from a third party apt repo.
Many are citing the post for missing nuance. Which is true. I have my own opinions on exactly what it’s missing though.
Building a good framework for something as complex and with such high attack surface as the web is really tough. Evidence seems to suggest that basically nobody can just build one that’s free from security bugs. What this means is that if you want a web framework to actually be secure, you have to first build it and host some things on it that attract actual attacks. There will be bugs and exploits, and you’ll have to find them and fix them. Serious bugs being found and fixed doesn’t mean your framework is bad. Your worry should be for the ones that haven’t had any - how many bugs do they have that haven’t been found yet because they haven’t hosted something big enough for anybody to care? How will the project team respond when one of those bugs is found? The frameworks that deserve our trust are battle-tested.
If you wanna build your own, you need to be prepared to pay that price. Unless you’ve hired somebody with like 20 years of experience in running web framework projects, who for some reason doesn’t want to use the one he’s been working on, you’re gonna have bugs.
I’ve been thinking a lot since the “framework” v.s. “library” debate making rounds on the internet. A proper framework should encapsulate all workflows from writing code to deployment. It institutes certain ways of doing things to keep “the house” clean and in-order. That also means “writing your own frameworks” many times over is out of necessity than anything else. At the end of the day, when deploying an application, you probably better off with only one way to pull in dependencies, only one way to talk to your server (if there is), and only one way to present interface to end-users.
When you are trying to ship a new single-page (web) application in late 2000s, existing frameworks at that time such as RoR simply cannot cut it, and you have to build your own, either Angular, Vue or to some extent the earlier ones (meteor?).
That is also why you have so many frameworks around web development. For small Windows / macOS / iOS / Android development, the OS providers already provide you with a flow on how you write code to how to deploy to client. There are custom frameworks certainly built in-house for mobile development because these OS-provided way will not cut it for large collaborations (e.g. one app developed by hundreds people).
That’s why the “don’t write your own framework” suggestion is really not withstanding. It is something out of necessity to facilitate collaboration. It will be great to use existing ones if it fits the bill, but there are also historical baggages and inherited challenges on its non-existence, especially if you are trying to do more interesting things.
When authorizing your views, enforce by functionality not the url.
Like if you have a delete function. Check auth at the point you delete, NOT the point you resolve the mapping from url to the function.
Extrapolating bad maxims from anecdotes is pretty much the same as writing a framework.
hmm. I’d say the position is more nuanced than the author alludes to. It isn’t like frameworks don’t ever have bugs, or that people don’t ever use them incorrectly or poorly.
Maybe… don’t decide to write/use your own framework, especially in a business setting, without intention and after a clear cost/benefit analysis and evaluation of available options.
Note that in most languages there are many good/decent library primitives to build upon, especially in the “web stack”. It isn’t exactly reinventing the wheel (eg. don’t write your own crypto) by using some them to make your own “framework”. (I generally prefer libraries over frameworks, where possible)
Some of the friendliest and most powerful “frameworks” I have used were home grown and locked away inside companies. Certainly some of the worst ones too…I guess, if you are going to write your own framework, make sure it isn’t a crappy one!
I agree that this post is way too black and white. My own experience with writing frameworks is that they’re really a bottomless pit of effort, and you usually end up doing a worse job overall than existing frameworks.
You’re basically reinventing the wheel. This costs a lot of effort to build and when you’re “done”, you keep pouring effort into it for ongoing maintenance. Getting new people on board is harder, because they’re definitely unfamiliar with your own framework.
Having said that, there is great benefit in being able to make things exactly the way you need them to be, and to be able to tweak things at a much higher speed than the slow pace of most “upstream” frameworks. And once you have built it, it can really increase development speed on new projects (assuming a similar type of project) if all projects benefit from the same framework.
So basically, it’s an investment, and you’d better do your due diligence to make sure you’re not investing in a dud.
Well stated. I very much agree.
The argument here is: We wrote a custom framework, there was a bug, it costed us a lot of money, therefore don’t write your own framework.
The underlying idea here is: something is hard, and we most likely wont be perfect, so let’s not do it. Let others bear the burdens of making mistake.
Which is a terrible idea to subscribe to.
This post clearly lacks nuance, but I do think that the point is valid. Unless your company has done a comprehensive cost/benefit analysis and found that the benefits of writing your own version of something that’s already been done a thousand times (like a web framework) outweighs the high costs, you shouldn’t do it. It’s not like web frameworks are something new and different; there isn’t that much to be gained by writing your own for 99% of web applications.
If you’re running a business, “letting others bear the burdens of making mistakes” is oftentimes a requirement for success.
What we really need in order to make a meaningful judgement is the story of the parallel universe in which they didn’t write a custom framework. Presumably it goes something like:
As others have said, there are pros and cons on each side and you have to weigh them up as best you can before making an investment.
I don’t think you should set out to build a ‘framework’. Build what you need. If you do something 10 times and there’s some stuff in there you use every time, that’s your framework for that task. If your job is to build websites, build a website. Build another website, reusing the bits you found useful from the last website. Do this another ten times. At the end, you’ll have a utility library you know ahead of time you’ll always need and a bunch of scripts. Pro tip: that’s all a framework is.
Every Ruby on Rails app was found vulnerable in 2013, and the Equifax data breach was due to an outdated version of Apache Struts. Not trying to hate on these frameworks specifically here – I like Rails – but they’re high-profile examples that show that frameworks are not always sunshine either.
Lobsters for example is written in Rails, but it uses a small fraction of Rails’ features. I don’t think it would really be any less secure if it had been written “from scratch” by someone who knew what they were doing, especially not if they used existing libraries like Rack and whatnot. (there are of course many other advantages to using Rails, and I think Rails is a pretty good fit for something like Lobsters. but not because it’s more secure).
Years ago (my first programming job) there was some push to replace a very simple CRUD CMS with Joomla. I pushed back against this as the code was pretty simple (not much that could go wrong) and I also knew that after I left no-one else would be there to maintain or update it, increasing the risk of automated scanners trying to find vulnerable Joomla versions etc. I think this is a good example where using a framework would not be a good idea.
So … it all depends on what you’re doing. I think The Real Lesson™ here should be to throw as much funky input towards your code as possible, especially security-critital code. I think a fuzzer would probably have caught this error.
I don’t know what kind of websites those “200 websites” are, if they’re simple “deploy and forget” stuff then a simple custom framework with very little moving parts might be a good idea. If they’re complex sites then a standard framework would probably be better (even in “deploy and forget” scenarios). Either way, like most “which should I use” questions the answer is “it depends” :-)
I believe the killer argument is “not my fault”. When you use something backed by a big community, you won’t be held accountable for its bugs, even if they cost significant money. If you wrote that bug however, that’s another matter. Especially if you had the option of using that popular thingy instead.
Often, “not my fault” turns into “not a simple fix” though
Definitely. That’s one reason why I personally like to minimise dependencies: code I wrote is code I can fix.
This is a sadly uncommon view in 2020, I feel.
The real problem here wasn’t your framework. It’s the act of separating your “authorization layer” from your service running your framework while also not rewriting URLs at the edge. Both are mistakes.
Web security is hard. Really hard. There are too many moving pieces and it’s just too darn complicated. Shifting the risk to a 3rd-party framework provides the benefit of (maybe) getting more eyeballs on some of the underlying code, at the expense of fully understanding it. But that can still lead to exploits when complicated pieces of code that aren’t fully understood by anyone interact in subtle ways and open up a new exploits due to misconfiguration/misuse. Read hackerone writeups to see how, even professional companies like Twitter, Google, Facebook, (insert your favorite web service), get this wrong.
I could go off on a rant about web security, but that’s a post for another time. It may be impossible to completely secure a web service, but putting an emphasis on minimizing attack surface (by keeping things simple) and doing regular pen-tests seems to be the best way of securing an application. Not putting your faith in a 3rd party library because it has more stars on GitHub.
I agree this is a bit stark: Reminds me of one of my favorite jokes from this post:
For every NIH mess a company can produce when they could have used an off-the-shelf component, there are just as many “avoid writing our own” horror shows around trying to build a sophisticated product around a combination of framework limitations that don’t quite fit.
Some domains are super well-understood and writing your own is probably not where you need to differentiate (e.g. web routing, core HTTP handling). But further out, IMO it can be harder to tell at the outset.
BrenDt: I’m not sure what the point of the article is. That custom frameworks have more bugs then popular, general purpose frameworks?
If so, what is the rationale behind this belief?
I can see arguments in both directions. On the one hand, more people look at popular frameworks and report bugs. On the other hand, they are more complex. Because they have a wider range of use cases to support. And the likelihood of bugs grows exponentially with the complexity of the code.
Why was the framework written in the first place?
Why is URL canonicalization not outsourced to an open source library that is called from bespoke framework?
While a good question, I think the relevant question here is actually “why was the authentication code working on the unparsed URL”? Using a good canonicalization library doesn’t help if you don’t use it in the authentication path.
It’s my pet peeve that the word ‘framework’ hides a lot of information about what it is you’re actually building.
The word ‘library’ was commonly used without adjectives. Once we started to use it for software development, it quickly became the practice to qualify one as a network library, video processing library, etc.
A framework seems to be defined as a collection of things developers (working on a certain set of problems) have to write over and over again. It can consist of utility libraries, but also integration work, and something I can only describe as practices enforced by code. I don’t think it’s strange that these grow to be hairy and error-prone over time.
I find it much more expedient and informative to say that this application is built on ‘x framework’ then it is to say it is built on 200 node.js libraries and these 5 common system libraries.
As long as the other person is familiar with that framework, then yes. A non-descriptive name is a way of passing information by reference rather than by value. It’s more efficient for the caller, but you’re passing the burden of resolving the information to the recipient.
But it’s often hard to describe the scope of a framework (obviously there are exceptions) in one or two sentences. To me that’s a definite code smell.
TLDR: Using a framework means giving up a lot of control, which becomes particularly problematic when you are dealing with a discovered bug.
Long, rant-y version:
… The counterpoint to this whole framework “herd immunity” concept is twofold:
(a) Once the herd is big enough, you’re guaranteed to be a target for automated attacks. Anyone who’s ever looked at a web server log has seen hundreds if not thousands of 404’s for calls to non-existent end points that do exist under (typically php) ‘frameworks’ like WordPress or the like. As has been mentioned by others - someone discovered a serious bug in Rails several years back, and just like that every rails app in the world was vulnerable to an easily exploitable bug. Security through obscurity isn’t great security - but there is a reason “hide your valuables” is still sound advice in a car park.
(b) If you control (or arguably, understand well enough to be comfortable patching) the library/framework, you can fix a bug as soon as you know it exists. Just because a community exists doesn’t mean that a fix is going to be timely or adopted instantly, particularly if you’re at multiple levels of dependency.
To illustrate point (b), last year I came across a weird bug where some actions in a third-party Ruby web app weren’t working. After a lot of faffing about, it turned out to be a bug introduced in a patch version (2.0.5) of Sinatra, that just broke shit on versions of Ruby before 2.4.
I don’t pretend to be a Ruby expert, I can mostly read it, I tend to not write it, but even I’d heard of Sinatra framework before this bug, so let’s just say that it’s reasonably popular in the Ruby world. The timeline around the bug that I encountered was thus:
2018-12-23 Sinatra 2.0.5 is released 2019-01-11 Issue describing SNAFU status on Ruby < 2.4 is filed. 2019-02-07 Issue is closed via PR …. Crickets 2019-08-21 Sinatra 2.0.6 is released with the fix
I’m just going to ignore that the fix was to literally add 5 characters + two spaces (literally
val &&), and that the time from issue opened to PR opened was roughly the same as the amount of time then spent discussing the PR and whether or not the PR author was correct for having following their own contributing guide and updating the changing file. All of that is IMO ridiculous, but inconsequential in the grand scheme of things.If you release a patch version that fucks shit up, and your “release schedule” is every 6 months, you either need to make sure your shit is fucking solid, or throw your fucking release schedule out the fucking window.
The current fad with “re-use all the things, don’t ever write anything that anyone might have written before” is beyond stupid. Given the sort of shit we’ve seen from this practice in the NodeJS community, I would fully expect these people to insist that they don’t need a lawyer to write a contract for a business, they have this perfectly good one their niece wrote in fucking crayon. It says “contract” on the top (although the R is reversed of course) so it must be of equal quality.
It might be a good idea to bank a portion of the money saved on license and support fees to be able to pay an experienced Ruby consultant to fix stuff if needed.
… Unless the “ruby consultants” you know have some magical ability to force third party projects to make more frequent releases when bug fixes are merged, what exactly are you suggesting that they could do?
We knew the problem. Short term we used a patch on the ruby file in question, and longer term we switched to installing a newer version of ruby from a third party apt repo.
Thanks for clarifying, it seemed at first read that you didn’t get this resolved until Sinatra was updated.
Open source saves the day again!
Many are citing the post for missing nuance. Which is true. I have my own opinions on exactly what it’s missing though.
Building a good framework for something as complex and with such high attack surface as the web is really tough. Evidence seems to suggest that basically nobody can just build one that’s free from security bugs. What this means is that if you want a web framework to actually be secure, you have to first build it and host some things on it that attract actual attacks. There will be bugs and exploits, and you’ll have to find them and fix them. Serious bugs being found and fixed doesn’t mean your framework is bad. Your worry should be for the ones that haven’t had any - how many bugs do they have that haven’t been found yet because they haven’t hosted something big enough for anybody to care? How will the project team respond when one of those bugs is found? The frameworks that deserve our trust are battle-tested.
If you wanna build your own, you need to be prepared to pay that price. Unless you’ve hired somebody with like 20 years of experience in running web framework projects, who for some reason doesn’t want to use the one he’s been working on, you’re gonna have bugs.
I’ve been thinking a lot since the “framework” v.s. “library” debate making rounds on the internet. A proper framework should encapsulate all workflows from writing code to deployment. It institutes certain ways of doing things to keep “the house” clean and in-order. That also means “writing your own frameworks” many times over is out of necessity than anything else. At the end of the day, when deploying an application, you probably better off with only one way to pull in dependencies, only one way to talk to your server (if there is), and only one way to present interface to end-users.
When you are trying to ship a new single-page (web) application in late 2000s, existing frameworks at that time such as RoR simply cannot cut it, and you have to build your own, either Angular, Vue or to some extent the earlier ones (meteor?).
That is also why you have so many frameworks around web development. For small Windows / macOS / iOS / Android development, the OS providers already provide you with a flow on how you write code to how to deploy to client. There are custom frameworks certainly built in-house for mobile development because these OS-provided way will not cut it for large collaborations (e.g. one app developed by hundreds people).
That’s why the “don’t write your own framework” suggestion is really not withstanding. It is something out of necessity to facilitate collaboration. It will be great to use existing ones if it fits the bill, but there are also historical baggages and inherited challenges on its non-existence, especially if you are trying to do more interesting things.
I’m sorry, I just can’t help it.
When authorizing your views, enforce by functionality not the url. Like if you have a delete function. Check auth at the point you delete, NOT the point you resolve the mapping from url to the function.
Extrapolating bad maxims from anecdotes is pretty much the same as writing a framework.