Enriching lightswitch with an angularJS client (part 1 of 2)

Introduction

This article is the starting point of a series on enriching a LightSwitch application with an full blown angularJS client.

I currently have no clue how many articles will cover this topic. Probably a lot because AngularJS is huge.

I have no full upfront design in mind but nonetheless, I have some initial thoughts about an architecture which should allow to integrate an AngularJS client in LightSwitch is a neat way where both LightSwitch and the AngularJS client keep there identity.

 

The base architecture user stories

In an attempt to illustrate the mindset, I’m starting here from two extremely simple yet powerful user stories:

 

 

As a developer I want to be able at any time to remove, without collateral damage,  the AngularJS client from the LightSwitch solution.

Being creative and introducing new things is good, but combining this with having the ability to go back to a previous situation in a way without collateral damage is even better.

What I mean here more concretely is that I want that a working LightSwitch application is never polluted with stuff belonging to the angularJS client.

So, imagine that our whole AngularJS client is just fully inside a folder in the LightSwitch server project. What I want is to be able to delete that folder, press F5 and still have a working LightSwitch project serving a LightSwitch html and/or Silverlight client.

Best case, the LightSwitch Server project should not contain any code (apart from the AngularJS client folder) specific for the AngularJS client.

So, this user stories emphasizes that things should be “LightSwitch-friendly”.  Our next user story is about “AngularJS-friendliness”.

 

 

As a developer I want to be able to copy/paste the AngularJS client right from the LightSwitch solution to another (OData)  backend and it should just work.

Obviously, that “other” backend should implement the same business logic and should deliver the same service as the LightSwitch back-end. In other words, the service interface should be identical.

This basically means that the AngularJS client should have no LightSwitch dependencies at all. My assumption is that given the fact we use BreezeJS as service proxy, we can connect the AngularJS client to any other backend supporting OData,

That could be  an Asp.Net (MVC) application based on an “EntitySetController”, which is a neat way of generating from an entity framework Edmx file Odata controllers. Note that is approach differs quite fundamentally from WCF Data Services, on which LightSwitch is based.

Another backend could be a MEAN Stack based backend (NodeJS, ExpressJS, MongoDb and AngularJS).

An even more ambitious route could be to develop the AngularJS client that supports via dependency injection multiple service proxy types. As you might know, BreezeJS expects, in the full out-of-the-box scenario a normal Web api controller, which differs obviously  from an OData endpoint.

 

Conclusion

Holy cow, that’s an ambitious mindset. I probably need some more time for the next article.