Forem: James 'Dante' Midzi

Crypto Forge - Embracing Nuxt

James 'Dante' Midzi — Tue, 06 Jan 2026 15:58:39 +0000

I was out of commission for several months. During my time away I got time to refocus, recentre and work on my writing.

When I was finally cleared one of the things I did was refresh my memory in several technology I had settled on. One of them was Nuxt, as I outlined in this article .

I am here to present to you Crypto Forge- an app that lists cryptocurrencies and allows you to sort them in different ways.

In essence it is a migration of Brad Traversy's project, Crypto Dash that was in React.

Why Recreate Instead of Building Something New?

As I mention, I needed a refresher on a lot of the tools I had chosen. Rather than come up with a whole new ides, to dip my toes back in, I thought migrating something that is already working would be simpler than starting something completely from scratch. I do have ideas.

What I Learnt

This exploration offered several learning opportunities, and entailed understanding what React was doing and translating that to Vue/Nuxt.

API Routes For Data Fetching

Initially when I stated, I tried to fetch the data directly in the page. Upon further reading, and advice from the discord I learnt that it was recommended to use the server folder and API routes to handle fetching of data.

This helps in better managing server only parts of a Nuxt application. Using the server folder also helps in scalability and structuring of endpoints.

While in this project I only made use of GET requests, in another one I am working I made full use of all the HTTP methods - it's a bit more complex.

My usage looks like this:

//server/api/coin.get.js
export default defineEventHandler(async (event) => {
    const query = getQuery(event);

    return await $fetch("https://api.coingecko.com/api/v3/coins/markets", {
        params: {
            vs_currency: "usd",
            order: query.order ?? "market_cap_desc",
            per_page: query.per_page ?? 10,
            page: query.page ?? 1,
            sparkline: true,
        },
    });
});

NOTE:
Ideally the URL would be in an environment variable

Composables To Avoid Logic Duplication

A composable is a reusable function that performs some kind of logic. Say you needed to fetch user data for each page they visit on your app, rather that making that call every time, you would create a composable that does that.

For example:

//src/composables/useUser.js

export const useUser = () => {
  // Shared, SSR-safe state
  const user = useState<any | null>('user', () => null)


  aaync function fetchUser(){
      const { data } = await useFetch('/api/user', {
        credentials: 'include', // important for auth cookies
      })

      user.value = data.value
  }

  return {
    user,
    fetchUser
  }
}

I made use of a composable to fetch the coin data. That piece of code is too long too share, you can view it in the repository though.

What's Next?

I have already started work on my next project using Nuxt. I am still contemplating whether to make it public or not. Broadly, I need to get a authentication and connecting to the database fully functional. So in the next coming weeks, I just might release it to the wild.

I am still fixing issues with my policies and row level security.

Wrapping Up

This was a fun exploration to get me back into the swing of things. I got to learn new ways of doing things; which I would argue are better than the other technologies I have explored.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

Laravel is How Development Should Be

James 'Dante' Midzi — Mon, 31 Mar 2025 07:11:42 +0000

I have not been doing that much writing. Not because I've nothing to write about, no. It's because I have been head down, silent and learning.

I have been learning Laravel. If you read this article of mine you will recall I said I wouldn't reach for Laravel because I already use TYPO3. I had to walk back that statement when I realised while I have TYPO3, it is better suited to more involved projects.

What changed? Well, I have a biggish project I am working on and I landed in a situation where SvelteKit wasn't sufficient and TYPO3 was too much. I needed a midpoint - and I was not going to go back to Nextjs.

Laravel

Instead of trying to rattle my head with something new, I chose to leverage the PHP that I already know. On another journey I went, and what a wondrous one it turned out to be.

Why Laravel Works?

It just does. In encounters that I have had with it, it shows a lot of thought went into creation of the framework. I don't know how to explain it, but it just does. Most things you may want to do, Laravel most likely has an in-built solution. Batteries included, I hear people say.

Authentication and Authorisation

A thing that we all have to handle as developers is auth. In previous times I have always left this until the end because a number of the options were a headache to deal with.

This is not the case with Laravel. You could choose to setup up the authentication flow on your own with code that sort of looks like this:

public function store()
    {
        //validate
        $validatedAttributes = request()->validate([
            'first_name' => ['required'],
            'last_name' => ['required'],
            'email' => ['required', 'email'],
            'password' => ['required', Password::min(6), 'confirmed'],
        ]);

        // create user
        $user = User::create($validatedAttributes);

        // log in
        Auth::login($user);

        //redirect
        return redirect('/dashboard');


    }

Or you could pick on of the starters that handle this for you. Some of them adding a few features to the process.

The same goes for authorisation. Based on how you want the access to things to be be you can specify the authorisation rules on the specific routes, app-wide or on individual controllers.

