Before writing code to solve a problem, consider if it is easier to discover, learn, and use an existing tool.Instead of making use of a task scheduler like Celery to upload the images, you can instead use Pre-signed URLs to allow the client to do the upload). suppose I want to upload images to AWS S3. If you need some work to be done asynchronously on the backend and don’t have the infrastructure yet to support it, consider offloading the work to the client.For ad hoc deployments or things that don’t need to be re-deployed often, consider writing a simple bash script which installs your dependencies and runs your service instead of using CloudFormation/Terraform.Here are some more examples of how you can “Keep things Simple”: The main point is you should always start with a simple solution that covers your use cases and enhance it when needed. The example I’ve talked about thus far is quite extreme and highlights my juniority more than anything else. Also, making use of mutex locks to manage concurrency is much easier as all the game data is in the same place. The only business logic needed here is allowing players to interact with an Estimation game. They send their inputs and receive game updates as needed. Players connect to the web server via WebSockets. Buzzwords and use of fancy technology aren’t reasons to design systems a certain way.This approach lends itself easily to the pitfalls of concurrency (race conditions, deadlocks, etc…).It’s too complicated! Something that could’ve been a simple function call now turns into an event which needs schema validation and business logic for using message brokers.Luckily, as I started implementation and matured as a developer, I saw the flaws with this design: I wanted to be able to use buzzwords like “Message Broker”, “Asynchronous”, “Event Driven”, etc… when explaining my design to others.This uses the producer/consumer pattern, a pattern I’m very familiar with.I wanted something scalable adding more workers means I’ll be able to handle more load.An arbitrary number of workers would consume events from the queue and execute business logic. Players would send requests to the server which would be translated into events and put into a queue for processing. Without getting into the details, here is how my design was to work:
0 Comments
Leave a Reply. |