SwiftEngine is aimed at being a highly resilient and scalable server-side platform, and as such the goal of the platform is to overcome some of the inherent vulnerabilities of other modern platforms currently in the market. A key example of what this means for production deployments is that each request and endpoint is contained within its own process; a crash for one request does not bring down the entire server. Similarly, memory leaks or other bugs are ephemeral and only live for the duration of the request, instead of transcending the lifetime of the server.
In addition to being a resilient and scalable, SwiftEngine is also highly performant due to the pre-compiled nature of all the endpoints because under the hood SwiftEngine uses Swift as its core language. All code that is executed on the server is a compiled (native object code) version of the source code. Thus, no processing power is spent on maintain a runtime environment.
All the developer has to do is save their .swift files within the designated site directory and SwiftEngine will handle the rest. Any compile time and runtime errors are handled by SwiftEngine, and are provided to the developer in a beautiful and easy to follow interface. With SwiftEngine, long gone are the days of manual compilation and dealing with shell log dumps. Simply save a file and request the URL, and SwiftEngine will automatically compile, cache, and serve the requested results.
In order to achieve these goals, there is a slight paradigm change compared to how a typical Swift project functions. The primary difference is the independently asynchronous processing of the various endpoints. Each one of the endpoints are compiled and maintained on their own; the introduction of a bug within one endpoint has no effect on the functionality of the rest of the site, but rather it's contained to that specific endpoint only.
One of the root concepts in SwiftEngine is its sophisticated routing logic. Out of the box, SwiftEngine has a smart routing logic that automatically attempts to match the http requests to a specific .swift file as its endpoint. However, for more advanced usage, a Router.swift file can be included within the root folder of the site for close control and customization of the request handling of the server.
As an example for the automatic routing when an extension is not specified, consider the following URL: http://somedomain.com/componenet1/component2/componenet3/componenet4
Since a Swift file can serve as the base executable in various positions within the URL path, the automatic URL router will use the following logic, and select the first available in the following order.
In order to maintain resiliency and endpoint independence, SwiftEngine takes a slightly different approach in how individual files are compiled. With a typical Swift based project, all the files are compiled together, and as a result the entire app either works or it does not. Conversely, within SwiftEngine, each one of the requested endpoints is compiled independently, so a bug introduced in one area of the code does not affect any other endpoint. In order to achieve this, the developer needs to specify (within each file) any other files within SwiftEngine that need to be used within that specific Swift file. The SEProcessor will iteratively process all the files with the require directive, so the developer only needs to specify what other Swift files are needed within the first Swift file.
As an example, if the example1.swift file depends on a class that is declared within example2.swift, the developer will need to specify example2.swift as a dependency via our custom require directive. To do so, one must only add the following line to example1.swift:
//se: require directory/example2.swift
This will inform SEProcessor that the example2.swift file should be used along with example1.swift file during the compilation process.
The following is a high-level logic for SwiftEngine preprocessor require directives: