17. May 2013 10:53
Azure is growing at an incredible pace and provides a good balance between lots of great services and easy ways to get started. I recently took a look at Azure mobile services, which seems to be an offering that has an interesting future with the rise of mobile development. So building a platform around features that you need to build these kinds of applications make all kinds of sense. Wanting to look more at Azure and with my recent focus on mobile it seems like a perfect fit for me.
Naming is hard
Diving into it you quickly become aware that the words "mobile services" are somewhat misleading, because although the service can be used for mobile it is just as much for building any other kind of small application. Only directly targeted mobile feature is push notifications. The featuers for working with data, scheduling and identity are very general purpose, but as a package this seems like a good idea - even though it name could be limiting to who will end up using it.
6. May 2013 14:31
While looking at how you can do your common scenarios in F# an obvious thing to look at is data access. I already covered type providers which are fantastic for consuming data. However type providers won't help you when you need to create data or in other ways interact with your SQL database, MongoDB, RavenDB or any other NoSQL solution you might be using. For this you will most likely want to use some of the libraries you already know and love - there is no reason to reinvent everything.
Working with existing libraries is mostly trivial, but F# likes types that are immutable which straight out of the box doesn't play well with serialization and mapping. This means that ORM's and libraries for MongoDB and RavenDB will throw exceptions when they try to construct your F# types. This basically boils down to the fact that code like the sample below won’t work, because the serializer can not instantiate the type and fill in the values.