Show HN: SyncNinja – Mirroring browser execution on the server
github.com
github.com
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).
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);
});
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://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.