No, we're just starting out, pivoting from a previous similar idea. We wanted to include community from day zero, so anyone can contribute to the design as well.
The project proposes a model that will have significant (negative) implications on client performance, server performance, developer cognitive overload, and latency (despite transactions).
It'll also introduce a very big attack surface for malicious agents to DDoS your server and possibly exploit the server-side V8 once an appropriate vulnerability shows up.
And it'll also produce application tightly coupled to browser API emulation, which would become an obstacle to the server being able to properly support native mobile and desktop applications.
I can put these issues aside for a moment, and attribute them to me being too cynical to believe in a new way of doing things.
But let's look at the benefits. This is the example being given for the kind of client code that SyncNinja would enable:
someDatabase.lookup('users', 'john', function (err, userData) {
console.log("User's real name is " + userData.userName);
});
This is already possible to do on the client-side, in plain JS, and any kind of server, as a very, very thin wrapper around the available AJAX calls provided by the server web API.
So my point is, I see no convincing examples of SyncNinja making something possible that wasn't already trivial before, and without the big overhead. Maybe you guys should work on what the value of this system is in practice.
Your "before" example doesn't show limitations of the browser, but simply a missing thin client library to abstract the AJAX calls.
Additionally, you have no prototype of this concept at all. Even a toy prototype with just one kind of event, or something. It sends the message that everything written in the paper doesn't come from experience, but it's merely hypothetical. And there's a giant leap from an idea to a working prototype.
Hey, thanks for the frank comment. Those are fair concerns and there will be a lot to address, for sure. The reason why we posted this so early (without any code) is that we wanted to get some kind of participation from the community from day zero. Your comment is the kind of participation we were looking for.
Now to actually address it, I think it's more than just a thin wrapper. Perhaps the example shows too little, but for many developers, writing server side code and all the necessary communication is a road block. For others it's just extra stuff to maintain. And we generally like less code that does more.
I wouldn't worry about V8 vulnerabilities, there are many node servers running in production today, in general, and they are doing fine. But your DDos point is pretty fair - I can see how that could be a problem. Feel free to submit a pull request to add to caveats if you want to take credit for it.
> I wouldn't worry about V8 vulnerabilities, there are many node servers running in production today, in general, and they are doing fine.
The problem is your concept is more than just another server running V8.
It's a server running V8 with code, which is nearly identical to the code running on my client (it gives me a peak at the server code structure), and which accepts a quite wide range of events allowing me to model an attack that would trigger a V8 vulnerability on the server.
It would be much easier to do compared to a server which exposes a minimal API in a completely opaque way.
> Perhaps the example shows too little, but for many developers, writing server side code and all the necessary communication is a road block.
I'm not every developer, so I wouldn't know, but I think you overestimate the hurdles of server-client communication that developers encounter.
A server-side API has to be written one way or another, as it's a key asset to a company and it encapsulates its business logic in a platform neutral way. This means I can have web site running off of it, I can have an iOS app running off of it, a desktop app, and also a cron job that runs every night and generates reports, for example.
None of this would be possible if you tightly couple the app business logic with a browser emulator.
Recreating the business logic with every client will be a gigantic waste of time and money and a very rich source of bugs. No one would do it that way. There has to be a central API.
Also there are many libraries that would generate the necessary client code (wrapping AJAX calls) for you from an API definition, here are some random examples I just googled up:
Security needs to be air-tight for sure, but we think we address it in the doc. Let me know if you have something specific that you think could be leveraged.
We talked with quite a few developers. There are many who want to launch their startup but have waaay less technical skills than you might think.
The way we thought of bridging the gap with mobile is by using Ionic and/or Apache Cordova, which use JavaScript.
Unless I'm missing some of the problems you're trying to solve, this seems like an extremely over engineered solution to the problem of code duplication (like validation) and boiler-plate communication code. For the former, if you're using a node backend, you can pretty trivially reuse the same code between client and server side. The later doesn't really seem like a big enough issue on its own to really warrant an architecture that requires a back-end with per-tab mirroring - you can usually encapsulate the 'cumbersome AJAX calls' with a straight forward API (or GraphQL query if that floats your boat).
This approach also forgoes many of the nice side-effects of having a clear slide-server boundary like avoiding leaking implementation details into your front-end code. Also, a simple REST API can be reused across platforms, so when you want a native experience on Android, iOS, etc you wont have to replicate this architecture or the underlying logic on each of those platforms.
I've been working on a project where we generate and synchronize view models (instead of full views like this proposal) between the server and web/app clients. We maintain (view)state in an Actor based backend, pushing updates to the clients through websockets. The client only needs to databind and render the model. This gives a really nice realtime user experience and is quite efficient.
Like SyncNinja, our architecture moves a layer of clientside code into the server. This enables more code sharing, at the cost of tight coupling between client and server (which does not matter for web but is problematic for our app clients). For use cases that need to work offline it falls apart; for that you need api's that work at the business layer and duplicate the view logic in each client.
I think SyncNinja will share difficulties we found around offline/localStorage, besides high resource usage, support for non-web clients, and all the problems you'd expect from browser differences (i.e. input prefill).
This is a startup, the application is not open source but everything we use is. We are building on the Microsoft stack, which might make it uninteresting for most of the HN crowd. Our main framework components are Orleans, Nancy, SignalR, Knockout.js and Xamarin. I think one could get the same results using Akka, express, socket.io, flux and React (or Ionic with angular)
It'd be interesting to hear about the issues you've found around SignalR and offline mode, as we are building on very similar stack so far and your experience can help others who are using Orleans
13 comments
[ 3.5 ms ] story [ 23.8 ms ] threadIt'll also introduce a very big attack surface for malicious agents to DDoS your server and possibly exploit the server-side V8 once an appropriate vulnerability shows up.
And it'll also produce application tightly coupled to browser API emulation, which would become an obstacle to the server being able to properly support native mobile and desktop applications.
I can put these issues aside for a moment, and attribute them to me being too cynical to believe in a new way of doing things.
But let's look at the benefits. This is the example being given for the kind of client code that SyncNinja would enable:
This is already possible to do on the client-side, in plain JS, and any kind of server, as a very, very thin wrapper around the available AJAX calls provided by the server web API.So my point is, I see no convincing examples of SyncNinja making something possible that wasn't already trivial before, and without the big overhead. Maybe you guys should work on what the value of this system is in practice.
Your "before" example doesn't show limitations of the browser, but simply a missing thin client library to abstract the AJAX calls.
Additionally, you have no prototype of this concept at all. Even a toy prototype with just one kind of event, or something. It sends the message that everything written in the paper doesn't come from experience, but it's merely hypothetical. And there's a giant leap from an idea to a working prototype.
Now to actually address it, I think it's more than just a thin wrapper. Perhaps the example shows too little, but for many developers, writing server side code and all the necessary communication is a road block. For others it's just extra stuff to maintain. And we generally like less code that does more.
I wouldn't worry about V8 vulnerabilities, there are many node servers running in production today, in general, and they are doing fine. But your DDos point is pretty fair - I can see how that could be a problem. Feel free to submit a pull request to add to caveats if you want to take credit for it.
The problem is your concept is more than just another server running V8.
It's a server running V8 with code, which is nearly identical to the code running on my client (it gives me a peak at the server code structure), and which accepts a quite wide range of events allowing me to model an attack that would trigger a V8 vulnerability on the server.
It would be much easier to do compared to a server which exposes a minimal API in a completely opaque way.
> Perhaps the example shows too little, but for many developers, writing server side code and all the necessary communication is a road block.
I'm not every developer, so I wouldn't know, but I think you overestimate the hurdles of server-client communication that developers encounter.
A server-side API has to be written one way or another, as it's a key asset to a company and it encapsulates its business logic in a platform neutral way. This means I can have web site running off of it, I can have an iOS app running off of it, a desktop app, and also a cron job that runs every night and generates reports, for example.
None of this would be possible if you tightly couple the app business logic with a browser emulator.
Recreating the business logic with every client will be a gigantic waste of time and money and a very rich source of bugs. No one would do it that way. There has to be a central API.
Also there are many libraries that would generate the necessary client code (wrapping AJAX calls) for you from an API definition, here are some random examples I just googled up:
- https://github.com/pksunkara/alpaca
- https://apimatic.io/
- https://github.com/ttezel/unio
Given the task is relatively trivial, and tools exist to automate it, I think a "road block" is too strong of a phrase to use here.
We talked with quite a few developers. There are many who want to launch their startup but have waaay less technical skills than you might think.
The way we thought of bridging the gap with mobile is by using Ionic and/or Apache Cordova, which use JavaScript.
This approach also forgoes many of the nice side-effects of having a clear slide-server boundary like avoiding leaking implementation details into your front-end code. Also, a simple REST API can be reused across platforms, so when you want a native experience on Android, iOS, etc you wont have to replicate this architecture or the underlying logic on each of those platforms.
Like SyncNinja, our architecture moves a layer of clientside code into the server. This enables more code sharing, at the cost of tight coupling between client and server (which does not matter for web but is problematic for our app clients). For use cases that need to work offline it falls apart; for that you need api's that work at the business layer and duplicate the view logic in each client.
I think SyncNinja will share difficulties we found around offline/localStorage, besides high resource usage, support for non-web clients, and all the problems you'd expect from browser differences (i.e. input prefill).