I started this project almost five years ago as a way of pulling my data out of Fitbit and being able to analyse it myself. I wanted graphs Fitbit didn’t offer, and I just wanted to learn how to play with numbers. A large part of my day job is stats and being to pull information from huge datasets is a skill I wanted to work on, and so I thought my personal fitness data would be the perfect dataset to play with.
The documentation for this project is still scarce, but I’m working on it. In the meantime the project is split into two separate aliments:
- Store - which is the backend server powered by Symfony
- Angular - which is the frontend service written in Angular
I’m also working on a Docker installation to make testing a deployment simpler.
What’s In a Name?
The project got the name Core very generically. Initially it was simple called Fitbit-Sync but as it evolved and become less Fitbit centred I started thinking of it as the core of my fitness project and eventually the name stuck. I stick NX in front of name because I tend to stick NX in-front of most thing I work on, and core is so generic its been used on most sites you want to register with.
Since first imagined the project has grown arms and legs all over the place, but at it’s core it has a very simple set of mantras:
- It’s your data
- We’re all in this together
It’s Your Data
It’s your data. Whether it’s a Fitbit, Samsung Health, Garmin, Google Fit or Apple Watch. We generated health data by waring these trackers, and we send it up to the cloud for them to use and process in what ever way their ToS dictate - I have no problems with this arrangement, if I did I’d never have bought a third parties hardware.
What made me create this software was the belief that just because I’ve put my data into the cloud doesn’t me it’s no longer mine. Nx Core is intended to use public APIs and exports to pull your information from these third parties into one database you have control over. I never intended to support hacks or web scrappers. If a freely exportable option is not available then it’s a service I want keep using.
A happy side effect has been I recently switch from my trusty Fitbit to a new Samsung. Core has let me keep my data intact. I still have my full history, I can still compare my weight today against my weight last year. The freedom (as in ‘speech’) to move from tracker to tracker depending on who give me the features I want. Rather than feeling if I move I’d lose everything I’ve already done.
We’re all in this together
Friends are a huge part of what helps us motivate when on any fitness journey, but friends rely on us all being on the same platform, and the same server. I wanted an independent option.
Core has the intention of allowing everyone to be friends which ever hardware they use. When I was a Fitbiter I had about 25 active friends. When I moved to Samsung I lost them all, now I have 1 semi-active friend, and it’s just not the same. With Core, we can all be friends again. At present this relies on you all being on the same server, but as part of the Road Map I want to extend this to a truly decentralised platform. Anyone on any server should still be able to be friends.
The biggest design choice I made when starting Core was to impose a complete separation between the Frontend and Backend. The backend server (Simply called Store) does all the heavy lifting. It takes in user request GET/POST/UPDATE etc. and produces sensible JSON string. The frontend should not try to alter the JSON sent from the Backend. The Frontend’s job is solely to display the information to the user provided by the Backend in what ever way it wants.
Likewise, the Backend should not attempt to provide formatting to the Frontend, only data and calculated results (average weight over time etc.).
Rightly or wrongly (and I’m open to discussion around this choice) my reasoning is, this should create consistent end points withing the Store API. Making frontend development easier and meaning what ever platform the frontend is written for; Web, Android or iOS. The value provided to the user should be the same.
The other reason behind this was purely selfish. I have no skill for webdesign, but I do like a pretty website. I wanted to freedom to use an off the shelf web page template with my Core data. So far this hasn’t happened, but if I’d tided rendering into the Backend I’d have tied my own hands down the line.
Anyone can help with this project. Whether you code, write docs or even just come up with new and interesting ideas everyone is welcome to help and any help will be welcome!. I’ve set the project up on GitLab (although there is a Github mirror). GitLab vs. Github is a very personal choice, but for me it is very pragmatic. I use a self hosted GitLab instance for most of my git repo, so it is just the platform I know, and the one I’m most comfortable with.
If you want to stay up to date on the project and how I’m getting on with the documentation, or just want a chat about it please feel free to join me over on my Discord server.
Ideas & Bugs
Some of the biggest help anyone can offer are fresh ideas. I recently posted on the /r/selfhosted sub-reddit and have been blown away by the fantastic suggestions put forward. I’m going over each comment and created a new issue on GitLab to track every suggestion. If you want to join the conversation, and your voice to any of the suggestions please head over there and join in.
Bugs are everywhere, and my code will be no acceptation. Sadly developing any code of any complexity will introduce some bugs. If you find any please let me know using the GitLab issue feature. If you found it, chances are someone else is going through it too and sooner I know about them the sooner I can start working on the fix.
Try it out
The best way to see what Core has to offer is to try it. I’ve created a Demo account on the server at COMING SOON, just login with the username demo and password demo. The information there is from my own records (all-be-it several years out of date), and the workout recordings are from a couple of my favourite walks (also nowhere near where I live)
For anyone not ready or wanting to host their own instance of Core I’ve opened up my own ‘release’ instance for anyone to register on. Being a ‘release’ the instance will be more stable but may be missing some of the latest features available in the ‘master’ branch. (see the Git flow section for an explanation on how I’m using branches to manage my repos).
I love Docker composers, so I’ve made a Docker repo that should pull download all dependencies and give you a working installation. At present, it’s using the php-apache Docker image and in my limited testing the performance wasn’t great. I am planning to change that to use the nginx image which should improve performance, but I’m not there yet.
Instructions Coming Soon…
Instructions Coming Soon…
Please checkout both the Code of Conduct and the Contributions Guide before starting to contribute to the code base.
I have tried using load of different workflows for Git, but in the end the one I’ve settled for this time is simple.
- ‘master’ - Is the main development branch. Anything that would be a quick fix (less than an hour or so) gets done straight in master.
- ‘branches’ - Anything that will take longer or make a possibly braking change to the API should be have an issue created for it, and a separate branch to work on that code. Then a merge request is then needed to merge that back into ‘master’.
- ‘release’ - Is for stable code. When features are added to master and considered stable a merge request is made to push them into the release branch. Version tags are also set on this branch.
This approach is a mix of GitLab Flow and what’s worked for me in the past.