Live Blogging the Development of a New Feature: via ReactJS / .NET Core Web API. Part 0.

Steve Bogucki

Table of contents:

Part 0: Project introduction (You are here.)

Part 1: Source control, layout (git, CSS, Flexbox)

Part 2: Styling, routing (Material-UI, media queries, React-Router)

Part 3: CORS, stream readers

Part 4: Blobs for cloud storage (Microsoft Azure)

Part 5: Blob metadata

Part 6: Introduction to Unit Testing .NET Core (xUnit, Moq)

Part 7: Unit Testing .NET Core — in progress.

You’ll find here — beginning with this article — a series of updates as I design, build, and implement a new feature for my personal site,, as it currently appears, prior to this project’s initiation, on Jan. 31, 2019.

I love that tools like Slack, YouTube, Medium, Stack Overflow, Discord, and others have provided for developers an online community of peers and mentors, should we want it. A goal of mine in 2019 is to live stream on Twitch while I code. Until then, something a little less ambitious (i.e., this blog) will have to scratch that self-aggrandizing itch.

Here is some background on the codebase upon which we will be building:

  • The app is deployed to Azure, via Microsoft’s App Service.
  • The server layer is written in C#, via the .NET Core framework. It serves static files, some of which initiate the client-side Single Page Application, which is written in JavaScript, via the ReactJS library.
  • I’m using Visual Studio Community as the Integrated Development Environment (IDE) and git for source control (the repository is on GitHub HERE).

Here’s a summary of the feature that we will build during the course of this blog series:

We’re going to create a component that allows me to easily share an image from my phone. The image, along with some text details, will serve as a sort of daily log of one of my favorite activities: my morning run.

WAIT! To put that in the “Professionalese” language that Scrum Masters and the like may be more familiar:

“As a user, I want to upload a picture from my phone, along with some minimal text details (i.e., the date), that will auto-populate an image-log on The image upload feature should be password-protected.”

The image will either be a picture of the results from a treadmill screen or a screenshot of a map from a fitness app. Examples:


And the idea is that, each morning, I will upload a new picture from my phone that automatically replaces the existing run log picture on from the previous day.

The kicker is that I want to be able to upload the image from my phone and have it automatically populate on my site without me having to touch the actual codebase.


What we are really going to build is going to be a .NET Core Web API controller with a RESTful POST method. Additionally, we’ll create a simple UI for my personal use to connect to the API endpoint (that user interface will be little more than an upload button that allows me to browse for files on my phone). The POST method will be password-protected and will only accept requests (image uploads) from users — me — who provide the matching password.

In regards to the client-side app, we will have to build at least two things: a link from the main page to the new run-log and, of course, the run-log component itself.

I leveraged my personal uber-professional design skills to sketch out this ambitious diagram of what that aspect of the project will look like:

We’ll be working on the bottom third box; the “MainWindowRun” component.

And then, of course, we will have to implement automated testing. And deploy.

Along the way, we will use tools like Postman to test the functionality of the Web API.

Of the steps before me, I should be able to perform most of them without much research. The front-end design is fairly minor, so I feel like I have that under control. My plan for the Web API is pretty standard and, since this tool will be for my personal use only, that code won’t have to be quite as robust (accounting, say, for every possible edge case) that would be necessary if this feature was intended to be public-facing in an unrestricted way.

The only question left unanswered for me now is whether this project will need any sort of database. My plan currently is for the images, upon upload, to save to my App_Data folder within the project structure on the Azure server. But this will be a technique I’ve never used before and — to be honest — one I haven’t given much thought to, because I’m excited to learn how to best implement this as I work through it. Which to me is one of the fun benefits of this being a personal - not strictly professional - project. I have latitude for experimentation, and the extra work that will incur.

So, that’s the mission before us. Should you choose to accept it with me.

As far as timing goes; I’m unsure. I encourage you (and would no doubt appreciate) if you follow me either on Instagram or twitter. I’ll provide notification on social media when I publish the next article in this series. Likely, tomorrow (maybe?). My project manager disapproves of my lackadaisical level-of-effort estimate here, but I have no story-point prognostication to provide. We’ll play this one by ear.

Look forward to working on this, and sharing the progress with you. Thanks for following along!

(Click HERE for the next part in this series.)


Steve Bogucki

Written by

I like code, running, techno, and my dog. #TrustTheProcess.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade