NotesChat

NotesChat is my private learning project that just reached it's 1.0.0 release. I just made it public so check it out on Github at:
Github/NotesChat

In this blog-article I am going to write about the reasons for the project and what I've learned.

Why a Chat-App?

1. Because I hate that I can't edit messages in WhatsApp for more than 15min or something. I often send ToDo-Lists and Idea-Lists that I want to constantly expand upon or update but I can't. Instead I have to use two Apps.
2. I wanted to learn how to build an App using MicroServices.
3. I wanted to learn how to use WebSockets without any libraries.

What I've learned?

The first lesson

The first lesson most certainly is, that it is stupid to build Microservices without any shared-libraries. Though this made the repository structure and the getting-started easier, it really is a pain to develop functionality across services. I would often need to copy files, DTOs or code lines. I made an active choice against libraries and it was the wrong one.

The second lesson

The second lesson is about the chosen technology.

Flutter

Flutter is not ready for use-cases like this. Especially the WebSocket library I've used has some quirks because of which I needed to implement extra edge-case handling on my server (ChatRouter). I don't want to blame the author(s) of the library, I am just new to WebSockets. Another thing about Flutter is that it might come with an extensive Material 3 library, but even though the names of components and concepts like pages are mostly the same, the implementation differs from the Material Design 3 spec. You have to define your own Page-Padding and Action-Button-Padding, which is hilarious with this being one of the few official implementations of Material Design 3.

C-Sharp

As for C-Sharp, it is the language I've used the most over the years. I however mostly used it for programming games with Unity and writing small Console-Tools, never something big like a WebAPI.
Since I've especially recently been writing a lot of WebAPI stuff with rust and also started using rust as my primary "scripting"-language (It's technically still a programm and not a script...), I am much more comfortable with rusts errors-as-value concept than with the whole try-catch thing. I did include a work-around, one of the few cases where I straight-up copied code from copilot, but it still didn't feel as comfortable as in rust. Especially since every time I used a library I needed to use try-catch anyway.

The third lesson

The third lesson is about Microservices.
It is most certainly an architecture that big, scalable systems need, but it is not something you should use for small to medium sized private projects like NotesChat. It just makes the whole development a lot harder, because when you want to add a feature, you need to change all the right services, then also think about cross-dependencies to other services and remember to restart them in the correct order, hoping the glass-house does not break.
This certainly is accelerated by my stupid choice to not build shared-libraries, but as soon as you use another language, you have to do things from scratch multiple times anyway.
This makes one of Microservices biggest strengths also it's weakness and made me stick to flutter and C# instead of writing a few services in rust or go.

The fourth lesson

The fourth lesson is about motivation.
During development I had a simple note in Google Keep Notes to keep track of what I still needed/wanted to do for NotesChat. Sometimes I would add random ideas throughout the day.
This led to me having ToDos of all sizes. From quick one or two liners to whole new features or even services.
When I sat down to code I could start with whatever sized task I felt like and then move on to other ones. I really felt the "5-Minute" rule in those moments, because on days that I didn't feel motivated, I could literally sit down for 5-Minutes, write some code and either be done for the day or move on to a slightly larger task.
I am still not gonna do Microservices for private projects again, but I am certainly going to do the To-Do-List in Keep Notes again.

The fifth lesson

The fifth lesson is about scope.
Because of how open the project definition was: "A Chat-App with the ability to mark messages as Notes", I could just add smaller side-projects onto NotesChat.
Is this scope-creep? Most certainly.
Did this help me actually finish the project? Surprisingly: yes.
Why though? I think because I could not be side-tracked because every project I had did contribute to NotesChat in some way or another. (I imagine this being a controversial take since it can be boiled down to "can't be sidetracked if you've only got one project". And yes, that is sort of what I am saying.)
One of those "side-projects" was an Ollama-Connector with the ability to create configurations of model + system-message.
This taught me about writing non-invasive Add-Ons. What I mean is an Add-On that does not change the code of the core Service/App.
It's a pain because of all the restrictions. Imaging being your own customer. A gruesome fantasy for most developers... But it was fun due to it's complexity.

Wrap-Up

Five Lessons seems like a good number of lessons for now.
I already said it multiple times, but it shall be repeated again:
As much as this project was hard and complicated, I had fun because of it. That is what coding is about for me.
As a side-note: That is why I did not vibe-code this project. It is not a product, it is a project for learning and having fun. I am spending my hard earned free time on the project after all. If I didn't like it and vibe-coded it, I wouldn't see the point in the project.

Well, whatever. Go check out the project here: Github/NotesChat.
If you have questions or run into issues, reach out in the comments section or via Github. I do technically also have socials like Instagram and Twitter, but I am not all to active on them.