Sarah Mattar is a Commit Engineer specializing in full-stack development. Her go-to languages are JavaScript and Ruby. When she isn’t on a computer, she is usually taking photos or at the beach.
The goal of the HOP—hackathon onboarding project—is to select a technology, framework or language that you have not worked with before, learn about it and create a deliverable application. A final project is a nice outcome, but it is more important to emphasize learning something new and documenting your process. What did you learn? What challenges did you face?
Goals
I had two goals for my HOP:
- Learn Swift
- Build a Slack App
Learning Swift
Swift is a programming language for the Apple ecosystem (iOS, iPadOS, macOS). It is an object-oriented language that is good for a multi-platform application. I began my learning process for Swift with a Udemy course taught by an instructor whose courses I had taken before to learn Python and Django. I thought I had it in the bag, but I was dismayed to find out that this course was not the same caliber of learning style and material. I felt let down and lost: I had gained some knowledge about Swift as a language, but the frontend content was outdated and incomplete. Fortunately, a Slack App does not need a frontend facing client—the Slack workspace is the client.
My first question: has anyone ever built an app for Slack using Swift? The answer? Yes. There is an open-source project called SlackKit, which is an ORM used to connect to the Slack API ecosystem, but this appears to be the only connection between Slack and Swift on the market. Some elements of SlackKit pointed to outdated APIs, others were current. I began exploring the Slack API documentation. There were plenty of API endpoints, but each time I went to look at one for the use case I had in mind, I found it was deprecated.
I was starting to get increasingly nervous that there would not be enough information or resources to create what I wanted to create in Swift, and the mounting anxiety began to leave me with more questions than answers: How would one query the Slack API endpoints using Swift if not via SlackKit? Had I picked the wrong tool for the job? If SlackKit is the only resource available, what if it doesn’t work? What if the API I want to use is not available, or I’m thinking of a use case that doesn’t have a public-facing API for developer use? Should I change projects?
I decided to reframe these questions into another question: could I query a REST API endpoint—from Slack or anywhere else—directly via Swift? Yes, theoretically that’s possible. I need to build a web server to handle the HTTP requests. My next step was to determine whether or not a web server could be built using Swift.
Swift + Vapor
Vapor is a multi-purpose server and web framework client for Swift. It has dozens of package-based dependencies, like Node: drivers for SQL and NoSQL databases, a frontend templating library (Leaf), and an ORM called Fluent which coordinates all calls to the database with the endpoints of your project. Vapor’s docs are very straightforward—they walk you through the initialization of a Swift executable package and scaffold it with Vapor’s pre-packaged dependencies. Great!
Much like Swift, Vapor has its own learning curve. It is set up somewhat similar to an MVC (Model-View-Controller) pattern web application, with everything except the View (I opted not to install Leaf, as I did not need a front-facing client). There was plenty to learn about how to integrate a database, and create Models and Controllers and migrations (version control for SQL databases). Controllers were more like API endpoint groupings but focussed more on data fetching than providing interactivity to a View layer, like in Rails or Django.
SwiftUI
In the interest of completeness, and because I was still feeling somewhat slighted by my previous Swift course experience, I began to do a Vapor tutorial series that utilized SwiftUI for a front-facing client. The series built a backend API using Swift and Vapor, and an iOS client using SwiftUI.
SwiftUI favors the MVVM pattern when setting up a new Single Page App. The MVVM pattern, which stands for Model, View, ViewModel, organizes frontend logic for an iOS application by calling various ViewModels corresponding to different Views.
- The Model is the same as the Model in Model-View-Controller (MVC) pattern: it is the typecast blueprint for your data type.
- The View can be thought of as a ViewController. It fetches the data from the database or API service.
- The ViewModel is what is done with the data. This is where the action and interactivity happens.
The remaining syntax for SwiftUI wasn’t intuitively straightforward to me: I felt like I was being led through a tutorial where I didn’t fully know or understand what I was doing, but I was jumping through the prescribed hoops anyway. I understood that there were basic building blocks like Text, Button, Color, etc. that could have their attributes modified, but that was it. That was until I watched Matt Moeykens’s video 5 Basic SwiftUI Concepts – those Swift building blocks of elements that I was looking at were actually… Views! They were child views of the main View that was defined as part of our Model-View-ViewModel pattern. Now we’ve come full circle.
The remaining syntax for SwiftUI wasn’t intuitively straightforward to me: I felt like I was being led through a tutorial where I didn’t fully know or understand what I was doing, but I was jumping through the prescribed hoops anyway. I understood that there were basic building blocks like Text, Button, Color, etc. that could have their attributes modified, but that was it. That was until I watched Matt Moeykens’s video 5 Basic SwiftUI Concepts – those Swift building blocks of elements that I was looking at were actually… Views! They were child views of the main View that was defined as part of our Model-View-ViewModel pattern. Now we’ve come full circle.
Building a Slack App
The Slack API
As I mentioned above, concurrently I had begun to investigate the Slack API documentation. It was a bit daunting at first, as each API I thought would be a good fit turned out to be deprecated. Worse, most tutorials for creating a Slackbot were also out of date, as Slack had changed its process of custom app creation to have a larger reach than just Slackbots. Finally, I found a tutorial on freeCodeCamp.org that was up to date (2019), explaining how to leverage and query the Slack API endpoints to create a Slackbot, starting with creating a Slack App on the platform to house the bot, and then implementing bot functionality based on data returned from various API endpoints.
Sending a GET request to a Slack API endpoint is not enough to retrieve data, there are also various permission scopes (i.e., reactions:read and reactions:write) that need to be activated in your Slack app for the data to be returned.
API endpoint + permission:scope = data
Once permission scopes are enabled inside your Slack App, you can test out any API endpoint you would like in Postman. The response will be returned as JSON.
Conclusion
My process became much more learning-heavy than I anticipated. I basically took on the scope of something akin to learning Javascript, Node and React without any prior knowledge of the language or the tech stack. There is no way to become an expert within a two-week window, but you will come away with much more knowledge than when you started!
I also began my HOP on the blind faith that I could start off with two completely unfamiliar topics, and they would converge into a final application. That convergence, while possible, did not happen within the time frame. Overall, my recommendation is to take something—singular!—that you want to learn, and learn it. For the sake of your sanity, you may want to integrate this new technology with something you already have familiarity with. This will keep your stress levels down and let you focus on building as well as learning.
###