This post is about Pika Core – a core of Pika Cloud web system. Pika Core consists of few components:
- Storage browser,
- REST API,
- User Authorization Provider,
- Admin panel.
Little bit of Pika Core’s history
Pika Core’s inital name was FMS. This shorthand stands for File Management System. For instance, I wanted it to serve me as well as my friends and even anonymous users. However, I haven’t planned it to be a core of bigger web ecosystem.
In this paragraph I will say something more about UI and UX changes – so a little bit about colours, logos etc. First versions were mostly white. Yes, just white. Next versions used different variations of colours – white with blue, white with dark blue, dark grey with teal, dark grey with cyber green and others. The pallete color I use now has become the main one, after some time after changing CSS framework from Bootstrap to MaterializeCSS. Therefore I realized I need a new colour palette to match Google UX and UI guidelines. This is how I created the one you see now: dirty white with indigo and some accent color. Each subsystem will have its own accent color:
- Core has teal,
- Status has light green,
- Note has accent red,
- Player will have orange.
What’s more is even codename of project changed through time. One of first version was “Caroline”, but I don’t remember other names. I just know that some time ago I decided not to change Pika Core’s codename anymore so I set its codename to Hannah after my little stepsister. And the thing with brand name is, it was just a joke at first. But after some time I thought it will be a good idea to just use Pika as an element of all brands for whole components in the web system. So, this is how a joke from office became a name of my cloud system 😀 . For some time pika was even in logo of it. This old logo is still used somewhere in the page, just look for it… And a new logo is used as “featured image” of this post.
Features of Pika Core
This web system is responsible for registering new users and allowing old users to log in. In the future, I plan to use Pika Core’s login page as SSO entrypoint. The module responsible for it is User Auhtorization Provider. It uses Identity Framework to authorize and authenticate users basing on roles.
From the very beginning this system was planned to allow anonymous access to my server’s storage. It was it’s first actual feature just after authorization.
To say more, a lot of features which can be seen today were actually planned. Actual form of Pika Core was the same from it’s first moment. The only feature which won’t be implemented is media player. For instance, it’s because of the decision I made. I decided to move whole player to separated web system.
At the moment REST API is not really big. It just supports Pika Status and authorization. Auhtorization is fully server side and does not need to add anything to headers, thus I mean any bearer or Basic auth etc. Identity Framework identifies each client with unique key, stored in well-secured storage files encrypted with X.509 compliant certificate. What’s more, REST API will be responsible for implementation of Federation pattern and integration of all client systems: Pika Note and mobile app. And this not the end because REST API of Pika Core will be able to return some files as a stream too. Thus, I mean all files which are not playable so JPEG, PNG, PDF, TAR, ZIP etc. Playable content will be accessible through Pika Player’s REST API which will be proxy to access to gRPC service, but more about I will tell in another post.
Admin panel is something I won’t really describe here. It’s nothing big and you know… security reasons and stuff 😉 .
Technical details of Pika Core architecture
I won’t write here how Identity Framework does really work, as of the fact it is all written down in MSDN. However, I won’t write here all of details of how I configured security on Pika Core – this will be another topic for another post. The most important thing to describe here is Pika Core’s design.
Browser is basically a listing of files stored on server’s filesystem. It is not a root of filesystem, this is one folder I chose for Pika Core. .NET Core maps this directory to be a root of my application’s filesystem. At the beginning, I used session to store where the user is in the directory tree. Now StorageController is compatible with main rule of Richardson’s model of maturity – it says that the server should always be stateless. Whole model refers to REST APIs, however it can be easily mapped for any other web application, because of its generic design.
So, now let’s say briefly how Browser lists all of directory contents. At first, web browser sends a request to the application on /Core/Storage/Browse endpoint with “path” param. Path parameter determines what path on app’s filesystem content we are actually listing. Then controller requests listing from a proper service. Next the controller creates a ViewModel object and then returns it with HTTP 200 OK to the client. Razor engine uses ViewModel object in template to render its content. All content is stored in public property of type IList<IFileInfo>. Web system creates thumbnail for videos and images asynchronously in the background. Web browser can download all thumbnails dynamically just after each one is ready. Pika Cloud’s core stores all thumbnails in filesystem cache.
Future of Pika Core
I refactored Pika Core lately. Saying “refactored” I mean that I have rewritten all its core logic and added some more features. However, I still haven’t finished it yet. There are some features such as:
- Copy/Move with dynamically rendered widget,
- downloading folder as a zip/7z,
- REST API improvments,
- monitoring system improvements,
- overall CSP fixes, code cleanup etc,
- Probably I will move whole app to Docker container.
There are no more plans for Pika Core itself. Even that Pika Core is a simple web application, I am kind of proud of it.
Thanks for reading and see you.