قالب وردپرس درنا توس
Home / IOS Development / Kitura and the BFF Pattern

Kitura and the BFF Pattern



Did you know: Etymologically, the word Kitura loosely stems from the Hebrew word Keturah which literally translates into "incense"?

What does that have to do with Kitura? Absolutely nothing! Why is Kitura's logo a bird and does it have anything to do with Swift's iconic imagery? Maybe! How do you pronounce Kitura – is it "i" long or short? No one knows the empirical answer to this. The members of the Kitura team have been known to pronounce the word Kitura differently at different times of the day on the same day. They were actually repeatedly asked why they did this, and typically, just as Apple announced availability for the Linux build of Swift, IBM immediately pounced. Out of the box, there were major hurdles to overcome: The team worked to port most of Swift's core APIs, like Dispatch, to compile and pass tests on Linux. In addition to this, the team visualized a module for running a RESTful server using Swift. This module is now known as Kitura

This article aims to give you a quick overview of server-side Swift using Kitura, how the Backend-for-Frontend (BFF) pattern works, and some of the high-level problems that Kitura solves.

Why Swift on the Server?

The core argument in favor of writing Swift for your server is at share code and knowledge between the front-end and the back-end of your app if you're a team of one, this streamlining is arguably just as crucial and empowering. This includes, but is not limited to, your model object code.

Given that the team who wrote Kitura came from the Node.js ecosystem, there was a conscious desire to model Kitura after Express.js , which is arguably the most popular node.js framework for running a restful server. But the router is one of the most important ones.

Think of a router as a module that routes requests to the appropriate place. Here is an example of a route in Express.js:

 app.get ("/ testing", (req, res) => {
    res.send ("Hello world!")
})

In English, this means that, whenever someone accesses / testing on your server, you send a plain-text response that says “Hello world!” Notice that you have two parameters called req and res passed into your closure for action the response. Compare this to how a similar route would look in Kitura 1

.x:

 router.get ("/ testing") {request, response, next in
    response.send ("Hello world")
    next ()
}

The two code snippets are nearly identical, except for closure syntax in Javascript versus Swift, and the need to call next () (something they managed to eliminate in Kitura 2.x). Not only does this provide a comfortable landing for Node.js developers interested in trying Swift, but this also means Kitura has been architected with a consistent, tried-and-true methodology that caters to performance, ease of use and code longevity. [19659005] The BFF Pattern and Why It Matters

The BFF (Backend for Frontend) is a design pattern that will quickly become your best friend (forever?):]

It's a common task for a mobile developer to interface with an app with a REST API. It's also somewhat common to run into issues during this integration. This could be for any number of reasons:

  • Overlooked responses
  • Inconsistent error states
  • Versioning issues
  • Poor documentation

If you are your head, you might also say something along the lines of, "I wish I could just have the server myself!"

What if there was a way to handle these issues in the same programming language you write your iOS apps in, and you can deploy this solution to the cloud separately from your mobile app? Well, that's exactly what you will do with Kitura. The BFF pattern enables you to deploy a server written in Swift that integrates with the existing server API.

The Swift server acts as an intermediary between your mobile app and that existing server API, and it allows the mobile developer to spend much less time integrating the app with the API. This also means that the only code your mobile app written in Swift will have to integrate with is also written in Swift, which insulates your mobile developers from having to work with something that may have a learning curve.

Picture a common scenario amongst developer teams for modern-day apps. With all due respect to DevOps and Data Science engineers, this scenario only involves two types of developers: the front-end developer and the back-end developer. For the affairs of explanation, assume the front end has two media: an iOS app and a website . You are the iOS developer. Assume you do not know how to set up a back end in any language.

Your app must show a series of restaurants with the following properties:

  • Name
  • Latitude and longitude
  • Object
  • Rating

The back-end developer has already made this method on the server, and you can access it by using GET method. You would need to query the server based on longitude and latitude. However, the current response is a little bit verbose, and looks like this:

 {
    "reasons": {
        "count": 0,
        "items": [
            {
                "summary": "This spot is popular",
                "type": "general",
                "reasonName": "globalInteractionReason"
            }
        ]
    },
    "venue": {
        "id": "40b13b00f964a520cff31ee3",
        "name": "North By Northwest (NXNW)",
        "location": {
            "address": "10010 N Capital of Texas Hwy",
            "crossStreet": "Stonelake",
            "lat": 30.391062198099544,
            "lng": -97.73859813809395,
            "labeledLatings": [
                {
                    "label": "display",
                    "lat": 30.391062198099544,
                    "lng": -97.73859813809395
                }
            ],
            "distance": 144,
            "postalCode": "78759",
            "cc": "US",
            "city": "Austin",
            "state": "TX",
            "country": "United States",
            "formattedAddress": [
                "10010 N Capital of Texas Hwy (Stonelake)",
                "Austin, TX 78759",
                "United States"
            ]
        }
    }
}

You have parsed JSON before, so the task might not be too difficult to complete, but you are not the only iOS developer who will ever work on this. You might be a pro, but it would be nice to make the job easier for everyone, right? And what if this API goes down all of a sudden? You could cache data on the device if you wanted, but users might notice a different user experience if the app is just loading data from the disk, and not able to pull data from a brand new query.

 Monolith

This is where the Backend for Frontend design pattern comes in. To this point, I have described a Monolith pattern, where one API is responsible for handling requests from every single possible client that may consume it. Aside from these issues, how can you be sure that the API is up to the task of fielding requests from X number of devices concurrently? We want to make their job easier, right?

The BFF pattern inserts an iOS API between the mobile iOS app and the main server API:

 The BFF pattern

A few reasons why this pattern works in this particular use case:

  1. You can be sure that the only devices that make requests from this API will be iOS devices. This means you can be less worried about balancing request load.
  2. You have more control over what data goes into a response to an iOS device. Before this, you may have left the back-end developer to eventually get around to you, and conditionally trimmed response data based on a [User-Agent] header. Now, you can download the back-end developer work uninterrupted, and solve your problem with parsing response data down to only what your BFF device needs.
  3. In our specific use case, you can save responses for queries one user might make into a database before sending a response. This means that if someone else requests restaurants at the exact exact location, and the stored data is enough to satisfy your refresh policy, you do not even have to send a query to the master server! You can just send the cached data and trust that it is fresh enough for your users.
  4. You can accomplish 1-3 in the language you already know how to write code in – Swift!

This is a microservice friendly approach that SoundCloud and ThoughtWorks pioneered in 2015. Imagine a workplace where you are free to "make your app work" without having to rely on another developer potentially blocking you. Thanks to the BFF design pattern, you don't have to imagine it anymore.

Where to Go from Here?

Now that you have a sense of using Swift on the server and of the BFF pattern, you're ready to get started working with Swift on the server. Kitura Tutorial: Getting Started with Server Side Swift to see Kitura in action.

You can learn much more about using the BFF pattern with Kitura in our book Server-Side Swift with Kitura . See below for a link to the book

And be sure to check out the official Kitura site for more information.

I hope you enjoyed this article on the BFF Pattern and Kitura. Please feel free to add comments or questions in the forum below!


Source link