Uncategorized – Page 3

Going to the gym after lockdown

Posted on March 2, 2021March 2, 2021 by Andris Z

Visit our website: https://www.fitradar.me/ and join the mailing list. Our app is coming soon.

Stay Loose

Posted on September 27, 2020September 28, 2020 by dzidai

Recently our team finished the work on FitRadar booking system. That was quite a challenging task and I decided to share some insights and knowledge we gained during the design and development of this system. Already on the early stage of designing and requirement gathering it was clear that ticket booking system on the back-end should be independent from the rest of the Fitradar system because we wanted to introduce Event Sourcing for such entities as Order and Payment. Since these two entities are responsible of money charging and money is always a very sensitive topic, we wanted to make sure we can always track down the state changes in booking and payment processes. But to what degree it should be independent was the question we had to answer.

Let’s start with a simple case we considered – one process application. In this kind of applications all communications between objects occur within one process and it means all libraries needed for application are loaded in single process. Usually when we talk about the client side applications – Android, iOS or client side JavaScript, then most of the time these kind of applications work within one process and rarely leave the boundaries of that process set by OS. In such case the isolation can be introduced on the code level, like implementing the new feature in a new library, but at runtime we are somewhat limited. Since all objects share the same process:

fault in one object might lead to crash in another object
the load of a single object affects the whole process, so we can’t assign PC resources to separate app components. It means you can only scale the whole application, usually by creating a new instance of the application. This starts to play a big role when app is hosted on cloud environment like Azure, Google Cloud or AWS where we must pay for used resources.
It is hard to apply new technology or framework to the new feature. Usually the whole application is build based on single architectural pattern like MVC and CRUD or MVC and CQRS and it is hard to introduce one more pattern (if we already using simple Data Access Objects for working with data coming from web, then it will take some time to introduce CQRS with Event Sourcing) in the same application. It is much simpler to create a new application.

So there is very little we can do about object decoupling at runtime in single process application case, but do we really need to deploy a booking system in a separate application? Maybe we can just isolate our booking system in a separate library and still run it in the same process with the rest of FitRadar libraries? And so we started to investigate it. Very quickly we noticed that our ideas of making booking system independent from the rest of application strongly reassembles the principles of Microservices architecture . And since now days there are a lot of talks around the Microservices we thought that our project might be a good candidate to move to Microservices architecture. But just because something is promoted doesn’t mean it fits your needs. You usually don’t start the development of application as a distributed system, unless it was a requirement from the beginning. Applications usually mature to the state when Monolithic Architecture doesn’t satisfy the initial requirements and a team starts to consider switching to Microservices Architecture. And we wanted to make sure that this is the time when the new feature requires us to switch to the new Architecture to make the development easier in the future. Here are the advantages of Microservices Architecture that really attracted our attention:

it gives us a smaller code base to work with. It is a really huge benefit if you consider that at certain point a team more and more starts to think about how properly structure the project (how to write the Clean Code), that any new developer could easy understand it and navigate it. And putting a Booking system as a separate solution would allow as to reduce the code complexity and as result would allow developers navigate faster and add new code faster. If you have ever worked on enterprise scale application development then you know how much time it can take just to figure out where to put your new code.
Web API end to end tests and Integration tests can run much faster because there is no need to load all of the Fitradar system libraries only those related to booking system. This advantage really starts to shine when we enter the test phase.
It allows us to scale booking system and the rest of the back-end application independently. The booking system is more focused on data writing in the database on the other hand main back-end application is focused on data serving. We expect thousands of data requests a day while user will be navigating around in mobile application and just few bookings a day.
Improved fault isolation

And for our project it seemed that we will gain more than loose if we will treat booking system as separate application and deploy it in a separate process. So we gave it a try.

Visit our website: http://fitradar.me/ and join the mailing list. Our app is coming soon!

Repositories and Data Access Objects are still alive

Posted on April 22, 2020April 29, 2020 by dzidai

In my previous articles when I was talking about Clean architecture and Domain Driven Design I mentioned one piece of domain layer – repository or more precisely repository pattern. The repository pattern is used to persist and retrieve domain models. Although repositories are mostly related to Domain Driven Design the other architectures might have the objects with the same functionality but are called different. In Fitradar application (front end and back end) the objects that are used to persist data in the database and fetch data from the database and map data to in-memory objects (aka POCO – Plain Old C# Object, POJO – Plain Old Java Object) and are not part of the Domain layer are called DAO (Data Access Objects). DAO usually are used in cases when no business logic is involved and the application needs to execute simple CRUD operation.

In Android application to work with database we use Room Persistence library but in our back-end solution we use Entity Framework Core. These two are know as Object-relational mappers or ORM. And today I wanted to explore the relationship between Domain Repositories, Data Access Objects and ORM and share some experience we had in our team working with these patterns and libraries.

If you look at the responsibilities of Repository, DAO and ORM they are very close to each other. Some years ago when ORM technology was in its inception the DAO and Repositories usually were working directly with the low level database access services. In case of .NET it was ADO.NET library and in case of Android it was SQLite library. And it was quite clear that DAO or Repository should use these libraries to persist or retrieve in-memory objects and map the data. But now-days when in application development main data access technology became ORM the border between ORM and DAO and Repository has become very blur, especially when one just switched to ORM. Working with ORM in different projects and languages our team came to conclusion that in same cases ORM can fully replace the DAO or Repository and can be used instead of it. Let’s look closer at the cases when it is appropriate to use just a ORM library and when the DAO or Repository should be used in combination with ORM:

If you need to save, update or delete single flat plain old object then in most cases ORM library will do the job for you. Of course EF Core and Room are capable of doing more, but then we really should investigate each case separately
If you need to fetch the data from single table by primary key then again in most cases you can fully relay on ORM
In case Domain layer aggregate has complex entity cluster hierarchy, where different entities might have different persistence state you most likely will need to write such aggregate persistence logic by yourself either using ORM or low level database access library. In our application one such aggregate is Sport Event that has Place and Organizer and some other entities. And the problem we faced when tried to save Sport Event by using built in EF Core capabilities was the different Entity State and the calculated state before Save operation. For example we had cases when we needed to create a Sport Event in Place that was not yet saved in database, and since both entities have the same Entity State EF Core tackled that case well and was able to create both entity records in database. But the problem started to appear when we wanted to create Sport Event in the Place that already had other Sport Events, now before saving aggregate Sport Event we had to fetch Place entity to make sure EF Core sets the correct Entity State. And the more entities your aggregate root has the more fetch operations might be needed. So in this case for us seemed obvious putting Entity State synchronization logic in separate Repository.
In case data query logic and following mapping logic is so complex that to make a code readable it is necessary to split logic in separate functions, you most likely will move those functions to separate class, Data Access Object, to persist the Single Responsibility principle.

As you can see the Repository and DAO still has their place in the modern software architecture. In case of queries in CQSR architecture query logic might be put in Application layer since anyway contrary to Commands, Queries only responsibility is data fetching, and that duplicates DAO responsibility. By choosing to put query logic in Application layer we make a direct dependency on EF Core. That is not a problem in classical three layer application, but it does not fit the Clean Architecture principle where Application layer should be aware only of Domain layer and with outer layers (EF Core belongs to the Infrastructure layer) communicates only through interfaces. In this case we should use DAO.

Please visit our website and join the mailing list. Our app is coming soon:

http://fitradar.me/

Study: fitness boosts brainpower in adults

Posted on January 25, 2020January 25, 2020 by Andris Z

Physical fitness has been associated with better brain structure and brain functioning in adults.

The findings of a study, led by Dr Jonathan Repple of the University Hospital Muenster in Germany, suggests that increasing fitness levels through exercise could result in improved cognitive ability – such as memory and problem solving – as well as improved structural changes in the brain.

A group of researchers led by Repple used a publicly available database of 1,200 MRI brain scans from the Human Connectome Project and combined it with physical testing to assess the subjects’ physical fitness. Each one’s cognitive ability was also measured. The researchers excluded subjects with pre-existing conditions, such as neurodevelopmental disorders, diabetes or high blood pressure.

The results of the study showed that physical endurance was positively associated with the global cognition scores of the subjects taking part.

In its conclusion, the group of researchers said the results of the study suggest that physical exercise could be used as a form of preventative healthcare.

“The observed pattern of results appears to support the notion of a beneficial effect of physical fitness on cognitive function,” the study reads.

“This notion is supported by the few available experimental studies indicating that physical exercise leads to increases in memory performance and brain structural integrity.

“This concept might be of relevance for a wide range of domains in health and life sciences including prevention, clinical care and neurobiological research.

“Along with previous findings, our findings point to the potential of physical fitness as a modifiable factor that might be applied as an intervention in prevention and clinical care.”

The report was simultaneously published in the Scientific Reports journal and presented at the ECNP Congress in Copenhagen, Denmark.

To read the study in full, click here.

Source: http://bit.ly/30Pqjy3

Please visit our website and join the mailing list. Our app is coming soon:

http://fitradar.me/