DEV Community: Greg Navis

Elixir-style Pipelines in 9 Lines of Ruby

Greg Navis — Mon, 24 Apr 2023 10:39:38 +0000

Elixir pipelines are an elegant construct for sequencing operations in a readable way. Fortunately, 9 lines is all it takes to implement them in Ruby.

Background: `<<` and `>>`

Ruby offers some pipelining primitives. Proc and Method respond to #<< and #>>, which can be used in pipelines:

FindByLogin = proc { |login| ... }
ConfirmUserAccount = proc { |user| ... }
SendConfirmationNotification = proc { |user| ... }

(FindByLogin >>
  ConfirmUserAccount >>
  SendConfirmationNotification).call("gregnavis")

This approach has several drawbacks:

The Proc returned by #>> cannot be called using result(...), but only via proc.call(...) or proc.(...) or proc[...], which is inconsistent with regular method calls. Admittedly, this is unavoidable, but can be made to matter less.
The pipeline argument comes at the end, but having it at the front would be more readable and more consistent with the pipeline structure.
Operations taking more than one parameter must be implemented as higher-order procs or use currying. Introducing or eliminating additional parameters entails switching between regular procs and higher-order or curried procs.

To illustrate the last problem, let's make SendConfirmationNotification take an argument determining the type of notification: e-mail or SMS. It has to be rewritten as:

# Using a higher-order proc.
SendConfirmationNotification = proc do |method|
  proc { |user| ... }
end

# Using currying; notice .curry after the block
SendConfirmationNotification = proc do |method, user|
  ...
end.curry

Unfortunately, the pipeline still suffers from the problem of argument coming at the end:

(FindByLogin >>
  ConfirmUserAccount >>
  SendConfirmationNotification[:sms])["gregnavis"]

The rest of the article shows how to use Ruby refinements, a built-in but relatively obscure facility, to make the code below work:

"gregnavis" >>
  FindByLogin >>
  ConfirmUserAccount >>
  SendConfirmationNotification[:sms]

Let's start with operator definitions. Monkey-patching will be used initially, but will be replaced with refinements by the end of the article.

Step 1: Defining Parameterized Operations

Parameterized and parameterless operations should be defined the same way. A new Kernel method will help here:

module Kernel
  def operation(...) = proc(...).curry
end

Basically, operation is an automatically curried proc. The pipeline can now be defined as:

FindByLogin = operation { |login| ... }
ConfirmUserAccount = operation { |user| ... }

# Notice user comes last.
SendConfirmationNotification = operation { |method, user| ... }

Due to currying, the first argument to SendConfirmationNotification can be provided in the pipeline, while the execution is "paused" until user is provided, too. The code below now works as expected:

(FindByLogin >>
  ConfirmUserAccount >>
  SendConfirmationNotification[:sms])["gregnavis"]

The next goal is moving the pipeline to the front.

Step 2: Piping Arguments into Callables

The following two expressions should be equivalent:

# When we write this:
argument >> callable

# we actually mean this:
callable.call(argument)

The snippet hints at what needs to be done: all objects must respond to >> and that method must call call. A top-level class (Object or BasicObject) must be modified to make #>> available on all objects, resulting in the following patch:

class Object
  def >>(callable) = callable.call(self)
end

Finally, we're able to write:

"gregnavis" >>
  FindUserByLogin >>
  ConfirmUserAccount >>
  SendConfirmationNotification[:sms]

The patches on Kernel and Object must be turned into a refinement to avoid global monkey patching.

Step 3: Introducing Refinements

Refinements are a topic for a separate article, but in short they are monkey-patches that can enabled inside a specific module or class by calling Module#using. Let's approach the problem outside in by starting with how we want the code to be used.

Suppose we're working inside a Rails controller. We'd like to be able to write code like this:

class UsersController < ApplicationController
  using Pipelines

  def confirm
    params[:login] >>
      FindUserByLogin >>
      ConfirmUserAccount >>
      SendConfirmationNotification[:sms]
  end
end

using is built into Ruby, and Pipelines is the refinement to be defined. It's an ordinary Ruby module that refines (i.e. patches) Kernel and Object:

module Pipelines
  refine Kernel do
    def operation(...) = proc(...).curry
  end

  refine Object do
    def >>(callable) = callable.call(self)
  end
end

That's it! Pipelines are now enabled only in UsersController, and no other code will be affected. Keep in mind you need to be using the refinement when defining operations too (so that operation is available).

Summary

That pipeline implementation would fit on a napkin. Let's have a critical look at this approach.

First, calling a curried proc with no arguments keeps the execution "paused", so missing an argument can make the pipeline return a curried proc, instead of the expected return value. This will likely lead to difficult to understand errors later in the program.

Second, procs are difficult to inspect. Seeing #<Proc:0x...> in the terminal is unhelpful when debugging. It is possible to inspect parameters passed to an operation via operation_object.binding.local_variables and operation_object.binding.local_variable_get(name) for parameters of interest. It'd be more helpful if inspecting an operation produced something along the lines of SendConfirmationNotification[method: :sms].

Next Steps

The above was my second approach to implementing pipelines. The first approach was object-oriented and didn't have the drawbacks mentioned above at the expense of slightly more complex implementation. I'll cover it an an upcoming article.

API Integrations: Client Classes and Error Handling

Greg Navis — Tue, 23 Aug 2022 13:41:38 +0000

The way API clients signal results and errors is critical to integration quality, especially for under-documented APIs.

The previous article introduced the concept of the client class - the class implementing all interactions with a specific third-party API. A dedicated class is a step in the right direction, but is insufficient to guarantee quality unless properly implemented.

In this and following articles, we'll discuss how to build robust client classes. Let's start with the problem of error handling.

Problem Statement

A robust API integration must be prepared to handle errors that absent from integrating with own code. For example:

Unavailability due to network or service disruption.
Unexpected results or errors as there's much more things that can go wrong: wrong HTTP headers, wrong encoding, invalid payloads and many others.

Consequently, error handling and recovery is central to a quality API integration. We'll cover four approaches, ranging from familiar (exceptions) to exotic (result monads).

Method 1: Exceptions

The most familiar approach is using a return value on success and raising an exception on error. This behavior is prevalent in Ruby and other languages. Simplicity and familiarity are its advantages:

Everyone knows how to raise exceptions, which makes the client class code easy to read and write.
Everyone knows how to rescue exceptions, which makes error handling code easy to write (but not necessarily read).
Unhandled errors cannot go unnoticed, as unhandled exceptions will result in a server error.

Regrettably, there are subtle downsides:

Exception-based control flow is non-idiomatic and less readable.
Exceptions caused by API errors and internal client class bugs are lumped together; distinguishing them requires extra care.
When working in the console, exceptions caused by API errors must be rescued and assigned to a variable for further inspection.

The last point is especially bothersome when working with under-documented APIs. They require much more exploration and experimentation, so developer convenience becomes crucial.

When using this method, it makes sense to define a dedicated exception class for API errors to make it easier to distinguish them from client class bugs. For example, the What Weather API from the previous article could define WhatWeather::ServiceError and use it like in the snippet below:

def show
  begin
    weather = $weather.find_by_name(params[:name])
  rescue WhatWeather::ServiceError
    # If the API returns an error then return a 200 and an error message.
    # Exceptions unrelated to the API will propagate up the stack and likely
    # cause an internal server error (as they should!).
    render "unavailable"
    return
  end

  # Happy path continues here
end

This brings us to the next method which addresses these drawbacks elegantly and idiomatically.

Method 2: Tuples and Pattern Matching

The Go-inspired alternative is to return [:ok, result] on success and [:error, details] on error, with exceptions left for truly exceptions situations, like inconsistent internal client state.

This method coupled with pattern matching, which landed in Ruby 2.7, results in idiomatic and readable control flow. The snippet below calls the imaginary What Weather API and uses pattern matching to decide what to do next:

def show
  case $weather.find_by_name(params[:name])
  in [:ok, result]
    @weather = result.current_weather
  in [:error, :timeout] | [:error, :unavailable]
    render "unavailable"
    return
  end

  # Continue with the happy path.
end

Flow control for successes and errors is unified and it's still possible to raise an exception when needed. Let's discuss two concerns related to the method, followed by its drawbacks.

First, if the client return value matches no cases then NoMatchingPatternError will be raised. It's helpful in identifying all errors occurring in the wild, but may be too radical. If that's the case then a generic [:error, _] catch-all pattern and a log statement with error details should be suffice.

Second, raising an exception on API errors may sometimes be preferable. In those cases, the client class can offer bang methods, like #find_by_name!, that call the non-bang version under the hood but raise on error.

Evidently, all drawbacks of method 1 were address but there's a new one: if an API call isn't wrapped in case then execution will continue along the happy path even upon errors. Fortunately, this problem can be solved with static code analysis which leads us to the third method.

Method 3: Tuples, Pattern Matching, and Linting

Given the API client is available via a global variable, it's likely that most, if not all, API calls will be made through that variable. This makes it easy for a custom linter rule to inspect all method calls on that global and ensure they're wrapped in case.

The linter could work like that: a configuration setting lists all global variables to check. Whenever a method is called with a global from the list as the recipient then the linter should ensure it's inside a case statement.

If building a custom linter rule is infeasible (thought, it's not as difficult as it sounds) then a makeshift approach based on grep may be good enough. For example, detecting all method calls on $weather that aren't wrapped in case could be accomplished with grep -r '$weather.' . | grep -v 'case $weather'.

Method 4: Result Monads

Monads deserve a separate article, so we'll describe them briefly and use dry-monads in examples that follow.

A result monad resembles a polymorphic implementation of booleans with a more sophisticated interface. There are two types of results: successes and failures. A success wraps the result of a computation (an API call in our case); a failure wraps an error description. A result can be transformed into another result via a method called #bind. When it's called on a successful result, it passes the wrapped value to a block and returns another result (a success or failure). When it's called on a failure then it does nothing and lets that failure propagate forward. There's similarity to short-circuit logic of boolean operators.

Result moands shine when composition is required, so let's enhance our example controller action: it geolocates us via the $geolocation monad-based service and then returns the weather at our location. A monad-based version of the weather API client class could look like in the following snippet:

class WeatherService::WhatWeather
  # Required to access monad-specific features.
  extend Dry::Monads[:result]

  def find_by_name(name)
    result = http_client.get(
      "/api/weather",
      params: { name: name },
      headers: { "X-API-Key": api_key }
    )

    if result.status == 200
      # Build the weather object and wrap it in a success monad.
      Success(build_weather(result))
    else
      # Extract error details from the response and wrap it in a failure monad.
      Failure(result.json)
    end
  end
end

The controller action would use $geolocation.locate_request followed by $weather.find_by_location. Both methods return result monads that can be combined using #bind:

def show
  weather =
    # locate_request returns either a success or failure.
    $geolocation.locate_request(request).bind do |location|
      # #bind on a success unwraps the value and processes them further via this
      # block. $weather.find_by_location returns another result which becomes
      # the result of the whole computation.
      #
      # However, if geolocation fails then #bind will be called on a failure and
      # would NOT call this block. It'd simply return the original failure.
      $weather.find_by_location(location)
    end

  # weather is a result monad, NOT the actual value.
  if weather.success?
    # Forcibly extract the weather value.
    @weather = weather.value!
  else
    render "unavailable"
  end
end

Monads may look unfamiliar and may require some time to learn. However, frequent composition of operations (not only third-party API calls) can make them a worthwhile investment.

Conclusion

We've discussed four different approaches to error handling. Methods 3 and 4 may be my personal favorites, but the real point is to broaden the inventory of techniques at our disposal, so that we're capable of making the right choice after taking the project state, goals, and team into consideration.

This article has originally appear on my website.

API Integrations: Building Client Classes

Greg Navis — Fri, 22 Jul 2022 09:59:34 +0000

Code speaks louder than words, so we'll go through an example integration with a weather service, called WhatWeather, that returns current weather conditions by latitude and longitude or city name. Let's describe that imaginary service briefly and then proceed with the integration.

WhatWeather API Overview

WhatWeather API is accessible over HTTP and offers one endpoint that can be used in two ways:

/weather?lat=...&lon=... returns weather conditions at the given coordinates.
/weather?name=... returns weather conditions in the given city.

The API responds with a 200 OK and a JSON object containing two keys: "temperature" and "humidity". Authentication is handled via a token passed in a custom header named X-API-Key. Any other status code, even in the 200-299 range, can be assumed to be an error.

Step 1: Build Client Class

First, we must define the client class interface. Even though the WhatWeather API offers one endpoint it makes sense to have two separate methods: #weather_by_coordinates and #weather_by_name. We should strive for maximum code clarity, not mirroring the structure of the underlying API.

Second, we need a namespace (a Ruby module) for all weather-related code. Its name shouldn't refer to a specific API provider to keep the code generic and avoid coupling to a specific vendor. WeatherService seems like a reasonable name.

Third, we need a class representing results returned by the weather service. In simple cases, a Struct should be enough, like the one below:

WeatherService::Weather = Struct.new(:temperature, :humidity)

In more complex cases, a custom class might be needed. It's important to make them independent from the actual API provider -- otherwise, it might become an octopus whose tentacles reach to the very depths of the app. For example, the client class should parse and convert HTTP responses into instances of WeatherService::Weather and similar classes so that if their API change there's only one place in our code base that needs to be adapted.

We're ready for the fourth and final step: implementing the actual client class. We can use a third-party client gem or interact with the API via HTTP, GraphQL or another protocol. Whatever method we use, it's important to keep the point from the previous paragraph in mind -- don't let the actual client implementation leak through the client class and flood the rest of the code.

The example client below takes an HTTP client object via the constructor. Keep in mind it's not production ready as its input validation, error handling, and response parsing is rudimentary but is enough to illustrate the idea.

class WeatherService::WhatWeather
  def initialize(http_client:, api_key:)
    @http_client = http_client
    @api_key = api_key
  end

  def weather_by_coordinates(coordinates)
    result = http_client.get(
      "/api/weather",
      params: { lat: coordinates[0], lon: coordinates[1] },
      headers: { "X-API-Key": api_key }
    )
    return [:error, reason: :invalid_response] if result.status != 200

    build_weather(result)
  end

  def weather_by_name(name)
    result = http_client.get(
      "/api/weather",
      params: { name: name },
      headers: { "X-API-Key": api_key }
    )
    return [:error, reason: :invalid_response] if result.status != 200

    build_weather(result)
  end

  private

  attr_reader :http_client, :api_key

  def build_weather(result)
    [
      :ok,
      WeatherService::Weather(
        temperature: result.json.fetch("temperature"),
        humidity: result.json.fetch("humidity")
      )
    ]
  rescue KeyError
    [:error, reason: :invalid_response]
  end
end

Much more can be said about implementing client classes but the above example is enough to proceed to the next step: integrating the client with the app.

Step 2: Integrate Client into App

For simplicity, we assume there's one client instance in the whole app. This assumption is safe when the class is stateless but might need to be revisited in more complex scenarios. It doesn't affect the gist of the method, though.

The client must be instantiated early in the boot process and be accessible from various places throughout the code. Ideally, it'd be possible to inject it as a dependency to each controller it but sadly it doesn't seem to be possible (or at least it's non-obvious). We're left with using some kind of global state.

I used to rely on module attributes (like WeatherService.client) but have changed to using actual global variables, e.g. $weather_service. I find it much cleaner than a de facto global masquerading as a method call.

The best place to instantiate the client is a Rails initializer. The weather service client can be instantiated in config/initializers/weather_service.rb:

Rails.application.config.to_prepare do
  $weather_service = WeatherService::WhatWeather.new(
    http_client: HttpClient.new,
    api_key: ENV.fetch("WHATEVER_WEATHER_API_KEY")
  )
end

We can now use $weather_service whenever we need to make an API call. That's not the end of the story, though, as there are benefits to be gained in testing and development.

Step 3: Testing

The test suite shouldn't depend on any third-party APIs as this would make it flaky and dependent on Internet access. Fortunately, with a global client instance it's trivial to mock it.

The first step is mocking the client before each test case and cleaning it up afterwards. We're using MiniTest and Minitest::Mock below but the same idea applies to other test and mocking frameworks.

class ActiveSupport::TestCase
  setup do
    @old_weather_service = $weather_service
    $weather_service = Minitest::Mock.new
  end

  teardown do
    $weather_service.verify
    $weather_service = @old_weather_service
  end
end

Now, each test case can declare weather service methods it needs along with their desired return values. For example, the code below will make the weather service return a predefined value for NYC:

$weather_service.mock(
  :weather_by_name,
  WeatherService::Result.new(temperature: 80, humidity: 63),
  ["New York City"]
)

Creating test cases for edge cases or errors is a matter of making the mock service return an appropriate value or an exception.

Let's turn our attention to the benefit this approach can yield in development.

Step 4: Development

Interacting with the app is an essential component of the development feedback loop. However, hitting a real API in development can make it difficult to explore edge cases (unlikely return values or errors). For example, we can't force WhatWeather to lie about the temperature in New York. That's another situation where our approach comes in handy.

The solution is a development-specific client class returning stubbed responses. For example:

def weather_by_name(name)
  case name
  in "New York City" then Result.new(temperature: 5, humidity: 50)
  else Result.new(temperature: 65, humidity: 47)
  end
end

Other edge cases, including errors and exceptions, can be implemented in the same way.

Switching between the real and stub API client can be a matter of configuration. For example, the client initializer file can be modified to read:

Rails.application.config.to_prepare do
  case ENV.fetch("WHATWEATHER_CLIENT", "production")
  in "production"
    $weather_service = WeatherService::WhatWeather.new(
      http_client: HttpClient.new,
      api_key: ENV.fetch("WHATEVER_WEATHER_API_KEY")
    )
  in "development"
    $weather_service = WeatherService::StubWhatWeather.new
  end
end

Now, the client can be chosen by setting WHATWEATHER_CLIENT to "production" or "development".

Further Steps

We outlined a high-level approach but have skipped many implementation details that need to be addressed in a real production system. For example:

Establishing client configuration patterns. What variables are needed? How are we going to configure stub and production clients?
Making it easy to switch between stub and production clients.
Client input validation, response parsing and error reporting.
Creating a set of specialized client tests that make use of the real API to ensure the client is working correctly.
Maintaining multiple clients (or service objects in general) and their relationships.

These decisions can only be made after taking a specific project's circumstances into account. We also need to be aware of the drawbacks of this approach in order to manage the risks and challenges they introduce:

Global state makes it possible to use the client from anywhere without an explicit dependency. It's easy to use the client from a model which, in general, should be discouraged.
Complex integrations, like Stripe, may require a lot of custom result parsing and conversion code. It may make sense to build some kind of a DSL to accomplish that, increasing implementation complexity, or let it flow through the client to the rest of the app, increasing coupling. It can be a tough call.
Mocking the API can result in a situation where the test suite is green but production is not.

Closing Thoughts

Calling third-party APIs is always going to be more difficult than ordinary method calls. However, hiding the API behind a well-defined interface that's entirely within our control makes it much easier to manage the complexity resulting from the integration. Its bulk will live in the client class and won't spill over to the rest of the code base making testing and stubbing easy.

If you enjoyed reading the article then I recommend you take a look at other articles on my website.

The Architecture No One Needs

Greg Navis — Fri, 11 Jan 2019 17:40:36 +0000

Single-page apps are all the rage nowadays. Many praise their vague technical benefits while ignoring tremendous development costs.

In this article, we'll discuss why a single-page app is almost always worse than a multi-page app and briefly cover alternatives that can yield similar benefits without the costs.

The Business of Software

Every business has two sides: revenues and costs. Whether an SPA is a good investment compared to alternatives depends on how it affects the bottom line.

Revenue depends on value delivered to users which in turn depends primarily on the feature set. Architectural choices don't provide value to users per se. The promise of SPAs is better user experience which may translate into higher revenue. This increase must be compared with the corresponding increase in costs to assess whether the investment is worthwhile.

The article attempts to prove the costs of an SPA are tremendous compared to an MPA mainly because of greater incidental complexity. However, many companies blindly assume user experience is improved enough to justify the extra expense. Others base their choice on some vague sense of engineering purity without considering business factors.

There are two key takeaways from the article:

Do not consider the SPA architecture unless there's evidence user experience is the number one problem of your app and even in that case consider alternatives. For example, if you need to make the app snappier then you may be able to reap the bulk of the benefit by tuning your database, caching, using a CDN, etc.
An MPA is a competitive advantage.

Let's take a look at the cost side.

The Price of Single-Page Apps

Architectural choices affect different aspects of development in different ways. That's why I compiled a list of areas negatively affected by the SPA architecture. You can use it to assess the impact an SPA has or would have on your project.

Let's emphasize a clear pattern: an SPA negatively affects most items on the list and requires extra work to regain capabilities present in MPAs by default.

Here's the list starting with the most expensive items:

Statefulness: I think this is a very underappreciated aspect of SPAs. Stateful software is always more difficult to work with than stateless. The frontend state is added on top of the already-existing backed state. This requires more development time, increases the risk of bugs, and makes troubleshooting more difficult.
Testing: The stateful nature of the frontend greatly increases the number of test cases we need to write and maintain. Additionally, the test setup is more complicated because we need to make the backend and frontend talk to each other.
Performance: It's frequently claimed SPAs offer better performance but it's more complicated than commonly thought. An API-only backend renders and sends less data than an MPA but the network latency is still there and the app won't be faster than that. We could work around the issue by implementing optimistic updates but this greatly increases the number of failure modes and makes the app more complex.
Slow First-Time Load: This is a well-known problem that isn't fully understood. The usual claim is that after the browser caches the asset bundle everything will be snappy. The implicit assumption is we've stopped development and don't update the bundle. If we do then users may experience quite a lot of first-time loads in a single day.
Authentication: This is optional for an SPA but it seems JWTs are a frequent choice for authentication. The claimed benefit is statelessness. It's all true but has a serious downside: we can't invalidate sessions unless we identify them on the backend which makes the system stateful. I think we always should be able to invalidate sessions. Therefore, because we need server-side state, we can simply use bearer tokens. They're simpler to understand, implement and troubleshoot.
Session Information: Again, this is optional but SPAs often use local storage instead of cookies. Its tremendous downside is lack of a mechanism similar to HTTP-only cookies. Given web apps often include scripts from third-party domains and CDNs a successful attack against them can leak session IDs and other secrets.
State Updates: Let's illustrate this with an example: we're building an e-commerce site that has a list of categories. We need to update the list from time to time. In an MPA, the list is updated on every page load. That's not the case in an SPA though. We need to think about an algorithm and implement it. It's not rocket science but it's busywork that users don't care about.
Error Handling: An MPA renders a 500 page upon error and that's it. However, an SPA needs to detect errors in the client code and then update the user interface accordingly. Again, busywork required to regain what MPAs offer out of the box.
Server-side Rendering: We may need server-side rendering so that users are able to discover the app. This is yet another area where you need to do work to match the capabilities of an MPA.
Protocols and Serialization: In an MPA, we can simply pass models to views and render attributes we need. This isn't the case in an SPA. We need to define data formats and implement serialization. Naturally, there are tools that can help but it's extra work and dependencies whose only effect is regaining the convenience of an MPA.
Tooling: Our build system may become more complicated because of the additional tooling and dependencies required to build an SPA.
Shared Metadata: We may need to share data between the frontend and the backend. For example, if the SPA consumes a REST API then we would like routing information to be derived from the same source. Again, this is unnecessary in an MPA.

If you look at the SPA architecture from a business perspective then your costs will go up but you won't see more money coming in because users don't care about technical choices. The result is a negative return on investment.

What to Do Instead

My advice is simple: if it hurts then stop doing it. Even better: don't start doing it in the first place.

A multi-page app is much simpler to implement and has many advantages that can only be replicated in an SPA at a huge cost. Naturally, more complicated components are sometimes unavoidable but there are more sensible approaches.

First, start using Turbolinks. It'll make the app feel snappier without injecting a ton of incidental complexity. It's often associated with Ruby on Rails but can be easily used independently with other technologies.

Second, use Stimulus.js for simpler components. It's a relatively new development but I had a chance to implement a dozen Stimulus controllers and the experience was great.

Third, if you're implementing a very complicated component then you can use React just for that component. For instance, if you're building a chat box then there's really no need to implement your login page in React. The same applies to Vue.js and the rest of the pack.

Summary

Single-page apps are much more expensive to build than multi-page apps. In most cases, there is no business reason to choose this architecture. The problems it's trying to solve can be address in simpler ways without excessive costs and complexity. There are cases where an SPA makes sense but this is a topic for another article.

DEV Community: Greg Navis

Elixir-style Pipelines in 9 Lines of Ruby

Background: << and >>

Step 1: Defining Parameterized Operations

Step 2: Piping Arguments into Callables

Step 3: Introducing Refinements

Summary

Next Steps

API Integrations: Client Classes and Error Handling

Problem Statement

Method 1: Exceptions

Method 2: Tuples and Pattern Matching

Method 3: Tuples, Pattern Matching, and Linting

Method 4: Result Monads

Conclusion

API Integrations: Building Client Classes

WhatWeather API Overview

Step 1: Build Client Class

Step 2: Integrate Client into App

Step 3: Testing

Step 4: Development

Further Steps

Closing Thoughts

The Architecture No One Needs

The Business of Software

The Price of Single-Page Apps

What to Do Instead

Summary

Background: `<<` and `>>`