Example project implementing an API that allows to create/view/manage your recipes!
- REST application to manage (CRUD) recipe objects
- Persistence of recipe information
- Production ready (testing, API documentation, standard packaging/Docker image, deployment descriptors, security-layer)
Decisions & assumptions:
-
Stateless service implementation, containerized and horizontally scalable across AZs & regions
-
Persistent data-store capable of handling high-volume read operations
- Opted for a NoSQL database (DynamoDB). The main reason for this choice is that the recipe entity data sits in a single table, the ingredients list is also made up of objets that are "unique-enough" per recipe due to name-amount combination. With this in mind a schema-less data-store meets the requirements and is flexible for future extensions to the data-model.
-
Data model
{ "id": "1000001", "created": "12-05-2022 10:47", "type": "VEGETARIAN", // | VEGAN | CARNIVORE "servings": 4, "duration": "90", "ingredients": [ {"name": "flour", "amount": 200, "unit": "gram"}, {"name": "salt", "amount": 7, "unit": "gram"}, {"name": "dry yeast", "amount": 10, "unit": "gram"}, {"name": "tomatto sauce", "amount": 250, "unit": "gram"}, {"name": "mozzarella", "amount": 200, "unit": "gram"}, {"name": "olive oil", "amount": 20, "unit": "gram"}, ], "instructions": "prepare dough, preheat oven, bake, serve" }Although Ingredient is a distinct object with defined attributes, the list of ingredients for a recipe is not persisted in another table.
The reasons being:- They belong together from perspective of querying (updating, removing etc) a recipe.
- Queries where individual and/or all ingredients are important to know (for all or related recipes) are mainly for analytics (ie how many ingredients are used in all recipes, how many recipes use ingredient X etc). And even for functionality depending on aggregating ingredients, it's possible to query the recipe-table and expand the ingredients column before aggregation occurs.
- Data normalized this way would not benefit from storage savings, the amounts & units are close to unique per recipe.
-
Container image for the application is created during application build (separate profile that can be enabled). Since the service is stateless it can be easily scaled as long as the data-store is scaled with it to support all connections from all service instances.
-
Security layer currently implemented at the service side using Spring-Security.
- However it is a good practice to push some of these concerns out of the service implementation and into an upstream layer such as API Gateway or a side-car proxy, components that are more capable of handling authentication, authorization and throttling/quota for incoming requests, thus limiting the amount of traffic that gets to be handled by the service.
- Local / development deployment using docker-compose allows for quickly running the application and dependencies.
# start containers docker-compose up Creating network "recipes_default" with the default driver Creating dynamodb ... done Creating recipes_recipe_service_1 ... done Attaching to dynamodb, recipes_recipe_service_1 dynamodb | Initializing DynamoDB Local with the following configuration: dynamodb | Port: 8000 ... recipe_service_1 | 2022-05-15 15:37:46.242 INFO 1 --- [ main] org.example.recipes.RecipesApplication : Starting RecipesApplication v0.1.0-SNAPSHOT using Java 17.0.2 on 3ce39535b0a7 with PID 1 (/home/appuser/recipes-0.1.0-SNAPSHOT-sb.jar started by appuser in /home/appuser) recipe_service_1 | 2022-05-15 15:37:48.883 INFO 1 --- [ main] org.example.recipes.RecipesApplication : Started RecipesApplication in 2.974 seconds (JVM running for 3.392) # (SKIP, sample DB commited to repo!) # initialize DB (only required once, data is persisted on disk between runs at: ./docker/dynamodb/*.db) mvn clean test -Dtest=org.example.recipes.test.integration.DatabaseInit
- Endpoints protection, authentication (user or client based) & authorization
- TODO: Request throttling to protect against malicious or compromised clients
- TODO: Client authentication (API key?, cryptographically signed tokens?)
- Scaling
- Security
- Authorization - which API is the client allowed to call & with what parameters, ie creating-recipes should require editor-access
- Application scanning (dependencies / BOM)
- Scanning code for bugs
- Scanning dependencies for known vulnerabilities in used versions
- Scanning container-images for known OS vulnerabilities, elevated application rights etc
- Scanning container-platform/application at runtime for:
- Permissions assigned to application in its sandbox, ie can it access more than required services such as the DB.
- Scanning HTTP traffic coming to/out of the application ie via ingress/egress gateway, making sure it is not going to known addresses.
- Backups
- Monitoring & logs
- Analytics
- Java 11+
- Maven 3.8+
- Docker engine
mvn clean install -Pdocker
Profile docker during build is optional.
docker-compose up
Access: /api-docs or /swagger-ui endpoints for documentation.
mvn clean test -Dtest=org.example.recipes.test.integration.RecipeControllerTest
...
recipe_service_1 | 2022-05-15 15:21:13.406 INFO 1 --- [ main] org.example.recipes.RecipesApplication : Started RecipesApplication in 3.089 seconds (JVM running for 3.467)
recipe_service_1 | 2022-05-15 15:24:07.021 INFO 1 --- [nio-8080-exec-2] o.e.recipes.controller.RecipeController : Created recipe with id: a12cb443-6b42-44f4-b975-c24511421ac2
recipe_service_1 | 2022-05-15 15:24:07.190 INFO 1 --- [nio-8080-exec-4] o.e.recipes.controller.RecipeController : Updated recipe with id: a12cb443-6b42-44f4-b975-c24511421ac2
recipe_service_1 | 2022-05-15 15:24:07.342 INFO 1 --- [nio-8080-exec-5] o.e.recipes.controller.RecipeController : Removed recipe with id: a12cb443-6b42-44f4-b975-c24511421ac2