Hey yah, Eugene here!
I AM A SOFTWARE ENGINEER AND FRONT END DEVELOPER,
I will help you create and maintain your Saas/Paas products or any other software.
PROFICIENCIES
React JS, Redux, Redux Saga, XState, Javascript ES6, Node JS, REST API, Web Sockets, Graph QL, Docker, Kubernetes, NGINX, kafka, Redis, Git, Webpack, Babel, Styled Components, Sass, HTML 5, CSS3, Javascript, Netlify, Heroku, Firebase, MVC.
Meet me at github
Workable CRM Portal
Micro-service, Dynamic UI components, database configurable UI elements
This is project is a work in progress.
Aside from the advantages of microservices one of the features of this app is its configurations.
This project is a test bench for a platform that I am working on. The idea is we have a skeletal Front end app, it has default design, layout and features, and functionality. The features that are visible are configured in the database. Say, we have a left sidebar with a list of menus that would open a new tab. The actual menu item data are being fed from a server and the corresponding tabs are also coming from the server. The goal here is in terms of business functionality, base on a user's status, we can enable, disable and upgrade certain features with just a configuration and database mutation. Think of the tabs that would be open when a user clicks on the left side menu. We can limit the number of tabs that can be opened or disable certain functionality in general.
One key aspect of this architecture is we can build our app much faster. In general front-end applications take more time to deploy. With this system in place, we don't even have to deploy anything. We just have to do a few mutations from a database and we can transform our front-end application to whatever shape that suits any business requirements. Both front end and backend are developed with typescript. And CRUD operations are accommodated with a graphql server.
Currently, this application has 5 microservice running for signing up, signing in, adding vacancies, and getting vacancies. As this app grows larger I might consider wrapping it with containers like Docker and orchestration services like Kubernetes. I may add in a BUS system probably, Kafka or Nats, and a messaging system say bullJS to keep it simple
TECH STACK
React, Typescript, Xstate, GraphQL, Styled-components, MongoDB,
View Project on Github
Authentication System Design
Universal login, SSO (Single Sign in) with OIDC/PKCE
For authentication, we can utilize a universal login, SSO approach using OIDC/ PCKE pattern. Multiple applications will be authenticated via a single Identity Server. Once authenticated, users can navigate to protected routes. With universal login and SSO. If a certain user is already authenticated from other related domains or application, that user will be redirected to the protected routes that it defined in the redirect URI. When signing out that user should be signed out to all the applications that user is logged in. With OIDC, when not authenticated, users will be redirected to a login page being served by the identity server. An OIDC client will be needing a redirect URI, authentication server URI, client id, client secret and scope that is stored from an ENV file somewhere in the front end. When a user goes into a certain page, if not authenticated that user will redirected to login page, the url of that login page comes from the authentication server URI defined in the application. Users can then type in their user credentials. After pressing the login button, the user credentials, client id, client secret and scope will be submitted together. Client ID will tell the server which claims/application that user has access to. If authenticated the user will be redirected to the route that it defined in the redirect URI.
AIR INFORMATION DISPLAY SYSTEM DESIGN PROPOSAL
Event based Asynchronous Micro-service Architecture
Challenges
- Airport system is such a tough challenge to undertake. The gist of it is to come up with a solution that address the major concerns regarding the information that will be shown to the end users. It all boils down to the availability, fault tolerance, reliability, speed and scalability of the overall system.
- High network and web traffic. Thousands of request could be made with thousands of users simultaneously accessing the application that is using the system. Those could users could belong.
- Write operations will be extremely high since different scenarios will cause data to be updated in milliseconds such as flight delays, departure time updates, emergencies, etc. Concurrency and reliability issues will be challenge since read and write throughput is high.
- Availability issue, heaps of areas in the system could be unresponsive, will fail or crash completely.
Solution
Given the challenges and requirements I think an Event based Asynchronous Micro-service Architecture is the best solution. For most applications to be honest a monolithic system will suffice, however for systems like this, with mission critical data that needs to be delivered real time on different applications that is being used to access data by thousands for users. We should design a system that address the requirements with enough wiggle room for upgrades and maintenance (Meaning the system should stay 100% online while conducting upgrades/maintenance). That ensures evolvability and extensibility.
Searcheable
https://bit.ly/searchable-gene
View Project on Github
Live Image search web app with react, redux, and redux-saga, masonry grid layout created with CSS grid and styled-components. Scrolling with #reactinfinitescroll. Data fetching with REST API, react suspense and react lazy.
View it live from here https://eager-kilby-1c6b47.netlify.app This app uses free API and is limited to only 50 requests per hour. The app may be unable to display images for the reason above. #Debounce search implemented with redux-saga take latest middleware. Here I am implementing a live search feature where users type in some keywords then appropriate images would be displayed.
It is implemented in a way that limits or #debounce queries to avoid sending in fetch requests for every character that a user types. It works likes this, there is a 500 ms time out wherein a fetch request doesn't trigger before the time out lapses. However, the moment a user types another character, the time out resets then the whole process runs again. Only when the 500 ms lapses, a fetch request is made to get the image related to the user's query. For the styling, I wanted to implement a masonry-styled grid layout.
The first thing that came to my mind was to use CSS grids. Later I found out that it is not really that straightforward to implement. I wanted the image blocks to have fixed width and height and the masonry layout to have a fixed pattern. My solution was to used CSS:nth-child selector with formulas an+b which target specific IMG elements inside the parent element
Archipro
SAAS (client analytics dashboard and eCommerce app)
Archipro is an eCommerce business to consumer software as service app.
eCommerce page where website visitors can browse different suppliers
A landing page where clients can view a preview of their landing page as seen by website visitors
Supplier analytics dashboard page
Cashfull - Full Stack Lending PWA App
Tech stack
M.E.R.N - MongoDB, Express, React, NodeJS.
Redux, Reselect, React-Hooks, Context-API
Hosting
Front-end: Netlify,
Backend: Heroku
Disclamer
This web app is primarily build for mobile devices, as such development focused on mobile experience and designed to resemble closely with native app. For better experienced and when possible use your mobile phone. Still you can view on desktop browsers and see some responsive layouts. I'm working on the desktop layout at the moment.
Goals / Requirements
- Streamlined application process.
- Get high quality applicants
- Minimal applicant verification
- Maximize retention rate
- Collect prospects from users who registers.
- Minimize loan defaults
Challenges
- Potential lower impression rates due to strict targeting and filtering.
- Application form would have to be longer in order to account for filter applicants.
- Bounce rate might go up.
- Applicants who doesn't have access to internet banking would have to be let go
Solutions
- Filtering applicants could work well for countries with higher population where marketing can play around different targeting strategies without much setbacks.
- Utilize a multi-step form with clear indicator on where users are in the application.
- Develop a super friendly dashboard where users can clearly see the status of their loan. They should be able to check the next repayment schedule and how much to pay and how many repayments left. As well as, if ever they default, users can clearly see the missed repayment and the details about the missed repayment ie. default penalties. Big pay now cta button to make it easier for users to click.
- Also with strict filtering system, it would be less likely that a customer would default.
Features
- Loan calculator that gets dynamic interest rates based on users chosen loan details.
- Filter applicants based on certain criteria.
- Automated loan decision i.e. loan approved or rejected.
- Customer dashboard with active loans, upcoming payments and overdue payments tabs.
User Flow | Architecture
View project on github
The calculator has three main smart components that dispatches actions that
would update the state.
SMART COMPONENTS:
- Repayment Schedule
- Loan Amount
- Loan Duration
- Loan Amount
- Loan Duration
To calculate the repayment amount our app needs the final APR value that
gets updates when repayment schedule is set to weekly, fortnightly or monthly.
Repayment amount component is getting data as props from the smart components namely loan duration, loan amount and repayment schedule component.
Every time users update those component, their respected state returns a new
instance of the new state and the component that needs the new data receives
it as props.
I used selectors from reselect to calculate the repayment amount.
The selector then picks the latest value from the three smart
components and performs calculations using given business logic.
The selector then picks the latest value from the three smart
components and performs calculations using given business logic.
Since the state of three smart components are stored in a global store using redux
repayment amount selector is able to read the state anywhere.
Also by using reselect, I am able to use the formulas anywhere without the
need to create additional components.
need to create additional components.
In addition, with reselect the data are memoized by caching expensive
function calls. Cached results are returned if the same inputs occurs again without
function calls. Cached results are returned if the same inputs occurs again without
having to recalculate.
If not, all smart components gets updated then reselect would return the cached data
and use it to calculate the final output
without having to re-render the individual components.
without having to re-render the individual components.
Any component, anywhere in the app are able to access the state it using connect,
a High order component given by react-redux.
With redux, I was able to keep the app structure flat with no deeply nested
components. Otherwise, I would have to nest deep in order to pass props from
parents to the children that needs it. Since we need the 3 smart components
to calculate the repayment amount, we would have to nest so deep that it would
be a mess to keep track and debug(prop tunneling).
components. Otherwise, I would have to nest deep in order to pass props from
parents to the children that needs it. Since we need the 3 smart components
to calculate the repayment amount, we would have to nest so deep that it would
be a mess to keep track and debug(prop tunneling).
With the app broken into self contained atomic components, I am able
to use the component anywhere without having to recode
to use the component anywhere without having to recode
Performance
View project on Github
Lets talk, I'd like to hear from you
Thank you!