mantrax3

Doesn't help if you click somewhere by accident and delete an email without noticing.

You can always shoot yourself in the foot even with a service layer.

But in a service layer you need to get it right once. And therefore if you don't, you have to fix it just once.

And coupling your business logic with your frontend layer suggests spaghetti code and violates DRY, because you typically have many frontends, but one app state.

Security is about focus. If the service coders can focus on the service being secure & fast, frontend guys can focus on the frontend being usable.

Otherwise you're asking everyone to think about everything, and human attention span, memory and skill sets are limited, and this does affect security.

If it's "not a hard problem" - and I agree it isn't, and it's solved by Clojure's SQL libraries, why should the web framework deal with it in any way?

And moving the problem actually helps, when the original place was the wrong place to solve the problem.

Security is one problem when you write queries all over the place. The other two problems are data integrity, and maintenance.

In a service layer you have exactly three concerns:

1) Validate abstract input (and permissions of the caller).

2) Perform the transaction.

3) Return abstract output (and/or errors).

No routers, no controllers, no views, no templates, no CSRF, no XSS, no HTML escaping, no GET, no POST, no nothing.

Just input, transaction, output. Pure data. Pure business logic.

And suddenly things that seemed hard to get right, or things you had to repeat all over the place in your code, get done simply, and just once. And all your web code calls the service layer.

All your iOS and Android app code - also calls the same service layer.

And they're both secure because you need to get the service secure just once - then all interfaces (web, mobile, desktop, API) use the same service.

And when you don't isolate the service, you'll be running SQL all over the place, and use every framework's souped up solutions to avoid SQLi.

Which one do you feel is better?

It's simple.

Let's see what the spectrum of PHP solutions is. It goes from:

- WordPress: very simple, you don't need to be a coder, not that powerful.

And goes until:

- PHP + libraries: complicated, you need to be a coder, extremely powerful.

And here's Drupal:

- Drupal: a lot more more complicated than WordPress, not that much less complicated than plain PHP, yet much less powerful than plain PHP.

In a nutshell, Drupal and apps like it want to be everything to everyone, and that's how bad apps happen.

WordPress may suck, but it has focus, and people with simple needs like the proposition.

Yes scores can't possibly be universal. But admit it. It just irks you to see a pop singer might be more popular than the president.

> "But in our universe, people saw the algorithm as hackneyed, particularly when Justin Bieber had a higher Klout score than the US president."

Maybe Klout was wrong with this particular arrangement, or maybe your assumptions about who has more influence are wrong. Ever thought about that?

After all, "entertainment clout" can be very quickly capitalized as "political clout", as Mr. Terminator has demonstrated.

When it comes to selling products, whose endorsement will sell more products: Justin Bieber or the US President?

Remember Klout's score is used to give "perks" to influencers, the purpose of which is that they show those perks to their fans, therefore influencing them.

While I don't care about Klout at all, I have to say I'd rather bet on Justin Bieber than the US President for that specific purpose.

In a nutshell, social engineering can be countered by proper software & processes engineering.

So if social engineering is possible, blame the software architects.

Maybe in extreme cases changing the email of an account might be needed, but there's no excuse a first level rep was able to do it. Least thing, he/she should've been forced by the system to escalate to someone above her, who has a much lesser chance to screw up.

Your logic is a bit weird.

Sendgrid just experienced this major embarrassment and are currently re-training their staff to avoid it again at all costs.

And you're going to move away from them now?

That's probably the one part that really didn't make sense. But maybe he did it for sport.

> "and it looks inspired by PHP."

You're getting the order wrong here.

- It was inspired by Java.

- PHP OOP was also inspired by Java.

It's hard to argue that Java's OOP model is bad. It encourages clear code structure and works especially well for large project (for tiny projects you don't need OOP at all, anyway). This is why C#, PHP, this library and many more are based on Java.

Oh, BTW, let's keep digging:

- Java's OOP was inspired by Objective C.

- Objective C was inspired by SmallTalk.

It's always Lisp or SmallTalk, isn't that fun?

And a bunch of people coming out of their caves to tell us how JavaScript's quickly cobbled up hacky prototype system is a design by God himself, and everything else is the Devil trying to trick us into his Java ways... Sigh.

Which is why the next versions of JS (ES6 and ES7) will have:

1) Modules (namespaces)

2) Classes

3) Member visibility

Whoops. Ignore the cognitive dissonance and continue with the flame!

Now. While the library linked here isn't the prettiest thing I've seen, I immediately get it. And I can immediately start coding in it and get the expected behavior.

This, in itself, is a huge feature compared to the awkward incantations one has to do in barebones JS to do OOP (of any kind). Even the fact it's string based doesn't make it inferior to some of the other unreadable stuff I've seen by people doing JavaScript "properly" (or so they think).

So, I say kudos about that. Here we have an implementation solving a practical problem in a practical way. No plot twists and surprises.

I prefer TypeScript, but this one doesn't require a parser, so it has its benefits.

You may have heard about spreadsheets or relational databases...