One useful feature of modern JavaScript libraries is 2-way data-binding. All interactive websites perform this functionality one way or another, but only a few libraries such as Ember.js, AngularJS and Polymer don’t require a single line of JavaScript.
In the years 2002-2003, Internet Explorer captured 95% of world-wide browser market share. It was unfathomable to many that over the next 10 years IE would decline to just over 15%.
At the heart of a web page, there are UI elements and these elements interact: with the user, each other, and the server. Although HTML5 expanded the original set of elements to include audio, video, and date pickers, there has been no standard way to define custom elements. Elements not specified in the HTML specification have had no support thrusting this responsibility onto client-side and server-side web frameworks.
There are 2 new principles at the vanguard of today’s technology:
The key to high availability is redundancy; it follows that if uptime matters, Finagle needs to be deployed to multiple servers. This article walks through both the basic multi-host configuration using finagle-core, and a more robust deployment scenario utilizing the finagle-serversets module.
The Separation of Concerns (SoC) pattern is one of those software architectural choices that everyone is helpful. It increases clarity, shortens the amount of code in the working context, and minimizes the chance of side effects. For example, two concerns that should not require entanglement: updating data and cache invalidation. Both are related, but one is concerned about business logic and database access, while the other deals with the cache servers. Finagle’s generated FutureIface can be used to keep these two separate.
A 30-minute presentation on Sept 19th at the Scala-Toronto Meetup. The slides introduce a technical application of Apache Thrift and additional features offered by the Twitter Finagle.
This is an obscure issue, with an easy workaround, but no obvious solution.
Long-running queries are very taxing on a database because they hold on to resources making them unavailable to other requests. And what happens if multiple identical requests are made while one is still running? Is there a natural way to share the same result, or do each request need to perform their own? This isn’t a simple caching solution, it’s more like a subscription behaviour to a running query if one already exists, if not one is created.
In a Service Oriented Architecture, a service may be used by many different clients – each with different usage patterns and performance profiles. Behind a corporate firewall, without each client authenticating itself to our server, how can monitor a specific client if we can’t identify their requests?
One of the largest headaches associated with network system architecture is abstracting away the network. External resources are always slower and more disjoint than working locally. While there are various caching techniques, few are suitable for use in a development environment.
When using Thrift, Finagle Filters on the client inherit from SimpleFilter[ThriftClientRequest, Array[Byte]], while on the server they must inherit from SimpleFilter[Array[Byte], Array[Byte]]. In this article, we will demonstrate one approach to creating a dual-function filter without repeating code.