Skip to content

Latest commit

 

History

History
22 lines (13 loc) · 2.74 KB

2012-05-16-kinvey.md

File metadata and controls

22 lines (13 loc) · 2.74 KB
title layout
Kinvey
default

So... not to dog on what Kinvey is doing, because it's useful in a certain context, but I'd like to differentiate between that and the approach that we're taking.

Kinvey is essentially making the assumption that the server is just a dumb data store - that all it needs to do is keep track of the state of things. There's another startup here in Phoenix that some guys I used to work with at Terralever are doing that also takes the same approach. They're calling it Deployd. They're not identical, but they seem to be assuming the same role.

In any case, Kinvey does allow some business rules to be saved on the server, but that's really not their focus. They want the smarts to be on the client side. Because of that, it's going to be difficult (or impossible) to build a system that has complex business rules. And business rules NEED to be on the server - it's the only way you can guarantee that they are enforced. Anything client side cannot be trusted - a malicious user could modify how it works and you'd have no knowledge.

So, it's interesting because there's this weird polarization going on. We've had HTML served over HTTP as the web standard for years, and that's a very server focused architecture. And people are complaining because the user experience is poor. And now there's an uprising, and people love mobile apps and these fancy new HTML5 web apps because they're finally getting their user experience back. And you've got developers responding to that demand, saying "Yes, truly the time of the client is nigh! Screw those uppity server guys!" You know, I read an article somewhere that mobile clients were rendering the web irrelevant... The author apparently didn't realize that the circulatory and nervous systems of his baby ran through the web.

There are things that legitimately belong on both sides. The code on the client should serve to create a workflow for the user. The code on the server should enforce business rules, oversee transactions, and authenticate with third party providers. If you take a myopic view for one side or the other, you're going to be at a serious disadvantage in almost any problem space.

What's different about Personify? Our offering to a developer is different. We make no claims of simplifying your application architecture into a single space. We don't do that because it's wrong. So you have to think about the server and the client as separate entities, and you need to design separately for them. We give you the tools to do both sides though, and we give you the tools to communicate between them.

To quote Albert Einstein:

Make everything as simple as possible, but not simpler.

Beware anyone and everyone that tells you you don't have to think. They are your enemy.