kanecheshire / peasy Goto Github PK

If the port is in use it would be better to let people know rather than fatalErroring so they can change the port.

Generally errors need to be handled better throughout but this is the first step.

Currently the parser expects the double line break that indicates the header section is complete is sent in one chunk of data, so if it happens to have been chunked so the line break is split over two chunks the parsing will fail.

It’s unlikely to happen but possible and would be one of those things that’s super hard to debug when tests randomly fail using Peasy.

Luckily it’s easy to add unit tests to cover this.

As I don't control all the used ports on the system that runs the ui tests, it would be great to just use the next unused port and ask the server about the port it used. This would make parallel UI testing with one server per UI test more reliable.

E.g. usage like this:

let server = Server()
server.start(port: 0) // indicate we want to use a port the system chooses for us. Method name could be different.
let serverAddress = "http://localhost:\(server.port)" // Server needs a new property e.g. `var port: Int?` that gets set when start is called.

let app = XCUIApplication()
app.launchArguments.append(contentsOf: ["-SERVER_ADDRESS", serverAddress]) // use serverURL to pass to app as the server url

Is that possible?

When you can drop iOS 11 support, I was thinking you might want to build on top of Network.framework (iOS 12+) or SwiftNIO to make it easier to get HTTPs support #13

Links

• https://github.com/apple/swift-nio
• https://developer.apple.com/documentation/network

Currently everything is bundled up as one lib which includes the code to handle sockets, and the nice API on top of that to handle intercepting requests and responding etc.

It would be beneficial for the socket stuff to be broken out into a separate reusable lib so that any API can be built on top of it. Peasy's API is nice but may not suit everyone, and also restricts the way that new APIs must be written (for example I've had to really think about the way websockets work and fit nicely with Peasy's existing API).

The socket lib (name pending lol) will essentially be a wrapper around the core Darwin APIs to listen for incoming socket requests, keep them open and handle reading from and writing to a socket.

Useful for testing timeouts or making the client-server interaction feel more real.

Drawing it out, the loop is only needed in two places:

• Server for incoming connection events
• Transport for requests and responses

Currently, we create one Loop in Server, and then pass that into Connections which don't use it directly but pass it to its Transport.

Wondering if it's even needed and whether we could just use a regular DispatchQueue async call on a queue.

It would be nice if you could load JSON from a file to respond with, like so:

extension Response {
    public init(status: Status, headers: [Header] = [], bodyFromJSONFile: String) {
        // load body data as JSON from given file
    }
}

The way it's currently set up (with not great error handling) is that if you stop and immediately restart the server with the same port and address it crashes.

Although Peasy does close ports when they're deinitialized, there's some odd behaviour with the InputLoop which stops it from closing immediately.

Probably easily rectified by explicitly closing things rather than waiting for deinits.

I got an issue "operation not permitted"

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>com.apple.security.app-sandbox</key>
	<true/>
	<key>com.apple.security.network.client</key>
	<true/>
	<key>com.apple.security.network.server</key>
	<true/>
</dict>
</plist>

and if I run:

server = Server()
server.start(port: 8880)

from main target it works, but from uiTests target it always fails.

As mentioned in #21, it's more beneficial if configs are matched in reverse order, so that you can set up a set of "defaults", and then add overrides that are removed after they're matched, so it falls back to the defaults after.

The reason I haven't approved that PR is because I want to spend some time and make sure I get the API right.