Introduction angular-meteor

[uri.goldshtein]

Hi everyone and thanks for inviting me to the team!

I’m Uri and I wrote the angular-meteor library - http://angularjs.meteor.com/

I hope I can contribute to the conversation after the work we've done with syncing Angular 1.x with Meteor’s reactive cursors and the DDP protocol.

In angular-meteor 1.x we are prototyping an array so that we can $watch it from the client side (and mimic an Observe API from the client) and Observe the same data from the server side to keep a full data binding.

We are also giving a option of running Angular on the server to create services and call them from the client.

Now I guess we have much less work as we can work directly with the Javascript array and there is no more 2 way data bindings...

Few general points I will probably discuss more within the threads:

1. API for calling change detection - Object or Array should have a standard API to notify change detection about what's changed. there is the suggested solution of requestCheck() notify the whole object/array has changed or we can use something more precise like - AddedAt, ChangedAt, MovedAt, RemovedAt.  it gives better understanding of what has changed and can help performance a lot (also in case one day change detection will be different).  It is very similar to the API Lovefield Observe Query and to Meteor’s cursor.observe are exposing.

2. Communication - I think Angular 2.0 support for HTTP and WebSockets should be a second priority to the first point I've mentioned. As the main goal of Angular 2.0 is to support large consumer facing apps, in most of those applications there are other solutions that take care of syncing the client’s data with the server over the communication layer.  it is a big shift of thinking about your app’s architecture but I think it is an important shift that needs to happen in Angular 2.0

3. Persistence - people will probably hate me for saying that, but I don’t think persistence suppose to be Angular’s job.  persistence and local storage suppose to be UI framework agnostic.  There are many types of solutions and architectures, some just take care of persistence and some adds latency compensation and conflict resolution between the server and the client.  Angular shouldn’t impose a solution. Also, solving that problem to the full extent is not an easy task as people tend to think.

4. Standard for WebSockets - If Angular does going to create a real time communication service, I wonder what this standard will look like. Reading Rob’s post on Sails’ blueprints is super interesting, it looks like their own implementation that goes in the same direction as the DDP protocol. if Angular 2.0 will support WebSockets, it needs to have a standard across technologies, like HTTP and REST. The only standard I know of is the DDP protocol. there are clients in Javascript, iOS, Java, .NET, Rails etc.. and it looks like the industry is starting to adopt.  If we are educating our users, standardizing WebSockets can be a great place.

Thanks and can't wait for more discussions,

Uri

[Benjamin Lesh]

I'm very interested in the web sockets discussion as well. But I don't think Angular, being a frontend framework should standardize on a single protocol. That assumes too much about the backend. For example, at Netflix, I'm much more likely to need something like the proposed Reactive Streams IO protocol.

Pub/sub is tricky and necessary, but there are ways around fixing it to a given protocol at the client.

--
You received this message because you are subscribed to the Google Groups "angular-data-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular-data-d...@googlegroups.com.
To post to this group, send email to angular-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/angular-data-dev/df4d44b0-0684-4552-bb84-77d7990db6e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Benjamin (Inglor) Gruenbaum]

I'm for standardising websockets and other communication protocols through observables for passing messages. I've used and enjoyed it before in my own code and we're already planning on shipping observables anyway. As for wrapping the observables with serverside change detection - that should be done in userland through decoration :)

To view this discussion on the web visit https://groups.google.com/d/msgid/angular-data-dev/CADcN1GC7Zb37Kj9Wnui2-81oma%2B%2BV_4tZ0%2BreTk6LcdDrx%3D%3DTw%40mail.gmail.com.

[Sander Elias]

Hi Uri

Welcome to the list.

I will go over your point 1 by 1

1. Have you seen Victors blog on change detection? 
   
