<p>Hello world! This is my first-ever blog post. Cool, right?</p>
<h2>Who's behind the keyboard?</h2>
<p>That would be me, Szymon, a frontend software engineer. Recently, I have joined Microsoft to work on an internal monitoring &#x26; telemetry platform. Sounds familiar? Before that I was developing a large-scale SaaS observability (yep, monitoring) platform at Sumo Logic. It definitely seems like coding interactive dashboards and charts is my thing!</p>
<p>Lately, I've been having many thoughts and no place to share them. That's why I decided to build my personal website.</p>
<p>Interestingly, this isn't its first version. In fact, if you dig into commit history 😁, you will see I had a similar website some time ago. Life got busy, and I moved on, but the source code stayed on GitHub. I thought, why not give it another shot? So, armed with the lessons I've learned over the years, here we are again.</p>
<h2>The old vs the new - Static Side Generation</h2>
<p>I consider Static Site Generation a must for static sites which don't change much over time. It minimizes data transfer between the client and the server. It also paves the way for static hosting - a more cost-effective &#x26; faster way of hosting React apps than using Docker containers.</p>
<p>Old version of my website used <a href="https://www.gatsbyjs.com/">Gatsby</a> for SSG. Now it's all about <a href="https://nextjs.org/">Next.js</a>. Why make the jump?</p>
<p>Well, Next.js is rapidly becoming the go-to React framework. With the release of Next.js 13 and its Server Side Components, it's now the talk of the town in the frontend space. I wanted to dive in, see its benefits first-hand, and perhaps refresh some of the features I might have overlooked.</p>
<p>That said, it's not just about the tech. While I've observed fairly similar build times and other key metrics with both, I must say - and this is purely subjective - the developer experience feels more streamlined on Next.js compared to Gatsby.</p>
<h2>What can you expect?</h2>
<p>I'll mostly post about the technology world. Expect deep dives into frontend topics, handy programming tips &#x26; tricks, and occasional articles on self-development. However, I'm not (currently 😁) aiming to be next <a href="https://blog.pragmaticengineer.com/">The Pragmatic Engineer</a> - my posts will be somewhat shorter!</p>
<p>Every so often, I'll also write about my passions. Right now, that's motorcycles &#x26; cars, sci-fi literature. But hey, these change!</p>
<h3>How often?</h3>
<p>I'm aiming for biweekly posts, but don't be surprised if something pops up sooner (or perhaps a bit later).</p>
<h2>What's next?</h2>
<p>I have plans for a few upcoming posts. I want to create a detailed write-up on coding a blog from scratch (part 0 - preparations, decisions, architecture; part 1 - actual implementation, tips &#x26; tricks; part 2 - transitioning to Server Side Components).</p>
<p>Apart from that, I recently did some job interviews and helped some friends prep &#x26; secure jobs. I have many insights on crafting resumes/CVs and preparing for interviews. I will certainly share these here.</p>
<h2>Other places</h2>
<p>I'll be cross-posting each piece on my <a href="https://dev.to/szymonpulut">dev.to</a> blog. I'll also share updates on my <a href="https://linkedin.com/in/szymonpulut/">LinkedIn</a> with each new post. If you're into the old-school vibe, there's always the <a href="https://szymonpulut.com/feed.xml">RSS feed</a> to keep you in the loop.</p>
<h2>To my Sumo friends</h2>
<p>I want to say a heartfelt thank you to all my colleagues at Sumo Logic. Working in such tech-savvy environment has been an incredible experience and learning opportunity. However, this would've been all nothing if not for all the amazing people at Sumo. Thanks! I'm confident our paths will cross again in future 😉.</p>


Hello World! Welcome to my new site!

<p>Let's kick things off with a quick peek at the web app — it's all about displaying a sleek and clutter-free dashboard, somewhat similar in functionality to <a href="https://www.home-assistant.io/">Home Assistant</a>. I intentionally kept the functionality limited to maintain that clean, minimalist design. IoT Dashboard is deployed on a Raspberry Pi and displayed on a simple tablet mounted in my house.</p>
<p><img src="/images/iotdashboard.webp" alt="Screenshot of IoT Dashboard"></p>
<p>If you'd like to visit the repository, the link is here <a href="https://github.com/szymonpulut/IoTDashboard/">https://github.com/szymonpulut/IoTDashboard/</a>.</p>
<h2>A Bit of Background</h2>
<p>This application has been on quite a journey. I first built it a few years ago using pure JavaScript and direct DOM manipulations. Then, as I was learning React in 2019, I felt it was time for a rewrite. This transition marked a significant milestone for me, as it really showcased the power and simplicity of React.</p>
<p>This current version is the third iteration of the app. My goal this time was to elevate it to a production-grade level. I also wanted to challenge myself by making it full-stack, using Node.JS for the backend and GraphQL for seamless frontend-backend communication.</p>
<h2>Big Picture Overview</h2>
<p>Throughout the development process for both UI and backend applications, I focused on a couple of core principles:</p>
<ol>
<li>
<p><strong>Modularity</strong>: The app needed to be fully modular, making it easier to understand and extend in the future.</p>
</li>
<li>
<p><strong>Streamlined Process</strong>: I automated the CI/CD process, adopting tools like <a href="https://www.conventionalcommits.org/en/v1.0.0/">Conventional Commits</a> with <a href="https://github.com/googleapis/release-please">Release Please</a>, along with <a href="https://prettier.io/">Prettier</a> and <a href="https://eslint.org/">ESLint</a> for code styling and rule enforcement. <a href="https://typicode.github.io/husky/">Husky</a> handles linting on commit. While automated testing wasn't a priority initially, I plan to add some basic coverage down the road.</p>
</li>
<li>
<p><strong>File Naming Conventions</strong>: Both frontend and backend codebases adhere to clear naming conventions, facilitating file location and organization.</p>
</li>
</ol>
<h2>Frontend: The User Interface</h2>
<h3>Overview</h3>
<p>The UI is neatly organized into sections, aligned with CSS grid display areas. Key features include a clock, weather forecast, air quality measurements, temperature sensor data from around the house, control functionality for front gates, and integration with a shared Google Calendar.</p>
<p>For local development, I stick to simple <code>npm</code> commands, while deployment is made easy with <a href="https://www.docker.com/">Docker</a> and <a href="https://docs.docker.com/compose/">Docker Compose</a>.</p>
<h3>Technical Details</h3>
<p>The frontend focuses on simplicity, as most of the heavy lifting is done by the backend. It's built with React and TypeScript. Styled with <a href="https://styled-components.com/">styled-components</a>, and utilizes <a href="https://www.apollographql.com/docs/react/">Apollo Client</a> for GraphQL communications. The frontend build process is powered by lightning-fast <a href="https://vitejs.dev/">Vite</a>.</p>
<h2>Backend: The Real Core</h2>
<p>My expertise lies more in frontend development, so this project has been a valuable learning experience. I learned a lot about backend architecture, coding in Node.JS, and implementing a GraphQL server.</p>
<h3>Apollo Server &#x26; GraphQL</h3>
<p>To maintain modularity, I relied on <a href="https://the-guild.dev/graphql/tools">@graphql-tools</a> and custom code to ensure flexibility in schema and resolver management.</p>
<h3>Modules</h3>
<p>Modules, housed in the <a href="https://github.com/szymonpulut/IoTDashboard/tree/55f15878f21f588b3aceaa883d6a3b697a0a8cd8/server/src/api">/api/ directory</a>, come in two types:</p>
<ol>
<li>
<p><strong>Internal</strong>: These modules interact with internal smart home systems, like <a href="https://github.com/szymonpulut/IoTDashboard/tree/55f15878f21f588b3aceaa883d6a3b697a0a8cd8/server/src/api/gateControl">front gate control</a>, using <a href="https://mqtt.org/">MQTT</a> for communication (MQTT is a message broker similar to RabbitMQ or Kafka, specifically optimized for IoT devices).</p>
</li>
<li>
<p><strong>External</strong>: These modules interface with external APIs, like the <a href="https://github.com/szymonpulut/IoTDashboard/tree/55f15878f21f588b3aceaa883d6a3b697a0a8cd8/server/src/api/weather">weather forecast</a>, primarily fetching data via REST APIs. Responses are parsed with <a href="https://github.com/colinhacks/zod">zod</a> for full type safety.</p>
</li>
</ol>
<p>GraphQL schemas are defined in <code>.schema.graphql</code> files, with exposed actions listed in <code>.resolver.</code> files. Actions themselves are in <code>.dataSources.</code> and <code>.mutations.</code> files (for fetching and mutating data, respectively). Internal modules may also have <code>.handler.</code> files in a <code>/handlers/</code> subdirectory for handling incoming MQTT system broadcasts.</p>
<h3>Custom Utilities</h3>
<ul>
<li>
<p><strong>Fetching</strong>: I've developed a <a href="https://github.com/szymonpulut/IoTDashboard/blob/55f15878f21f588b3aceaa883d6a3b697a0a8cd8/server/src/utils/fetchData.utils.ts">data-fetching function</a> for consistent integration with <code>zod</code> and <a href="https://github.com/szymonpulut/IoTDashboard/blob/main/server/src/utils/cacheManager.utils.ts">simple caching</a>.</p>
</li>
<li>
<p><strong>MQTT</strong>: The MQTT setup, detailed in the <a href="https://github.com/szymonpulut/IoTDashboard/tree/55f15878f21f588b3aceaa883d6a3b697a0a8cd8/server/src/mqtt">/mqtt/ directory</a>, includes pre-defined topics and mappings for subscriptions and mutations. Secrets are managed via <a href="https://github.com/szymonpulut/IoTDashboard/blob/55f15878f21f588b3aceaa883d6a3b697a0a8cd8/server/src/mqtt/mqtt.topics.secret.example.ts">mqtt.topics.secret - example</a>, avoiding hardcoded values.</p>
</li>
</ul>
<h2>Challenges Faced</h2>
<p>The journey wasn't without its hurdles. Here are a couple of interesting challenges I encountered:</p>
<ol>
<li>
<p><strong>Setting up TypeScript in the backend</strong> proved more cumbersome than expected due to Node.JS's limitations in this area. Overcoming issues with <code>tsconfig</code> as well as imports during build &#x26; dev flows was particularly challenging.</p>
</li>
<li>
<p><strong>On the backend’s side, managing multiple GraphQL resolvers and schemas</strong> posed tooling-related hurdles, which was especially evident with separate modules. While centralizing everything by hardcoding resolver addresses was an option, I aimed for an auto-detection system.</p>
</li>
<li>
<p><strong>Integrating OAuth APIs</strong> introduced complexities, especially since I was more accustomed to simpler authentication mechanisms like JWT. Testing the integration involved using the GraphQL layer and added to the perceived difficulty.</p>
</li>
<li>
<p><strong>Battling perfectionism</strong> might sound like a cliché, but it was a real struggle. It took so long for me to publish this article because there always seemed to be another item on the TODO list (that would make the project so much better and/or professional). In the end, I decided to “force-release” this article even though there are some unfinished aspects, as a way to push past that barrier 😉</p>
</li>
</ol>
<h2>TODO</h2>
<p>There's always room for improvement! Here's what's on my radar:</p>
<ol>
<li>
<p><strong>Introduce automated testing</strong>. This wasn’t yet a priority, since this is a non-customer-facing application that does not serve a critical role. However, I appreciate the comfort of working with well-tested code (being able to freely refactor and plan to invest some time in it.</p>
</li>
<li>
<p><strong>Move certain interactions (night &#x26; silent mode, webcam view) into a menu</strong>. As I'm more accustomed to desktop-oriented applications, deciding on the best approach for triggering/displaying the menu is still up in the air.</p>
</li>
<li>
<p><strong>Find out a better way to store MQTT-related secrets</strong> rather than a <code>.gitignored</code> <code>.ts</code> file. This issue is especially frustrating when setting up the development/build environment on a new machine.</p>
</li>
<li>
<p><strong>Apply refactors across both server &#x26; client applications</strong>. On the client side, using React Portal for the webcam modal is a starting point, along with improving the setup in <code>main.tsx</code> &#x26; <code>App.tsx</code> is on my list. On the server side, renaming <code>externalSchemas</code> into <code>DTO</code> would be fitting, as well as a few changes in tooling - better code generation from GraphQL schemas.</p>
</li>
</ol>
<h2>Conclusion</h2>
<p>The IoT Dashboard isn't just a project — it's a constant companion throughout my career journey. With its modular design and efficient data handling, I'm proud of how far it's come. But perhaps most importantly, I am proud because I use it in my everyday life 😁</p>
<p>Stay tuned for more tech insights and stories from my journey in the world of software development. Until next time, keep coding and exploring! 🚀👨‍💻</p>


The Architecture Behind the IoT Dashboard

<h2>Presentations</h2>
<p>There were several noteworthy presentations throughout the day, but two, in particular, left a lasting impression on me.</p>
<p>First up was Aleksandra Sikora's talk titled "Turning Your Code Inside Out". Ola was live-coding an interpreter for a new language called OLang (a clever play on her name). This was a super-refreshing departure from the usual frontend/backend development. Plus, it was eye-opening to witness the power of GitHub Copilot in action.</p>
<p>The next presentation that really resonated with me was "Supply Chain Security: Risks and Open Source Tools to Assist" by Jossef Harush Kadouri. It shed light on the critical aspect of paying closer attention to project dependencies and utilizing tools like <a href="https://github.com/os-scar/overlay">Overlay</a> (overlays information about packages suggested on StackOverflow), <a href="https://deps.dev/">deps.dev</a>, <a href="https://snyk.io/advisor/">Snyk Advisor</a> (dependency comparison tools). A valuable lesson for anyone involved in software development.</p>
<p>I'd also like to give a shoutout to Illia Mishkin for his lightning talk on "Monorepo computation cache (self-hosted Nx Cloud alternative)". Although Illia seemed a bit nervous, it was evident that he had spent considerable time and effort researching the topic. The insights he shared were incredibly informative.</p>
<h2>Organization</h2>
<p>The conference's organization left little to be desired. One aspect that stood out to me was the hosting format. After each presentation, the host engaged in a sit-down discussion with the speaker, eliminating awkward moments of them standing around aimlessly. What's more, questions for the speakers were collected throughout the presentations via an online system accessible by scanning a QR code. Attendees could also vote for the best questions, adding an interactive element to the Q&#x26;A sessions.</p>
<h3>Pricing</h3>
<p>The meet.js conference is known for it's affordability. First-wave tickets were a steal at 100PLN (approximately 23USD), and even the second-wave tickets were reasonably priced at 200PLN (roughly 46USD). The registration fee also covered a lunch (tons of pizzas - nobody went hungry). Additionally, attendees could brew coffee at the available coffee machines. If that wasn't enough, if you craved snacks or barista-made coffee, the cinema's cafeteria was open.</p>
<h2>Conclusion</h2>
<p>I'm genuinely pleased that I attended the conference and can say that I'm looking forward to the next annual summit. Rumor has it that it might take place in Bielsko-Biała. I've got my fingers crossed, hope to see you all there!</p>


Category Technology

Hello World! Welcome to my new site!

The Architecture Behind the IoT Dashboard

meet.js Summit 2023 - Wrocław