eykrehbein / strest

⚡️ CI-ready tests for REST APIs configured in YAML
MIT License
1.74k stars 59 forks source link

Run requests asynchronously #134

Open strix opened 5 years ago

strix commented 5 years ago

Running all of the requests synchronously takes a lot of time. Running requests asynchronously would be much faster. I know there's a lot to consider here with what is already in place especially when considering dependent variables from other requests.

I was thinking of these changes to the yaml to accomplish this:

version: 2 # might require version 3 for this
async: true

requests:
  healthCheck:
    request:
      url: https://foobar.com/health-check
      method: GET
  longRunningRequest:
    request:
      url: https://foobar.com/lots-of-work
      method: GET
  login: # will return { authenticated: true }
    ...
  authNeeded:
    requires: # list of all dependent requests that need to run first (e.g. for variables to be available)
      - login
    request:
    ...
      headers:
      - name: Authorization
        value: Bearer <$ login.content.authenticated $>  # It's possible to use the status code, headers, and status text from previous calls.
  anotherAuthNeeded:
    requires: # list of all dependent requests that need to run first (e.g. for variables to be available)
      - login
    request:
    ...
      headers:
      - name: Authorization
        value: Bearer <$ login.content.authenticated $>  # It's possible to use the status code, headers, and status text from previous calls.

In this scenario:

  1. healthCheck, longRunningRequest and login all run/resolve asynchronously.
  2. Once login returns successfully, authNeeded and anotherAuthNeeded both run asynchronously. If there are more dependent requests, their names are added to the requires list and are only ran after the dependencies have returned successfully.

listr seems like it would come in handy to accomplish this.

eykrehbein commented 5 years ago

At first, I want to appreciate the suggestions @strix made. It comes really handy 👍

@certifiedloud, the answer is simple. When I started creating this tool, I haven't thought about some performance optimizations. I thought about how to link those requests together and how to use values from previous requests - synchronous requests were the first reasonable option that came to my mind. Sorry that it's such a shame, but you're welcome to contribute to this project.

strix commented 5 years ago

@eykrehbein I'll probably take a whack at it if you don't mind. I have some thoughts to make this possible but you know the code more than anyone and may have a better solution than whatever one I come up with.

eykrehbein commented 5 years ago

@strix Sure go ahead please! Well actually I barely remember what I've written there because school is kinda taff at the moment.. :D But I read a few lines and I guess you should take a look at this line https://github.com/eykrehbein/strest/blob/master/src/test.ts#L104. At this point the loop which starts the synchronous testing begins. So you'll need to create an if statement and deny this loop to be executed if the async: true option was set and instead execute your code. And you'll need to make a few changes to https://github.com/eykrehbein/strest/blob/master/src/configSchema.ts because of the schema syntax parser which will throw an error if you don't.

Maybe I'll create a complete rewrite of this project in the next weeks or so including the listr library as default output (for synchronous executions aswell) and simplified syntax. (because currently the syntax isn't my best friend to be honest)