2. To offer a complete solution, one needs to both. The low-level, and the high level. The low level needs to be low enough to enable everything. Not just the use case you can come up with, but all the other ones too. As you said yourself most applications. That is a far cry from all applications! Angular 2 needs to be inclusive.
3. I can repeat myself here. App-builders need persistence. Angular 2 should provide an consistent API across low level persistence, and communication. Beside that, it would be nice if we also provide a higher-level storage, with again, the same API. did you read through the document I posted?
4. Having read trough your DDP documentation, I think this is might be a nice addition. However, I feel this is more of a userland extension. It will fit a number of applications quite well, but the majority off applications will need to talk to existing back-ends. 

Welcome to this list! Let the discussions begin ;)
with kind regards

Sander Elias

[Jeff Cross]

Thanks for posting, Uri! Some great discussion items. I've added some comments.

On Sunday, April 26, 2015 at 7:30:32 AM UTC-7, uri.goldshtein wrote:

Hi everyone and thanks for inviting me to the team!

I’m Uri and I wrote the angular-meteor library - http://angularjs.meteor.com/

I hope I can contribute to the conversation after the work we've done with syncing Angular 1.x with Meteor’s reactive cursors and the DDP protocol.

In angular-meteor 1.x we are prototyping an array so that we can $watch it from the client side (and mimic an Observe API from the client) and Observe the same data from the server side to keep a full data binding.

We are also giving a option of running Angular on the server to create services and call them from the client.

Now I guess we have much less work as we can work directly with the Javascript array and there is no more 2 way data bindings...

Few general points I will probably discuss more within the threads:

1. API for calling change detection - Object or Array should have a standard API to notify change detection about what's changed. there is the suggested solution of requestCheck() notify the whole object/array has changed or we can use something more precise like - AddedAt, ChangedAt, MovedAt, RemovedAt.  it gives better understanding of what has changed and can help performance a lot (also in case one day change detection will be different).  It is very similar to the API Lovefield Observe Query and to Meteor’s cursor.observe are exposing.

I think you could actually create a pipe for this in the present design, and selectively override or bypass the iterableDiff pipe that "for of" template expressions get piped through, which has an algorithm to determine removed items, added items, moved items within the list. Since you already know the exact mutations that occurred, you could save the work of that algorithm. But, I am skeptical the performance gains would be significant (we could benchmark this to see, perhaps in Vegas next week).

 

1. Communication - I think Angular 2.0 support for HTTP and WebSockets should be a second priority to the first point I've mentioned. As the main goal of Angular 2.0 is to support large consumer facing apps, in most of those applications there are other solutions that take care of syncing the client’s data with the server over the communication layer.  it is a big shift of thinking about your app’s architecture but I think it is an important shift that needs to happen in Angular 2.0

A socket library to add some good testing and ergonomics is on the roadmap. It won't be very prescriptive on how an application should use sockets though.

 

1. Persistence - people will probably hate me for saying that, but I don’t think persistence suppose to be Angular’s job.  persistence and local storage suppose to be UI framework agnostic.  There are many types of solutions and architectures, some just take care of persistence and some adds latency compensation and conflict resolution between the server and the client.  Angular shouldn’t impose a solution. Also, solving that problem to the full extent is not an easy task as people tend to think.

Our focus in the near-term is providing good testability and ergonomics around native persistence APIs, and working with third-party libraries and services who focus more deeply on persistence solutions. We've been working with teams like Lovefield, Falcor, Firebase (and you on angular-meteor!) to support those efforts integrating with Angular any way we can. Long-term, we may build higher-level libraries for specific kinds of applications, but you're right that we shouldn't impose a solution, and that the problems are complex and hard to generalize for all angular applications.

 

1. Standard for WebSockets - If Angular does going to create a real time communication service, I wonder what this standard will look like. Reading Rob’s post on Sails’ blueprints is super interesting, it looks like their own implementation that goes in the same direction as the DDP protocol. if Angular 2.0 will support WebSockets, it needs to have a standard across technologies, like HTTP and REST. The only standard I know of is the DDP protocol. there are clients in Javascript, iOS, Java, .NET, Rails etc.. and it looks like the industry is starting to adopt.  If we are educating our users, standardizing WebSockets can be a great place.

I'm happy to help prove out and push forward a good, simple protocol for realtime communication, but I'm not the right person to champion it :).