Loading repository data…
joicejoseph3198 / repository
hobby project built entirely for my own satisfaction with java, springboot & react as front end. Stemmed from my brief interest in mechanical keyboards, its a store where you can auction and bid for exclusive keebs. Built multiple microservices, created a local kubernetes cluster using kind. Integrated it with front-end built using react.
Status: In progress
Overview of the project:
Built microservices-based application based on Java 17 and Spring Boot 3, and implemented various technologies used in building large-scale, real world microservices architecture. Overview of the project: Built microservices-based application based on Java 17 and Spring Boot 3, and implemented various technologies used in building large-scale, real world microservices architecture.
Key Features:
I’m aware that the set of supporting services that I’ve applied throughtout my project are rather overwhelmingly complex for such few microservices and somewhat over engineered and at some places not fully implemented. However the purpose from the beginning was, to be able to learn about services that can support a much larger microservices landscape.
Stage 1: Creating cooperating microservices
Created a small set of cooperating microservice with minimalistic functionality, to which I’ve added features as I’ve made progress with my project.
Product Service - manages and stores information about product. (Product focused towards a single typle of product — mechanical keyboards)
Review Service - manages reviews about the products
Product Composite Service - composite service aggregates information from the two core services and presents information about a product
Stage 2: Dockerizing services
Stage 3: Adding Persistence
Grunt developer’s guide to test containers for integration testing
Stage 4: event driven microservices
A bit about Spring Cloud Stream and how I configured it:
Spring Cloud Stream abstracts away the complexities associated with messaging middleware, enabling developers to concentrate on crafting business logic rather than dealing with middleware specific code.
The core concepts in Spring Cloud Stream are as follows: • Message: A data structure that’s used to describe data sent to and received from a messaging system. • Publisher: Sends messages to the messaging system, also known as a Supplier. • Subscriber: Receives messages from the messaging system, also known as a Consumer. • Destination: Used to communicate with the messaging system. Publishers use output destina- tions and subscribers use input destinations. Destinations are mapped by the specific binders to queues and topics in the underlying messaging system. • Binder: implementation responsible for integration with specific message broker is called binder. By default, Spring Cloud Stream provides binder implementations for Kafka and RabbitMQ. It is able to automatically detect and use a binder found on the classpath. Any middleware-specific settings can be overridden through external configuration properties in the form supported by Spring Boot, such as application arguments, environment variables, or just the application.yml file.
We can also specify the number of retries until a message is moved to another storage for fault analysis and correction. A failing message is typically moved to a dedicated queue called a dead-letter queue. To avoid overloading the infrastructure during temporary failure, for example, a network error, it must be possible to configure how often retries are performed, preferably with an increasing length of time between each retry.
producer configurations
consumer configurations
A helper class StreamBridge is used to trigger the processing. It will publish a message on a topic. A function that consumes events from a topic (not creating new events) can be defined by implementing the functional interface java.util.function.Consumer as:
using stream bridge to publish event
consumer bean
Stage 5: Discovery Service
Used Netflix Eureka for service discovery
With Spring Cloud, it is easier to set up a Netflix Eureka server and adapt Spring Boot-based microservices, both so that they can register themselves to Eureka during startup and, when acting as a client to other microservices, to keep track of available microservice instances.
discovery server configuration
discovery client configuration
Used a single instance of discovery server, which is okay in from the project perspective. But would probably need multi instance in a production environment for high availabilty.
Stage 6: Edge Server/Gateway Service
Introduced an edge server to the landscape, it can be used to secure a microservice landscape, which involves hiding private services from external usage and protecting public services when they’re used by external clients. All incoming requests will now be routed through the edge server
Stage 7: Authorization Server
The gateway will be configured to accept any access token it can validate using the digital signature provided by the authorization server. The product-composite service will also require the access token to contain valid OAuth 2.0 scopes:
• The product:read scope will be required for accessing the read-only APIs. • The product:write scope will be required for accessing the create and delete APIs.
Stage 8: Config Service
Introduced Spring Cloud Config, which provides the centralized management of configuration files for all the microservices
configuration files for all our microservices are stored in central configuration repository, which will make it much easier to handle them. All microservices were updated to retrieve their configuration from the configuration server at startup.
For the project I’ve resorted to using local file system as the repository but I plan to change this with a Github repository or something like Hashicorp Vault.
Structure of the local config repository looks something like this:
Future enchancement: Try to use Spring Cloud Bus to add support to detect changes in configuration and pushing notification to the affected microservice
Stage 9 : Resiliency using Circuit Breaker mechanism
Used resilience4j to implement a circuit breaker and retry mechanism between product-composite and product service.
How circuit breakers work:
Sometimes synchronous dependencies to other services can become unresponsive or even crash if these services stop responding as expected, especially under a high load. These types of error scenarios can be avoided by using a circuit breaker, which applies fail-fast logic and calls fallback methods when it is open.
Selected from shared topics, language and repository description—not editorial ratings.
JBRKR000 /
Spacewar2D is a 2D space shooter game built with the FXGL library. The player pilots a spaceship to defeat enemy ships. Developed solo for hobby and educational purposes, the project aims to deepen Java programming skills.
InspireNXE /
Ember is a voxel engine, built for Java, developed as a hobby project to tackle the unique challenges associated with game development
jie1311 /
This is an individual project for my personal hobby, which is a website with both front-end and back-end functionality, built with Spring MVC. With the data of different types of aircraft and airports, it has features such as data visualization and route search.
Mohamed-Imran-12 /
AuthShield is a hobby and learning-based authentication project built with Spring Boot, React.js, and MySQL. It provides basic authentication features like signup/login, JWT, email verification, and password reset to help students focus on core application development.
ScottJuvik /
Hobby project: A retro-style Java Space Invaders game built with the MVC architecture 🎮👾
YashM-235 /
My Sem-II project built on Java, for the purpose of Room Allocation, considering problems like language barrier, interests and hobbies.