Circuit Breaker design pattern and library for Swift

Working with REST services can be extremely error prone. You could have latency, network failures, or at worse case even total down time. I have been writing a lot of code as of late that requires extreme error handling and graceful failing when dealing with remote REST services and in general web calls – like parsing or loading external web sites for DOM evaluation as an example. The issue is you can’t trust the performance or even trust the service is even available and knowing what methods are failing or causing the bottlenecks could be extremely cumbersome. You could implement network profilers to capture what is going on, or, you could implement a CircuitBreaker design pattern and take control of your calls yourself.

Welcome the Circuit Breaker design pattern. This pattern allows you to monitor a specific function call and “break” gracefully if it has taken too long or even fails. This is usually symptomatic with asynchronous calls that may require calling other code on completion, fail, or timeout. Methods like jQueries ajax where you supply the various error, complete, and done methods work great and even languages like Swift and Java have similar callbacks but it lacks data around the calls. The CircuitBreaker design pattern will make your code easier to follow for race conditions and it can even track statistics around the calls…

If you are a Swift programmer you can check out the Swift CircuitBreaker project on GitHub. It has complete documentation and makes using this design pattern very easy and straightforward.

Now, what sets this package apart in my opinion is it also gives a large set of statistics around the calls. Capturing how long calls take (latency), how many successes, failures, and even average response times.  From an SLA perspective this is great! You can then quickly identify what remote calls to “other” services are the primary bottlenecks or problems in your application.

Why IBM adding SWIFT to the cloud is a huge game changer.

IBM + Swift

Long ago we use to dream about writing server software in the language we write the client software in. Then came Java, the end to all arguments, Java everywhere, etc. The only problem was there were a few camps that didn’t totally buy into Java everywhere and in some cases banned the virtual machines existing on devices, like the Apple products. Similar to what happened with Adobe Flash. I do believe this was a huge step in killing Java, in the end, people are going to choose the popular language but having a strong ecosystem on both ends is critical for programming languages. I have to mention .NET because it really has achieved this nirvana for the Microsoft world. The .NET platform is certainly a platform to be reckoned with, it even runs on Linux. The biggest problem for .NET is according to WinBet.org Microsoft’s market share in the United States is only 2.8% for mobile devices – if this was a Presidential candidate they would be bowing out by now.

So then came a technology called Node.js. Once again a proper stab at using the same language in the client applications as you use on the server and in this case it’s JavaScript. The only problem was language enthusiasts still debate whether JavaScript is even a full language. Here is a really nice article for the uninformed about JavaScript. I personally believe Node.js is great; everything I have done in Node has been dead simple and easy. But I also noticed a problem, a shift in the market per say, in mobile applications. Companies began moving away from hybrid applications and began investing in native mobile applications. Specifically almost every vendor I work with asks about the Apple platform support for business applications (not really customer facing). I am talking about check out terminals, store associate applications, inventory apps, pick and pack, check-in/check-out devices,etc. I never hear the Android discussion come up for these kinds of devices.

So now we have a dilemma, we are back to different client and server languages. Interestingly enough, the IBM BlueMix services are REST base so you don’t really care what the server platform is, however, if you are developing the server and the client facing application you do care what languages are used. So I started seeing myself creating Node applications in BlueMix and Swift based applications for the devices – two very different languages and skill sets needed; and I am still not a good Swift programmer even after a couple of apps.

Now comes what I consider a huge announcement:

Apple just gave IBM a huge leg up in the cloud wars with Amazon

IBM’s partnership with Apple bears even more fruit today as theIBM Cloud becomes the first cloud computing platform to support the smash hit Apple Swift programming language.

 

We can now take an awesome full featured language like Swift and use it in both server and client applications. And most will agree Swift is an amazing and fun language to program in. Think of Swift as the language of the best of the rest. Swift brought in the best features from many languages all rolled up into one.

The question is how long will this last? Will it grow the Apple marketshare? Could this be the nirvana we are looking for? I am very interested in hearing others feedback on this.

So now all of you Apple iOS developers should go over to the IBM Swift page and check out what Swift you can do on the BlueMix servers!

Playing in the new Swift playground

apple-swift-logoPlaygrounds are not a new concept in software development. I have always had that “Test” project with all kinds of different code blocks that I wrote for some project or tested out ideas for creating more optimized code. I figure I would test out the new Swift playground and see what it’s all about.

In case you don’t know what a playground is, here are some great things you can use playgrounds for:

  • Learning to code
  • Testing out new algorithms quickly
  • Creating a complex mathematical formula and get results quickly -for instance, I use Excel almost exclusively as my calculator application
  • Interact with a running application

Learn more about playground on the Swift site here.

My Good and Bad on the new language Swift from Apple

apple-swift-logoI am a tech geek, I love coding and I certainly love learning new languages. My first look at Swift is only through the eyes of reading the manual, yes, some people like reading novels I like reading manuals. I have yet to download and play around with it so this is a more of a blind analysis than a hands on review. So let’s start with what I really like about the language.

The Good

Continue reading