// auth on a route
Route::get('/jobs/{job}/edit', [JobController::class, 'edit'])
    ->middleware('auth')
    ->can('edit', 'job');

// the policy that manages it
 public function edit(User $user, Job $job): bool
    {
        return $job->employer->user->is($user);
    }

Database Relations

A thing that has given me trouble when building is database relations. I recall a time on one of the projects I was working on I got stuck trying to define database relations with Prisma. Some of it was because of how new I was at it. But even after I understood what was required the particular process manged to confuse me more.

Laravel on the other hand is intuitive about relations. Yes, you have a couple of places you have to ensure you have handled. But that, I have found makes you consider things more deeply and pay close attention.

Take for example; you have an Employers table and a Jobs table. Each Employer can have many Jobs. For that you would:

Add the relation in the migration file
Define the relations in the respective model files

Code snippets in this article are taken from my Learn Laravel in 30 days repository as well as the final project from that.

Appreciation

I would also like to thank Jeffrey Way for making my journey into Laravel an enjoyable experience. I highly recommend the 30 days to learn Laravel playlist.

What About SvelteKit?

It's a very unfortunate thing really. I find myself in the position of having to walk back on things I said.

A little while after I adopted Svelte, several changes were made that go against the simplicity I have been aiming for. As such, if I am to use SvelteKit now, it would be in the state that I found it in when I started and now. As for the time being, me and Sveltekit are taking a break.

Wrapping Up

I never paid that much attention to Laravel and I regret that. However, at least I have seen the light.

Although, I am not a fan of how the Laravel team are trying to streamline the project creation process. I don't like starters I didn't make is all.

I have been doing a lot of walking back my statements recently, huh?

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

How Svelte 5 Made Me Understand Nuxt

James 'Dante' Midzi — Thu, 27 Feb 2025 10:38:37 +0000

I have gone on a journey. A long winding journey. A journey I could not have foreseen. As it would have it; I am back, once again, announcing my change in methodologies and workflows.

A lot has happened in the world of development and tech; from React and Next.js, to Lucia, to Laravel, to Astro. So much to talk about...

One of those 'changes' has made go back to the drawing board yet again. Something I did not think I would have had to to do for about 3 to 5 years. Yet, here we are; me eating my words. Rather than having to answer question later down the line, I figured it would be simpler for me to talk about and explain my decisions.

The Changes

It all boils down to one thing really. One thing that has been made core and I cannot get with it.

Runes - My Friction Point

I have read through the documentation, I watched the release videos. I have explored the new way. After all that, I will never accept the runes syntax. My brain will not find synergy.

This - whatever this way is - is in opposition of all the reasons I gravitated towards Svelte and Sveltekit.

let count = $state(0);
let double = $derived(count * 2)

$effect(() => {
    setInterval(() => {
        elapsed += 1;
    }, interval);
});

I understand all of it, I get what they were trying to accomplish. I just don't like it. It is too indicative of React; and I left React ages ago.

I left the useState and useEffect of React because they wound up complicating what should have been simple. The runes syntax of Svelte feels a little to similar to React and I have no intention of writing that kind of code again. Regardless of how 'better' it may be.

For me there was something elegant about Svelte's $: syntax. It was simple, straightforward and easy enough to understand. It wasn't perfect, but it worked.

Then Snippets...

To be able to have and reuse chunks of code. Sounds cool on paper, but looking at the code and the implementation, it feels too much like a React way of doing things. There are waaaaay to many symbols for my liking. This is horrible to look at:

<script>
    let { message = `it's great to see you!` } = $props();
</script>

