Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jun Park #250

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Jun Park #250

wants to merge 2 commits into from

Conversation

junsp
Copy link

@junsp junsp commented Nov 11, 2024

This is for the take home assignment for staff engineer position in Crexi.

I thought it would be nice to kinda show end to end work including example endpoints (controllers) as actual API resource examples. So some works were done to present Swagger as UI to play with.

launchSettings.json is provided to run the solution, choose profile "RateLimiter" to run and play.

Swagger UI will appear at: http://localhost:5000/swagger/index.html

Since there were some mock data seeded as InMemoryDatabase injected in Program.cs to simulate data available, in the swagger Custom-Header below can be used to test:

{ "Id" : "296035ED-532E-46C9-8172-60806CC86B50", "Region": "US" }

In actual production, this can be replaced to actual database or Redis, etc.

There were Users data and Properties data resources to represent different API resources and mock data were seeded as InMemoryDatabase to play with.

However all the interesting stuff is in the Services.Common project considering this work would be cross cutting concern, to be reused and exploited in any endpoints and API projects. So maybe if this is actually delivered in production, maybe provided as infrastructure layer work, either as common library (nuget pkg) or maybe gateway implmentation before actually reaching each endpoint.

This work considers dynamic loading of configurations. It's done via json format, which in production could be retrieved in database or redis, etc.

However for simplisity, there is 'rateLimitConfig.json' seeded in this project, which will represent per region, per resource configurations of rules.

This configurations are loaded via IRuleConfigLoader with RuleCofigLoader, which is backgroundservice and currently set to refresh every 24 hours considering rule configurations wouldn't change frequently.

How the rules results aggregated are determined by IRateLimiter, with current example of DynamicRateLimiter, which applies condition of all rules required should pass to let the request reach the API resource.

IRateLimitFactory will instantantiate each required rule, which will contain cache getting updated per client states to calculate rule result for each client.

Each rule implements IRateLimitRule to be compliant to aggregated abstracted IsRequestAllowed call.

Middleware was used to check the rules before letting request reach each API endpoint resource.

This is for the take home assignment for staff engineer position in
Crexi.

I thought it would be nice to kinda show end to end work including
example endpoints (controllers) as actual API resource examples.
So some works were done to present Swagger as UI to play with.

launchSettings.json is provided to run the solution, choose profile "RateLimiter" to run and play.

Swagger UI will appear at: http://localhost:5000/swagger/index.html

Since there were some mock data seeded as InMemoryDatabase injected in
Program.cs to simulate data available, in the swagger Custom-Header below can be used to test:

{ "Id" : "296035ED-532E-46C9-8172-60806CC86B50", "Region": "US" }

In actual production, this can be replaced to actual database or Redis,
etc.

There were Users data and Properties data resources to represent
different API resources and mock data were seeded as InMemoryDatabase to
play with.

However all the interesting stuff is in the Services.Common project
considering this work would be cross cutting concern, to be reused and
exploited in any endpoints and API projects. So maybe if this is
actually delivered in production, maybe provided as infrastructure layer
work, either as common library (nuget pkg) or maybe gateway
implmentation before actually reaching each endpoint.

This work considers dynamic loading of configurations.  It's done via
json format, which in production could be retrieved in database or
redis, etc.

However for simplisity, there is 'rateLimitConfig.json' seeded in this
project, which will represent per region, per resource configurations of
rules.

This configurations are loaded via IRuleConfigLoader with
RuleCofigLoader, which is backgroundservice and currently set to refresh
every 24 hours considering rule configurations wouldn't change
frequently.

How the rules results aggregated are determined by IRateLimiter, with
current example of DynamicRateLimiter, which applies condition of all
rules required should pass to let the request reach the API resource.

IRateLimitFactory will instantantiate each required rule, which will
contain cache getting updated per client states to calculate rule result
for each client.

Each rule implements IRateLimitRule to be compliant to aggregated
abstracted IsRequestAllowed call.

Middleware was used to check the rules before letting request reach each
API endpoint resource.
remove obsolete files
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant