Change scenario

[waghanza]

Hello all,

In order to make this project more reliable, we need to implement more tests.

The idea is to create a v2 of this project, so we can seamlessly switch to this version when implementations. So v1 and v2 will exists in parallel.

For v2, we will use a SQLite database (in-memory) to make sure we use a lot of data so as we can serialize/ deserialize (JSON) data, but without having latency and db performance issues.

Purpose of this is to have all implementations setup for mid 2025.

Here is a list of endpoints listed for this purpose :

PS : The purpose of this project is to have some raw indicators about frameworks letting any one to choose between stack in context of product creation, or tech migration.

PSS : I'll create a comment per endpoint, please argue for each one in threads, and fill free to suggest in comments

[waghanza]

First endpoint is /, in order to check response time

[waghanza]

Second endpoint is /user/:id, to check for routing parameters

[waghanza]

Third endpoint will be /hello?user=John to test also query parad in url

[waghanza]

Fourth endpoint will be /all, to have a big serialization json content, from database

[waghanza]

Fifth endpoint will be /filter. The idea is to deserialize filter (given as JSON), pick some data in database and serialize it as json

[pi0]

Suggestions from #6726:

• Nested calls (/x calls /y when generating response)
• Response streaming

[waghanza]

Thanks for your insights.

Response streaming could be hard to maintain, especially with the (huge) number of frameworks we have here. Will file upload endpoint be ok ? I mean will test the file part of a framework features set ?

Not sure to understand nested calls, I mean in a real application @pi0

[trikko]

I think you should set a endpoint /dump that must reply with a dump of the request in a simple format (to avoid relying on 3rd party libs: are we testing them?)

For example:
path: /dump
query params: hello=world
cookie: ....
post body: ....

Etc.

Please randomize params to avoid hard coding of requests. For the same reason I would add some cross check. Eg: /sum?a=35 must return 35+the number on post body. Then try some extra fuzzy test (what if a=pizza or a=-5 or a is missing or...)

Every other URL should be a 404 (again: random testing to avoid a strict rule)

[waghanza]

This is more about test, right ?

Then it's a good idea to make sure no explictly define endpoint returns any 4xx.

However, we are more talking about how we can be consistent, I mean to compare frameworks with something more realistic that a simple hello word

Having requirements for a framework to be included in this list is a good idea. Feel free to open a discussion about that. Keep in mind that some used frameworks (I mean in production), fastify for example could be inconsistent with web standard => #8116 (comment)