-
Graphinder series articles
- Graphinder – Project Introduction
- Graphinder – I don’t need this covered…
- Graphinder – Minimum Vertex Cover problem
- Graphinder – Simulated Annealing algorithm
- Graphinder – Code review yourself
- Graphinder – Genetic Algorithm – Introduction
- Graphinder – Genetic Algorithm – Selection
- Graphinder – Genetic Algorithm – Crossover
- Graphinder – Genetic Algorithm – Mutation
- Graphinder – Genetic Algorithm – Wrap up
- Graphinder – Monthly Progress Report – March
- Graphinder – Async IEnumerable with Rx.Net and IObservable
- Graphinder – Reporting progress with Rx.Net
- Graphinder – TDD and starting from red
- Graphinder – Domain models vs Persistence models
- Graphinder – Queries and Commands vs Repository pattern
- Graphinder – Encapsulating persistence layer
- Graphinder – Solution changes and nuget hell
- Graphinder – Monthly Progress Report – April
- Graphinder – Application architecture
- Graphinder – Resources planning on Azure
- Graphinder – Quick summary and what next
- Quick thoughts after Daj Sie Poznac 2016 finals
Over week ago we’ve seen a second month of Daj sie poznac 2016
passing by.
Same as month ago, I’ve come to conclusion, that it would a good idea to note down what have I done in Graphinder project during last 4 weeks.
Current state of a project
April brought both progress on implementation and architecture levels. I’ve written less code and spent much, much more time actually thinking on why and how to do many things to stay both flexible and content about my decisions.
Algorithms microservice – persistence
First of all, persistence layer for Algorithms
microservice in its bare implementation is in place.
While working on it, I needed to work my way around few hurdles, that is:
- Unconventional domain layer – raw algorithms and optimization problems are generally a way of solving problems given by business, not a business domain per se; in Graphinder they are the core of the application
- Unconventional data types – to preserver progress of algorithm, I need to persist its current state; persisting solution as One-To-Many association with
Node
table smelled like NO-NO solution, so I’ve ended up borrowing idea fromGenetic Algorithm
and mapped chosen nodes as an array ofbool
, mapping it layer asbyte
array to DB. Not an ideal solution but quite fast. Would probably need a revision for more universal approach for other optimization problems. - Completely hiding up knowledge of how persistence works – that was actually quite fun part to do and quite personally rewarding to see the outcome: any other layer that asks persistence to retrieve or save data, has no idea what’s going on out there and has no way to use it if not through queries and commands
- Graphinder.WebApp – application based on ASP.NET MVC, SignalR, D3.js and (possibly, but not from start) React.
- Graphinder.Algorithm.GatewayApi – application based on ASP.NET WebAPI, serving as a gateway for scheduling work for algorithms and serving as CRUD endpoint for algorithms-related data; I’m almost 100% sure that it’d also share location with
Microsoft Orleans
. - Graphinder.Algorithm.WorkerApi – multiple instances of worker APIs that will be responsible for job retrieval, processing and persisting solutions for a problem and then returning it back to user; although written in WebAPI now, can be for example a NodeJS API and I’m definitely looking into creating one in a more distant future as
proof-of-concept
.
Graphinder project – architecture
Second of all, I’ve almost crystallized my idea on how an architecture of whole system would look like.
While I’d like to keep this covered in a separate post, I’d like to note few things that will be part of project:
As project structure also changed, it made some of links in previous posts pointing to location that no longer exists on GitHub.
I’d like to deeply apologize for that and as an atonement I’ve decided to… fix that next week. 🙈
I’m also revising possibilities on fitting everything I want to show on each consecutive release on Azure. For now, I’ve finally configured virtual network based Windows Server 2012 VM with RDP access through VPN. Took only 4 hours. Huh…
A week off from project
You probably haven’t noticed if you didn’t visit my GitHub account page, but my contributions in April went down to 50% of what I’ve done in March. I’ve also ended up with 20 out of 30 days with a commit, as opposed to 23 out of 30 days in March.
One of the reason of such state is that – as I’ve mentioned – I both fought few hurdles in persistence layer and wanted to revise entire Graphinder
architecture idea based on experience I’ve made during those 2 months.
But what’s more important is that as a simple, human being I needed some rest from a project and I took a whole week off from writing both posts and (partly) code for Graphinder
. I’ve been busy with code nonetheless as Regalia: Of Men And Monarchs is coming due to its beta and some of school work made me crunch on it a little more than usual.
While it’s almost impossible in job environment to take a week off from a certain project not taking a break from work per se, I’m glad I could do this with Graphinder
as now I’ve already grew hungry for new things that are waiting for implementation, starting from Monday and on!