قالب وردپرس درنا توس
Home / IOS Development / Removing dependencies

Removing dependencies



Over the past few weeks we have cleaned up the addictions of our Swift Talk backend. Now that we are done, we finally feel that we are at the top of the code base again. No more dark, dusty corners!

In this post, we will outline how the codebase has evolved over time, and the changes we have made to clean it up.

We started developing the Swift Talk backend almost three and a half years ago. To begin with, we hired a contractor to build the site using Ruby on Rails. After we launched, we continued making small changes ourselves and hiring other entrepreneurs for bigger things.

When we decided to rewrite the backend in Swift last fall, our goal was to get the new backend up and go as quickly as possible. For the most part, we repeated what Rails backend did before. To focus on building the most interesting parts of the site, we included third-party libraries to handle PostgreSQL, XML and crypto functions. We also kept all the CSS and Javascript infrastructure around, and served the same .css and .js files as before, only from our Swift server.

A few things bothered us about the state of this codebase:

  1. Some of the Swift dependencies felt unnecessary, given the small code it would take us to directly interface with the underlying libraries.

  2. We did not understand the Javascript build stack (mass node modules, browserify and babel) and the depreciation warnings in the JS build process began to accumulate.

  3. We ended up sending huge CSS files (2 MB uncompressed) and Javascript (7.3 MB uncompressed) files, although they did very little to improve the functionality of the site. For example, the subscription form was built using React, which adds a huge amount of code to a small sub-section of the site.

When it comes to Swift dependencies, we ended up writing our own lightweight cover around libpq, similar to the wrapper we demonstrated on Swift Talk. Our wrapper is about 300 lines of code, almost half of which are simple mechanical conversions between Swift types and their representations in PostgreSQL. We are happy to maintain this little piece of code against a mature library like libpq itself. The advantage is that we can easily fix warnings that occur with new Swift versions, fix bugs when we meet them, or make changes to the API to better suit our needs.

We also removed our dependence on BlueCryptor, a Swift wrap around CommonCrypto on macOS and libcrypto on Linux. Since we only used it to create md5 hashes for our assets, we wrote our own md5 wrapper around the native crypto libraries, with about 30 code lines.

Before, we used Perfect XML to parse XML on Linux, as the Foundation's XML parsing gave us strange crashes. In recent releases, these issues have been resolved, and we managed to release addiction and use the Foundation instead.

On the client side, we slowly dropped more and more Javascript dependencies until we could remove the entire Javascript built stack. There is no one application.js anymore, instead we have a few inline scripts for pages that need it. For example, we ended up writing about the payment form without React, which took about 1

50 lines of vanilla Javascript code. We maintained the spirit of the response-based code: our custom Javascript also keeps track of a state object and reproduces the potentially affected DOM nodes as the state changes.

We took a long look at CSS and also managed to remove almost all dependencies.

When we create stock after refactoring, we cut the CSS and Javascript sizes to a fraction of what they were before: the uncompressed CSS is 199 KB, and there are only a few bits of inline Javascript. This makes for a faster site and – at least in our case – much happier developers 😀.

To check out the backend, the source code is on GitHub.


Source link