
Show HN: SyncNinja – Mirroring browser execution on the server - vladaionescu
https://github.com/syncninja/syncninja
======
zerovox
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.

------
Maarten88
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).

~~~
vladaionescu
Very interesting. Is your project open source by any chance?

~~~
Maarten88
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)

~~~
centur
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

------
rywalker
Project looks promising... Do you have source code to a demo app available?

~~~
vladaionescu
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.

~~~
SwitchLink
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.

~~~
vladaionescu
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.

~~~
SwitchLink
> 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:

\- [https://github.com/pksunkara/alpaca](https://github.com/pksunkara/alpaca)

\- [https://apimatic.io/](https://apimatic.io/)

\- [https://github.com/ttezel/unio](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.

~~~
vladaionescu
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.

