Astoria

I was going to write a blog post on Astoria but Pablo's post says almost everything I was going to say.

I fully agree with him, in that there are multiple scenarios where the default implementation will be good enough, and it's much more productive than what we have today.

The fact that you can further filter the results of methods like 'CustomersByCity' is a significant step forward compared to the static service interfaces we usually have today. 

On the other hand, the client-side library has a WebDataContext class that knows how to track changes in the client. The problem is that as the EF does not have a change-tracking serialization mechanism (see previous  posts) the way they have to post a set of changes to the server is by executing multiple HTTP requests, which is obviously a bad thing.

The good news is that I think there's no way they can ship Astoria this way, so they'll need to come up with a good disconnected story ;).

Pablo also mentioned in his presentation that you'll be able to upload your EF model and the Astoria live service will create the tables in the database and host up to 100Mb of data. That's quite interesting, and it means they'll need to tackle another problem (which it's solved quite well in DeKlarit) which is how to keep your data stable when you deploy a new version of your model.