What kind of apps we should test?

[kjugi]

It just came up from the agenda. @jonchurch prepared example app which we can use for performance tests:

PR here: #24

Here comes the question.

How many apps we want to run our tests against?
What other apps we can prepare as well?

Q more related to the PR:
Do we want to strip out the auth from the PR and make a "simple" app and prepare another one for "auth" case?

• Simple CRUD application (the todo app)
• Application with auth (the todo app)
• API Gateway application which parse sent data and validate different type of requests. For some it's doing some computation and for other requests it just forwards to mocked service (like a proxy?)
• Stress testing
  • Application with many middleware
  • Mounting many sub-routers
  • many routes
  • serialize small & large payloads in response
  • error handling paths
  • async & sync middleware
• Real world applications (low priority, more like WIBY)
  • Look for other benchmarks from those projects
  • https://github.com/pelias/pelias
  • https://github.com/bluesky-social/atproto/blob/main/packages/pds

[wesleytodd]

What other apps we can prepare as well?

One use case that was on my mind which might be an interesting one is the Bluesky PDS: https://github.com/bluesky-social/atproto/blob/main/packages/pds/package.json#L55

Do we want to strip out the auth from the PR and make a "simple" app and prepare another one for "auth" case?

I feel like we can solve for the issue brought up there with that, but also I feel like it might be good to do this and keep both. Or maybe make it so we can keep one but use it for both use cases? We don't want to have too much duplication but also too narrow of tests is part of the problem in the past.

[kjugi]

I don't quite understand this example of PDS. Can you explain a bit more what's behind this idea?

I can see the initial PR is merged: #24 That's good. We have a first simple app that covers 2 topics.

• Simple CRUD application ✅
• Application with auth ✅

Another proposals:

• API Gateway application which parse sent data and validate different type of requests. For some it's doing some computation and for other requests it just forwards to mocked service (like a proxy?)
• Router based application which is pretty obvious to explain
• Application with middleware or many different middleware's

[wesleytodd]

I don't quite understand this example of PDS. Can you explain a bit more what's behind this idea?

It is an open source and robust example. The problem in general with "synthetic" examples is they rarely show the real world problems apps encounter. And it is not common to have "real world" code that is also OSS that we can test on. We have plenty of internal company apps we could test on, but since the source is not available it makes it really hard to use as any sort of real signal to our use cases.

Another proposals:

Love these ideas.

[kjugi]

OK, Thanks for your explanation! I have checked it again right after. That makes more sense now.
Looks like some kind of role model example of how things can be done. That would be awesome to possibly achieve similar result in the future.

For now, we just have a starter applications. Who knows what the future can bring! It's definitely something we can improve in the future.
Side note to that part. I remember there was some thread on express js slack channel about building docs webpage with express itself. I know that a moment after everything settled down so I'm not tied to it in any way.We probably won't have enough power to build it up and maintain.

I just thought about it for a second. Maybe that could be a real world and robust example app to benchmark on?

Of course, I need to make a statement that it's far from this for now. Still happy with those demo apps we have now and the ones proposed on the list

[jonchurch]

express-microbench-core/
Purpose: Overall Express health baseline
Routes: Representative sample from each subsystem
- /hello (baseline routing)
- /json-small (JSON serialization)
- /param/:id (parameter parsing)
- /headers-5 (header processing)
- /mw-2 (2 middleware layers)