The Geeks Blog

Vapor 3 has been one of the most exciting, world-changing, rug-from-out-underneath-you, interesting and at times head-banging-on-the-wall experiences since I started with Vapor! The transition to Vapor 3 is a game changer, and nothing compared to migrating to Vapor 2. Honestly I think if you are coming to Vapor 3 completely fresh with no experience of Vapor 2, you are probably going to have a better time! However, don't despair, there is light at the end of the tunnel and once you get your head around async and Futures, you will be thankful. Going back to Vapor 2 having been focused on Vapor 3 for so long sometimes feels as painful as having to go from Swift back to Java or JavaScript!

Vapor 3 is effectively a complete redesign of the framework and actually closely follows the evolution of Swift itself. With Swift you had Swift 1 when it first came out, Swift 2 which improved a few things and added a few features as people used it more and then Swift 3 broke the world as everyone learnt how they wanted the language to work and how using it day-to-day really was and it set the foundations for the future of Swift. Going to Swift 4 was (almost) painless. Vapor 3 is exactly the same. Vapor 2 added some cool features such as configuration and proper routing but Vapor 3 has built the foundations for Vapor to grow and evolve into the leading server-side Swift framework it has become for years to come. It will be a painful, but necessary transition, much in the same way that Swift 2 to Swift 3 was. Whilst I don't agree with every design decision that was made, I fully support them and understand them.

This is the sixth tutorial of a series of tutorials on Vapor. For more, click here

Up until now, everything we have been doing has been focused on an API and all the requests we have been sending have been sent through a REST client. This is great for iOS apps (and other mobile clients) but at some point we are going to want to have a presence on the web and a way of using the application through a website. We can serve HTML files via Vapor relatively easily but we will want a way to display content from our application. The way to achieve this is to use a templating language where we can use a template to display different things of the same type - for instance, a template to display a reminder. Vapor has it's own templating language, Leaf and in this tutorial we will learn how to use it!

This is a write up of the talk I gave at October's Vapor London Meetup. The slides from that presentation can be found here.

With the modern web, the 'Internet of Things' and more and more essential business being moved online, the web is becoming a bigger and bigger target for attackers. Gone are the days when you didn't really have to worry about things such as security and HTTPS because it didn't really matter. You may also find that you are under legal obligations to protect your user's data correctly.

It could be expected that with all of this focus on security, especially in light of many of the recent massive hacks and data breaches, that security would be the focus of all developers; but that isn't the case. A lot of developers try to avoid it and if you are coming to Vapor from iOS it may be something that you have never really considered, especially since on iOS a lot of things are taken care for you.

This is the fifth tutorial of a series of tutorials on Vapor. For more, click here

In the last tutorial we rounded off the relationships by adding a new Category model and a sibling relationship between that and our Reminder model. In this tutorial we are going to finish talking about Fluent for now, talk about some of the conventions that are emerging and importantly talk about persistence.

Model Keys

Currently in our model code, we need to define the initialisers for Row and JSON. We also need to tell Fluent how to create the database tables for our models in our Preparation. Until Codable is supported in Fluent 3 we need to manually specify all of they keys for our models. One of the emerging patterns of Fluent is to use a struct to define our keys. This makes sense as generally having hardcoded strings lying around in our code is never really a good idea, especially when they are duplicated! If we create an inner struct in our Model to hold the responsibility for naming our keys, that becomes a lot safer. So in our Reminder model, create an inner struct inside our Model that looks something like:

This is the third tutorial of a series of tutorials on Vapor. For more, click here

In the last tutorial we looked at adding a parent-child relationship between our reminders and users. In this tutorial we are going to look at sibling relationships and allow reminders to be categorised. By the end of this tutorial you will set up a sibling relationships between a new Category model and our existing Reminder model.

Sibling Relationships

First, let's recap on what sibling relationships are and how they work in Vapor. A sibling relationship is a many-to-many relationship; in our app this means that a reminder can have many categories and a category can contain many reminders. This means that in our models, you can't really link IDs to each other since there will probably be many links.