Working With Social Network APIs

Creating Vicinity Buzz naturally involved working with a the APIs of social networks. That information seemed worth sharing for those of you interested in writing any type of application that would integrate with a social network.

Developer Documentation

Any of the social networking sites you probably want to integrate with have developer api’s that are well documented. Here’s the starting points for a variety of services:

Working With JSON

All of these APIs are best used with JSON. If you’re not familiar, you can read up at json.org. It’s the notation for serialization of javascript objects, and object literals.

Where To Make the Call From

If you are working in a standard web page, you could call the api from document.ready (assuming you are using jquery). This is the approach I take on hoolihan.net, my personal homepage. There is a twitter feed on the right side.

If you have a bit more of an application, you may want to look at one of the many javascript frameworks that help you route events to actions. These are frameworks like backbone, knockout, spine, etc. There are also commercial variants like kendo, dojo, and sencha.

jQueryMobile is commonly paired with PhoneGap, and in that scenario, using something like backbone is a bit tricky. You may want to bring in a template binding library, but avoid routing.

Binding

jQuery.templates was one of the first good javascript template binders that I’m aware of, but there are now many different options. In the jQuery world, most of the momentum seems aimed at jsrender. Recently I’ve considered bring in knockout and only using the binding part, but I’m not far enough in to evaluate that direction.

API Keys

Unless you’re using the most basic parts of the API, you’ll probably need to register your app and get an API key. It’s a token that identifies your application. In the event of API abuse (too many calls, etc), they have information to contact you and analytics around the issue.

Open Authentication

This is a big topic, but if your application wants to use a social network to identify your users, this is possible via open authentication. If you are interested in this, get started here.

What Do You Think?

Are there any particular areas of the APIs that you’d like to see more detail about? Any conceptual parts that would warrant their own post? Let me know what you think below.

Interesting Assignment Related to Rich Internet Controls

One or my recent projects was to work with a client to create a Silverlight control for reporting purposes that has some general flashiness, and is reusable across several sections of the site. It has brushed into some interesting areas. I have used Silverlight for some media and imaging applications before, but this was the first that the control had to integrated with the authorized users profile and other security related server side settings.

In particular, the first thing to keep in mind is that as long as the Silverlight Enabled WCF endpoint is within the web application on IIS, then the service code has access to the users profile info. It’s just as if making a jquery request from a page, there is no need for the Silverlight control to re-authenticate.

The really interesting part is where the project goes from here. The client has asked me to create an equivalent control using HTML 5 technologies. There will be some lunch and learn sessions on how both of these projects were done, and comparing and contrasting both the user experience and developer experience.

I’m excited about doing this type of work for a variety of reasons. First, the training aspect really helps our company differentiate from other consulting companies, especially from rent-a-coder staff augmentation type shops. And I enjoy the challenges and rewards that come with helping other developers work with tools that are new to them. Finally, the very question we’re addressing (plugin vs standards based RIA controls) is on the forefront of lot of minds, given the current state of browser and mobile applications.

Anyway, this is just a general update of what I’m up to, but I hope this work will spin off some presentations I can do locally, and some blog posts.

Datalayer Decisions (Repository, DAO, Services) in Domain-Driven-Design Applications

I have been working several applications lately at work that use Domain-Driven Design.

I had a couple of questions about design choices I saw made in the applications I’m working with. I recently talked to an architect who uses DDD a lot (Model first), and had the chance to pick his brain. Here’s what I came up with. I’d be curious to hear other opinions via comments:

1. Why choose Repository vs DAO pattern or vice-versa? I even found some Spring posts recommending both.

Answer: Repository fits nicely on a legacy schema. If you’re domain objects do not match the database, then there this pattern works better. For green field, DAO choice means you can simplify mapping, because your schema is under your control.

One additional consideration: DAO model first means that your database may not be normalized and / or friendly for reporting tools etc. If you are in an enterprise setting, that reporting should be done off of a separate schema anyway (data warehouse). The warehouse records can be written in the service layer (see question 2) or extracted via an ETL process batch job. If this is overkill, then you may want to use Repository and map to a friendlier schema.

In the case of using both repository and DAO, this seems to be of value when you are not using an ORM. The DAO simply manages CRUD for one table, and the Repitory layer handles joining and translating entities into domain objects.

2. What is the purpose of a service layer that encapsulates a DAO or Repository?

Answer: There are various concerns that relate to the application, but not the domain model. For example, a Product model will have validation that is true in and of itself. For example, it must have a name, and that name is 50 characters or less. But in the context of an order, there may be additional validation rules that involve various domain models in the context.

So the service layer should provide a single interface for various actions related to domain that the User Interface layer should call. So for instance, a web application has an admin section where I want to delete a product. And a product can only be deleted without orders.

Top to bottom, the stack looks like the following:

  • Web application: Sends request to Product Service to delete a product
  • Product Service:
    • Calls OrderRepository to validate there are no related orders
    • Calls ProductRepository to delete Product

That is rather simple logic in the service, but why should the product repository know about the order repository? These services serve as single endpoints for user interface programmers. They can simply request a product deletion and handle appropriate validation messages / errors. They don’t care about context validation, model validation, and all the sub steps involved, that is handled for them.

And each class follows the single responsibility rule.

Integrating Internet Services on Your Site (Or Mini-Cloud Web Sites)

Something I’ve been increasingly fascinated with over the last year is the reuse of free internet services that I have. On my site, I have widgets that feed the last 4 posts from this wordpress blog, and my twitter feed. I also have an ajax live bing search box that will return results from my site, or the web in general. Most recently, I setup my default page to show a random image from a set I have on flickr.

Separately, over on linkedin, any blog posts that I tag “linkedin” show up. And I have a google docs presentation integrated into my profile. All of these integrations were free, and pretty easy to do. Many of them involved copy and paste html. A few involved calling api’s, but they were easy to use and well documented.

And I haven’t touched the tip of the iceberg. Last.fm, Delicious, google calendar, and more all provide feeds and widgets that I’m not yet taking advantage of. And there are creative ways to use these differently than intended.

It’s easy to write a twitter widget, that doesn’t appear to be twitter. Drop it on a client’s site, and they can add news blurbs via twitter or sms. It’s a small piece of content management that couldn’t be easier to integrate.