{#snippet hello(name)}
    <p>hello {name}! {message}!</p>
{/snippet}

{@render hello('alice')}
{@render hello('bob')}

Nuxt

In an article, where I sang the praises of SvelteKit, I said that I didn't like Nuxt and how it did templating.

With the looming arrival of Svelte 5, I revisited decisions I had made earlier. I realised that a lot of what I was complaining about had to do with my misunderstanding. I got over those misconceptions and learnt, built and migrated some projects.

A few things that finally won me over were:

File-Based Routing: Nuxt implements file based routing, not directory based - I have an article on this. I have always been partial to file-based routing. I only tolerated SvelteKit's directory approach because everything else is simple.
Auto Imports: In most frameworks if you wish to import something into a file, you usually have an import statement at the top. This is not the case with Nuxt
Separation of Concerns: I mentioned this in that same article; how I was not a fan of Next.js placing everything in a single directory. Nuxt doesn't have that problem - everything has its specified place
- Pages
- Layouts
- Middleware
- Server
Modules: So the Nuxt people have modules, modules upon modules to things you may want to add to your project; icons, SEO, sitemaps, fonts. Nuxt probably has a module for that. Reminds me of Astro integrations - I love those.

I was wrong about Nuxt, I admit that.

Wrapping Up

I guess that's the beauty of being a developer and an adult; the ability to choose what I use and what I don't. If I am not happy in what I am doing and what I am doing it with, I will rarely ever invest that much commitment into it - this is where I have arrived with Svelte - I am not happy, I feel I am moving backwards.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

You Don't Need The Flex

James 'Dante' Midzi — Mon, 27 Jan 2025 12:04:52 +0000

I find it very amusing that this is going to be my first post of the year. But it has bothered me enough that I must speak about it.

No one can deny the godsend that tailwind has been. We are able to prototype faster and get things done quickly.

I have noticed in the upsurge of Tailwind, has come with a forgetting and overlooking of some properties inherent in CSS and HTML.

Block and Inline Elements

Yes, I am afraid we have to go there...

Block-Level Element

I actually fail to understand how people forgot about the block element aspect of HTML. I see someone doing this:

<div class="flex flex-col">
    <p>One</p>
    <p>Two</p>
    <p>Three</p>
</div>

And all they wanted to do was have elements one after each other - stack them. They already do that! That is what HTML inherently does.

Block-level elements always start a new line.

Yes, of course I understand there are certain instances where you want your element to only take up as little space as possible - what flex does - but paying attention to what they have done, that is rarely the case.

Have a gander a some block elements

<div>    <p>    <main>    <section>    <header>    <nav>    <h1>-<h6>

To quote something Kevin Powell said (I am paraphrasing):

"Don't undo the styling and then end up redoing it again. Use the HTML to your advantage"

Inline-Level Element

For posterity, it is only right I talk about inline elements as well. In HTML, there are certain elements that are not block. These elements only take up as much width as necessary. As such you can place them side by side - they do not naturally stack.

Some inline elements you are familiar with:

<a>    <img>    <input>    <span>    <button>

Wrapping Up

So next time you are trying to stack elements, don't just rush to add flex. Put your elements on the page and see if they stack as you want. Unhand the flex and think about what you want your resulting outcome to be.

And if what I said, doesn't make sense, here is a link to w3schools with examples you can play around with.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

Your Constant Quest For Productivity May Be Hurting You

James 'Dante' Midzi — Wed, 17 Jul 2024 12:26:44 +0000

I have been head down working on several things. During the time I found myself accomplishing a lot of what I had set out to. Accomplishing a lot more than I would previously. What changed?

Let me take you on a journey...

A number of the decisions I took towards the end of the previous year began to pay dividend. These included my stepping away from React and that ecosystem. Changing how I go about accomplishing the things I set out to. Elimination of things from my life and avoidance of others.

Anyway, I digress...

Let's talk productivity...

Productivity

You will be hard pressed to not encounter someone talking about productivity this or productivity that. Be it an app, a book or some system that has 'increased their productivity'. Everyone and their grandma is on some tool, some book, some extension or some keyboard shortcuts to increase productivity - and it never ends. There is always going to be something, there is always something and there will always be something.

One of the things I did, or rather didn't do, was stop hunting down tools and methods to 'achieve ultimate productivity'. A realisation hit me; I asked myself; with all this focus on creating the most productive work environment, is anything actually getting done?

Why that question specifically? It boils down to an insight I had while I was reading and taking in the words in my own time. In it, our guide said something that made me stop and think. It was something to effect of:

The only thing you have the power to control is you. And as long as you are controlled by external forces, you will not be free.

Which in turn got me thinking; all this 'productivity' everyone is stuck in endless loops in search of, who is it for? Does anyone really want to be productive, or do they want to look like they're being productive? I have to admit, at a point I was guilty of the latter.

That choice, that simple decision of asking myself; this that I am doing, is it helping me in any way? Is it aiding me getting to my keystones in any way? When I answered those questions honestly, a shift in my mindset occurred. I did away with all the hype and zeroed in on what was important to me.

The More You Look for Productivity, the Less You Accomplish

That was the observation, the conclusion I came to. Every minute, every second spent on trying to and looking for ways to be 'productive' was a minute spent on not getting anything done. Simple as that. There is no hidden tool, special book or supposed system that will get you to be more 'productive'.

The change that needs to happen is you, within you. Once your mind is set right and your focuses are correctly aligned, things will begin to work smoothly and you will attain that 'productivity' that you've been feverishly hunting.

Contrary to what you might have been lead to believe, there is such a thing as too much 'productivity'.

Conclusion

Forget the productivity tools, forget the books, forget the systems. Do the work, accomplish the task. Quiet the noise. Productivity is not some magic pill you can stumble upon, it is a shift in mindset. Wrap your head around that, and stop hunting for magic geese.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

Say Hello To shrinkat - A Tiny URL Shortener

James 'Dante' Midzi — Mon, 15 Apr 2024 14:48:38 +0000

TLDR
I made a link shortener. The goal was to learn the Pocketbase API and see if it could be viable for some smaller projects I build in the future.

There is really not much to say here. I wanted to implement an entirely localised solution to building something

Technologies I Used

SvelteKit (of course)
Pocketbase ¹
TailwindCss

What I Learnt

How authentication works with Pocketbase: It's quite different from how something like Supabase handles it.
Data modelling: Being sqlite, the way I had to think about data needed a slight shift in mindset.
Working with the Pocktebase sqlite database: Working with a barebones database was actually really fun.

Here Are Some Screenshots

Here is the homepage:

Here is what a logged in user sees:

Wrapping Up

This was a fun little thing to build. I learnt quite a bit. There is definitely a place for Pocketbase in my off the cuff build.

My one gripe is deploying this database is not simple, not in the slightest. And no, Docker does not count - I do not use those dark arts.

The code

The code for shrinkat is available on GitHub. Fork it, make it your own, create pull requests...

https://github.com/meerkat-collective/shrinkat

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

Testing ↩

Rendering External Markdown in Astro

James 'Dante' Midzi — Wed, 07 Feb 2024 14:30:34 +0000

It seems like I'm always writing the same article... 😂

I enjoy Astro, it's a good framework, but there is one thing about it or rather the docs that irks me.

Astro is pitched as a content first framework with native markdown support. That's what they say. However, this isn't completely the case.

When it comes to markdown that is local to your project, Astro does absolute wonders with the rendering and parsing. Your problems arise when you have your markdown from an external source i.e. a CMS. The docs have been structured in such a way that they want you to use local markdown and Content Collections.

But sometimes, your markdown is somewhere else. What is one to do then?

Let's go on a journey shall we? ...

The Scenario

You use Hygraph as your CMS for your articles. You write your articles in markdown, and you can fetch them and all their data. What you want to do is have your articles rendered on your newly created Astro site.

The requirements for this task are as follows:

It needs to be one thing - a package or whatever - that you import and use.
You don't want to have to configure any additional things.

Before I give you the solutions that I think are best, I challenge you to find the solution within the Astro docs. I'll wait...

The Solution(s)

Markdown Component (deprecated)

I fought with this a while back when Astro was still in v1, and in those times, there was a package called @astrojs/markdown-components. That package has long since been deprecated, as such you won't be able to install it.

For reference, this is how that would look (those who read my Displaying Dev.to Post on Your Astro Site article will be familiar with this code.)

<!-- /articles/[slug].astro -->
---
import Markdown from "@astrojs/markdown-component";

export async function getStaticPaths() {
  const articles = await fetchArticles();

  return articles.map((article) => {
    return {
      params: { slug: article.slug },
      props: { article },
    };
  });
}

const {article} = Astro.props;
const {body_markdown}  = article;
---

<div>
    <Markdown content={body_markdown} />
</div>

A wise man once said, "If it ain't broke, don't fix it."

My site has been working well with this package, and because of that, I will not upgrade it to a higher version as I am not in the mood to do the dance again.

Now, let's head on to the stuff that works with newer versions of Astro.

Astro Pub

Repository: https://github.com/astro-community/md

Installation & Usage

npm install @astropub/md

<!-- /articles/[slug].astro -->
---
import Markdown from "@astrojs/markdown-component";

export async function getStaticPaths() {
    ...
}

const {article} = Astro.props;
const {body_markdown}  = article;
---

<div>
  <Markdown of={body_markdown} />
</div>

NOTE: Currently as of writing this, AstroPub requires astro@^3.0.0 to work smoothly.

Thoughts

If I had no choice, but to fight this battle again, this is the method I would choose.

Markdown-it

Repository: https://github.com/markdown-it/markdown-it

Installation & Usage

npm install markdown-it

<!-- /articles/[slug].astro -->
---
import markdownit from "markdown-it";
const md = markdownit();

export async function getStaticPaths() {
 ...
}

const {content_markdown} = Astro.props
---

<div>
    <Fragment set:html={md.render(content_markdown)} />
</div>

NOTE: Markdown-it also requires astro ^3.0.0

Thoughts

I don't like this method. I don't like it because:

I have to declare a variable to store markdown-it.
I have to use the set:html to render the content.
I have to additionally call the render function and then pass my content to it.

Astro Remote

Update: 29 February 2024

After submitting an issue, Nate added the install command.

Repository: https://github.com/natemoo-re/astro-remote

Installation & Usage

npm install astro-remote

<!-- /articles/[slug].astro -->
---
import {Markdown} from "astro-remote";

export async function getStaticPaths() {
 ...
}

const {content_markdown} = Astro.props
---

<div>
    <Markdown content={body_markdown} />
</div>

Thoughts

Astro Remote works very similarly to Astro Pub, and I like that about it.

The Thing About Marked

If you did accept my challenge and looked in the docs, you might have found this section:

Fetching Remote Markdown

The Astro docs recommend marked, but there's some things you have to be aware of with marked.

Marked Site: https://marked.js.org/

Thoughts

Marked informs you on their site that it does not sanitise your markup. Do with that information what you will.

Wrapping Up

Astro - a brilliant little thing. A bit more care with regard to this part of their framework/documentation would be cool. At least as much care as is given to other parts of the docs.

On a steam, whitep4nth3r went on a journey of trying to find this information on stream, her goal was to use things the 'Astro way. In the end, she went with the markdown-it approach.

The stream if you are curious. It's at 3hrs 57 minutes: https://www.twitch.tv/videos/1998429304?filter=archives&sort=time

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

Why SvelteKit Will Be My Goto Moving Forward

James 'Dante' Midzi — Mon, 04 Dec 2023 13:00:00 +0000

Allow me to tell you a tale, take you on a journey of how I switched how I work completely and I am probably not going back...

History

Anyone who knows me and has been following my journey is aware that my development focuses consist of:

Python
PHP (TYPO#3)
React/Next.js

What this has allowed me to do is be more efficient at picking the correct tool for the things I'll be trying to accomplish.

The Then

It's no secret that I have been an advocate of Next.js for some time. I even have a short series I did investigating how to integrate it with different Headless CMS. I have done explorations on the features I believed people should know in regards to Next. As such me and Next have been on very good terms for a while.

Breaking Up With Next

Put simply two words - App Router. I am not sure what the team at Vercel was in a hurry to get to, but they rushed this like I've never seen before. With me, if anything is pushed on me that hard, I form a natural aversion towards it; see one of my previous articles.

The Lie of `Stable`

While they may have made it stable now, when a lot of the features of the router were introduced they weren't ready; despite what they liked you to believe.

I could go on and on about the things that were reportedly stable, but that's not the point of the article. What I will do is tell you my main pain points.

Clear boundaries or lack thereof:

One of the things I liked about Next.js was that there were clear boundaries; your pages go here, your assets go here, API routes go here. That is all but gone, with the brunt of the things happening in the app folder.

Having to add pieces of text to change how your file/component works:

This sort of relates to my first point; the adding of 'use client' or 'use server' within a file does not sit well with me. There is something elegant about getStaticProps and getServerSideProps; you knew exactly where your data was coming from and how it would be rendered.

I will not even get started on the actions, sorry server actions.

Yes, I know I can still use Next.js the way I prefer, but the mob makes so much noise I would just rather maintain the project I have the way they are and just not deal with this new way.

The Now

After all the noise with Next.js I went on a journey to find something else that would meet my needs and not lie to me. My journey led me to several options; ones that did things better than Next.js, others not so much. Here is a very brief rundown:

Laravel

Considering I already use PHP in the form of TYPO3. I didn't go that way because I already got a sufficient dose of PHP. Also, I wouldn't randomly whip out TYPO3 for any 'ol project.

Vue/Nuxt

What put me off of Vue/Nuxt was mainly their templating engine. It just didn't sit well with me; the particular way the files in it are written. Also, something about its routing felt iffy.

Solid

This would have been going back to a version of React/Nextjs type framework. I wouldn't learn as much as I would like. Also things would still be abstracted from me, I was trying to avoid that.

Enter Svelte

Long ago, I tried to dabble in Svelte, but that was in my naive and hard-headed days and never took the time to understand what it required of me. Additionally, I tried to do it alongside another person and that did not go well. This time instead, I chose to knuckle down and get into what made Svelte Svelte; the changes in mindset I would need to undertake for this part of my journey.

Finding Synergy

I am not going to lie, the move to SvelteKit was not seamless. A lot of shift in mindset was required

To start the directory-based routing and wrapping my head around the +page.svelte naming convention was a bit confusing to get comfortable with. Afterwards; understanding how working with data was accomplished and what the +page.js and +page.server.js files did, and where I used each.

Understanding those things would aid me greatly in grasping how SvelteKit works and how I should approach my journey with it. With determination in my heart and a vantage point I was aimed at, I went to work.

And then, it clicked!

During the struggling, the change in mindset and embracing the power of native HTML and how SvelteKit leverages that, it clicked. Sticking to it paid off and my new home had been found and solidified.

What I Like About SvelteKit

Native HTML: It strips away the abstraction; no virtual DOM or anything of the kind. It's all just native HTML. Because of that your elements work the way they were intended.
Things are defined clearly:
1. +page.svelte: is your frontend stuff what you see when a page loads. Basically the crux of what a user sees when they visit your site/app.
2. +page.js / +page.server.js: this is where you load data to be displayed on your pages, and where your form actions run.
3. +layout.svelte: this applies styling and/or data to set of routes under the same directory.
4. +layout.js / +layout.server.js: allows you to specify data you want applied to an entire set of routes. In essence, the higher level of your page.server.js
Form actions: With it leveraging the native HTML means it takes advantage of all the functionality already present with forms. This means that nothing is hidden from you; what you can do in a form on a basic page, you can do with Sveltekit.
1. progressive enhancement: since we leverage the default functionality of forms, they will reload the page on a submit. Progressive enhancement gives us the ability to utilise the submit action without making the entire page reload.

Yes sure, Next.js might have now implemented some of this in their new version, but with SvelteKit it feels a lot more thought out and not rushed.

Wrapping Up

All in all, I actually thank Vercel for taking the approach they did. I would not have rediscovered Sveltekit otherwise. In addition, it helps in my goal of stripping away complexity that I talked about in these articles:

And that's the journey; How an advocate of Next.js was not impressed by the direction it took and moved to SvelteKit. Thereby finding a better way, a more honest way, a streamlined way of doing things. A way he is much happier with.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

File-Based vs. Directory-Based Routing: Understanding the Difference

James 'Dante' Midzi — Fri, 24 Nov 2023 18:57:41 +0000

I don't know who did it, and why everyone is suddenly confused by this. What you are calling file-based routing is not what you claim. I will gladly explain.

I am going to use Next.js as an example:

File Based

This is file-based routing:

src/
└── pages/
    ├── index.js
    ├── about.js
    └── contact.js

In the folder that defines your pages, if you are able to create a file in there and it automatically becomes a page (contact, about, services etc) that is file based routing.

File-based routing is a routing where the entry point to your routes is an index file. What that mean is the same way you can have a contact.jsx , you could also make a contact/index.js and these two would do exactly the same with little to no issues.

Frameworks that employ this:

Astro
Eleventy
Nextjs (with pages)s
Vue
Svelte

Directory Based

This is directory based routing

src/
└── app/
    ├── page.js
    ├── about/
    │   └── page.js
    └── contact/
        └── page.js

With this way, there is a defined method of creating new pages i.e a folder with the file name and a special file within it.

When using this way, anything that does not follow this pattern is not regarded a page.

Frameworks that use this

Nextjs (with app)
SvleteKit

A Table To Know What You Are Using

Ask	File-Based Routing	Directory-Based Routing
Can I make a file name as a route and it works?	Yes	No
Can I create a folder with an `index` file and that will become the page?	Yes	No
Do I have a special naming convention for pages?	No	Yes

With this clarification at hand, can you all stop confusing this? You can? Thank you.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

Typesafe - An Overused Term That Needs a Reality Check

James 'Dante' Midzi — Fri, 17 Nov 2023 18:04:42 +0000

This article is rant. Nothing more, nothing less. A rant.

Of all the internet hype words, this one really gets on my nerves. I didn't mind initially, but now - it is EVERYWHERE!!!

Every place I turn, be it articles or YouTube videos, someone is going on and on about typesafe this or typesafe that. I am at a point where it is virtually impossible for someone doing things related to web development to not mention typesafe.

I hear people saying typesafety makes the web better. It doesn't, not really. Because all the problems pointed to in favour of this still exist regardless. The actual problem isn't JavaScript or its lack of types, no - it is people not adequately learning JavaScript correctly and then blaming the language.

And It's not that I have an issue with typesafety, no. I use several strictly typed languages all the time. It's the fact that y'all won't shut up about it that's annoying me. I get it, move on, there's better things to do - things to be shipped.

We are at a point at which people are no longer writing good code, but typesafe code. Because that's the focus - typesafe code, not working code. I personally see this as a bad thing as we are moving further and further away from the fundamentals. The fundamentals. Remember those? the building blocks - the foundations - that meant you understood why things happen the way they do.

What Makes Me So Confident?

For a good 5 months, I watched a developer much more experienced than I and several of the people preaching this typesafety mantra build consistently without it. He built and took to production in JavaScript. How? Because he understood the core fundamentals of the language he was using.

Here is an example, say you were making an input component in React:

What you and your ilk would have done:

export default function Input({type, value}: {type: string, value:string, onChange: () => void}){
    ...
}

versus

What he would do:

export default function Input({type, value, onChange = () => {} ){
    ...
}

So if anything what you have succeeded in doing is making sure I do not conform to this typesafe noise.

If any one of you comes to this and says it's necessary, I'm reporting you for antagonising me.

Conclusion

If you noticed, I have a conscientious attempt to not mention the offending language itself specifically. Or the superset around whatever as they said when they were convincing you all to fall in line.

Here's the thing, if y'all didn't push this typesafe agenda so much I might have gotten with it. Right now, it's just too much and I am tired.

I promise you, if this current state of things was my introduction to development I would have stopped and pursued other ventures. Matter of fact, I am getting closer and closer to doing so.

You and your typesafety can go hang. I don't want it. I am going to be focusing on my open-source commitments.

LEARN THE LANGUAGE AND WHAT IT REQUIRES! STOP TRYING TO FIT IT TO WHAT YOU ARE USED TO!

Side Note

Another thing that's exacerbating me could possibly be that I just finished reading 1984 and the mind control in it is oddly indicative of all of this.

Yes. I have animosity towards your typesafety. I didn't before, I do now.

Automate Database Processes: Supabase Triggers

James 'Dante' Midzi — Tue, 17 Oct 2023 13:12:33 +0000

This article follows my Row Level Security one ...

As I was doing my tests I came across an issue whereby the user_data table wasn't created if there was an issue with connectivity. The upsert that I was trying to run wouldn't fire.

That got me thinking; the profiles table gets created when a user signs up, right? Something, somewhere is being automated to accomplish that. But how?

So, I went on another adventure...

I went searching in my project to see what had been done when I was following the guide that I was using as a starting point. What I discovered was really interesting. The starter that I used from the guide - User Management - created a function. What that function does is create a profiles table row and populates it with certain fields.

That looks like this:

begin
  insert into public.profiles (id, full_name, avatar_url)
  values (new.id, new.raw_user_meta_data->>'full_name', new.raw_user_meta_data->>'avatar_url');
  return new;
end;

With this knowledge, I went digging further and found out that functions are the first key to the puzzle I was trying to solve, the other being triggers.

What Are Triggers?

Triggers allow us to watch database events (insert, update, delete) and call a function whenever they occur, allowing us to automate functionality in our database while keeping our data in sync.

Automating Database Events

The automation that I need is comprised of three main aspects:

Relations
Functions
Triggers

Relations

Recall in the last article I said I wasn't going to delve into table relations. For the coming steps, relations are the lynch pin to a lot of what I want to accomplish.

Profiles Table

To start off, here's the relation between my profiles table and the auth.users one:

The auth.users table is from the authentication service I talked about in the prior article.

User Data Table

I could choose to link this table directly to the auth.users one, the same way the profiles one is - but that creates a separate relation. What I want is to relate the user_data one to the profiles one. In essence; an authenticated user has related profile data as well as user data.

So instead I have made the relation to the profiles one - that way everything is connected.

Functions

Triggers, from what I learnt, require functions. Naturally, I started there. The requirements for my function were straightforward:

when a row in the profiles table is created, create a row in the user_data table that is related by id

The settings for functions and triggers can be found in the Database area of my project.

Creating The Function

Let's go through the steps to create a function and the important aspects to take note of.

Return Type: Because we are making a function that a trigger will call, we have to set its return type to trigger

Definition: This is the core of what our function will be doing. It will be similar to the one before:

begin
    insert into public.user_data(id)
    values (new.id);

    return new;
end

Type of Security: It is necessary to change this to SECURITY DEFINER. This is to ensure that the trigger is run with the same privileges as a dashboard user. If left as SECURITY INVOKER, it would fail because the user trying to run does not have the necessary permissions.

Triggers

With the function ready, let's create the trigger that calls it.

Creating The Trigger

These are the important aspects to take note of when creating a trigger.

Table: We have to set the table that is to be watched for changes. In our case, as we discussed, it's the profiles table.
Events: Here we specify what kind of action will invoke our trigger. We want INSERT events.

Trigger Type: Next is to set when we want the trigger to run. We need it to run after because we require there to be a row in the profiles table to be created first. That way it is correctly related.
Orientation: As we want accompanying data for each user that is created, we set this to Row. Otherwise, it would only run once and fail on subsequent attempts.
Function to trigger: Lastly, we choose the function we need to be triggered.

Recapping

We have created a function that is run through a trigger, allowing us to have database actions and events automated whenever specific conditions are met. What it does is create a row in the user_data table whenever an insert event happens in the profiles table - all this being linked via the id

Last Update: 30 October 2023

Conclusion

As with most things in Supabase, this also wasn't that hard to get up and running. The beauty also is that I know exactly what is going on and what I have to do if I need to modify or add to it.

This adventure has been very fruitful. The fact that I can ensure that I can ensure that user data and info is created and related fills me with confidence.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

Fortify Your Database: Supabase's Row Level Security

James 'Dante' Midzi — Mon, 25 Sep 2023 14:13:31 +0000

Over the last few weeks, I have been working on stripping away complexity from my apps. In those adventures, I needed a database service that would enable me to handle authentication with them as well as store my app data.

This has to happen with me seeing what exactly is happening in my database. I don't want anything hidden or wrapped in something to form a sort of bridge. That meant no ORM, no third party auth service, etc...

I remembered Supabase was one that seemed interesting when I heard about it. The pathway was chosen...

One of the first things I had to do was figure out how Supabase Auth worked. This was surprisingly easier than I assumed it would be. That assumption - of auth being complicated - came from some issues I encountered with NextAuth when I was using it.

The only thing I would say is simpler is Clerk. But with Clerk, I would end up having to do some id gymnastics to get things to sync up - thereby defeating the stripping away of complexity.

Authentication Service

Supabase has a built in Authentication Service where users are added when they sign up for your app - this is done automatically when a new user is signed up. This makes it highly efficient to handle the auth logic of your project.

This feature of Supabase simplifies my life when it comes to signing up new users to my app.

The only issue is that these users who have signed up have no clearly defined permissions. If they got access to your database, they could do whatever they want, and we don't want that.

That is where Row Level Security comes in...

Row Level Security

On each table in your project, you can enable RLS and define who has access to do what on each table.

By default when you create a table in Supabase, RLS is activated. What it does is make it such that no-one can access the table. However, in most instances you would want specific users to access a table based on specific conditions.

Enter... Policies

Policies

Policies in Supabase are simply rules as to who can perform which action on a specified table. All policies are; is SQL logic that you attach to a Postgres table. There is no limit as to how many policies you can have on a table.

They - policies - can be accessed from the Authentication section of your project or the dropdown beside your table's name.

RLS is a Postgres primitive and can provide "defense in depth" to protect your data from malicious actors even when accessed through 3rd party tooling.

Supabase Docs

My Use Case

In one of my apps I have two main tables - a profiles table and a user_data one. I need it such that only a user whose id matches is able to view, add/modify information related to that user id. While I could write the SQL myself, Supabase simplifies this process with their UI.

Both my profiles and user_data table have 3 policies: select, update and insert

Recall I mentioned that policies are just logic? Well, the logic for my insert would look something like this:

CREATE POLICY "Users can insert their own profile" ON "public"."profiles"
AS PERMISSIVE FOR INSERT
TO public

WITH CHECK ((auth.uid() = id))

I allow insert actions on my profiles table, but only if the authentication id (from the authentication service) matches the id of the user. The connection of the auth id and user id dives into relations and I am not delving into that right now...

Conclusion

Supabase has been an absolute joy to work with. From creating a project, and making tables, to defining permissions on said tables. I also appreciate the straightforward approach to accessing your data from whatever frontend you decide to use.

Their docs are also decent which helps, and if not, the discord is an excellent place to ask for assistance.

Things... just... work...

My next exploration will be with the CLI and linking a local instance of Supabase with a hosted one.

In my goals of reducing complexity, Supabase succeeds in aiding me in accomplishing them.

Thank you for reading, let's connect!

Thank you for visiting this little corner of mine. Let's connect on Twitter, Discord and LinkedIn

Forem: James 'Dante' Midzi

Crypto Forge - Embracing Nuxt

Why Recreate Instead of Building Something New?

What I Learnt

API Routes For Data Fetching

Composables To Avoid Logic Duplication

What's Next?

Wrapping Up

Thank you for reading, let's connect!

Laravel is How Development Should Be

Laravel

Why Laravel Works?

Authentication and Authorisation

Database Relations

Appreciation

What About SvelteKit?

Wrapping Up

Thank you for reading, let's connect!

How Svelte 5 Made Me Understand Nuxt

The Changes

Runes - My Friction Point

Then Snippets...

Nuxt

Wrapping Up

Thank you for reading, let's connect!

You Don't Need The Flex

Block and Inline Elements

Block-Level Element

Inline-Level Element

Wrapping Up

Thank you for reading, let's connect!

Your Constant Quest For Productivity May Be Hurting You

Productivity

The More You Look for Productivity, the Less You Accomplish

Conclusion

Thank you for reading, let's connect!

Say Hello To shrinkat - A Tiny URL Shortener

Technologies I Used

What I Learnt

Here Are Some Screenshots

Wrapping Up

The code

https://github.com/meerkat-collective/shrinkat

Thank you for reading, let's connect!

Rendering External Markdown in Astro

The Scenario

The Solution(s)

Markdown Component (deprecated)

Now, let's head on to the stuff that works with newer versions of Astro.

Astro Pub

Installation & Usage

Thoughts

Markdown-it

Installation & Usage

Thoughts

Astro Remote

Installation & Usage

Thoughts

The Thing About Marked

Thoughts

Wrapping Up

Thank you for reading, let's connect!

Why SvelteKit Will Be My Goto Moving Forward

History

The Then

Breaking Up With Next

The Lie of Stable

The Now

Laravel

Vue/Nuxt

Solid

Enter Svelte

Finding Synergy

What I Like About SvelteKit

Wrapping Up

Thank you for reading, let's connect!

File-Based vs. Directory-Based Routing: Understanding the Difference

File Based

Directory Based

A Table To Know What You Are Using

The Lie of `Stable`