DEV Community: Andrew Luchuk

Simplify your frontend with Inertia JS

Andrew Luchuk — Wed, 30 Jul 2025 16:11:00 +0000

I sometimes want to integrate a frontend framework like Vue or React with Django.

There's only one major problem: maintainability. If I build the frontend of my application using a JavaScript framework, I will have to maintain multiple repositories and create APIs to facilitate communication between the frontend and the backend. Since I often develop projects on my own, setting up an API can be a prohibitive amount of extra work.

Fortunately there's a solution: Inertia JS. Inertia allows you to replace the view layer of your full stack framework with your frontend framework of choice.

What Inertia JS offers

Here are some other reasons you might want to try Inertia.

Simplicity: Inertia cuts out the complexity of an additional API layer between your backend and frontend. It also eliminates one of the more complex aspects of frontend frameworks in my experience: client-side routing.
A familiar full stack workflow: instead of communicating with the frontend using an API, Inertia uses the traditional approach: controllers and views.
Reduced development time: because you no longer need an API, you can reduce the amount of time needed to complete your application.
Simplified maintenance: the lack of an API layer means that maintaining your application is simpler due to the reduction in code dedicated to server-client communications.

You might think that by using the typical full stack approach, you would lose one of the core benefits of frontend frameworks: seamless transitions between pages. Surprisingly, Inertia is able to maintain seamless page-to-page transitions without sacrificing the traditional full stack structure.

Inertia is not a one-size fits all solution. If you intend to build an API for your backend for a reason other than purely communicating with the frontend, Inertia may be unnecessary. Similarly, if you do not need the seamless page-to-page transition user experience that frontend frameworks offer, Inertia probably isn't the best choice. If your site is primarily intended to present information to readers (like a CMS) and complex user interaction is not required, Inertia might introduce pointless complexity.

How to get started

That said, if Inertia would be useful for you, getting started with Inertia JS is pretty simple.

Inertia is designed for Laravel, so if you are building a Laravel application, then following the official setup documentation is the best way to get started.

On the other hand, setting up Inertia with Django is more complicated. The Inertia community has already built an adapter for Django, so you won't have to build your own tool kit to get Inertia and Django working together. Because Inertia is intended mainly for use with Laravel, the documentation for getting it set up with Django is
less descriptive and straightforward.

Fortunately, I have created a simple solution to get Inertia and Django up and running right away. I've created a GitHub repository template that you can use to scaffold Django with Inertia, React, and Tailwind CSS in just a few clicks. The first step is to go to the repository's GitHub page and click "Use this template". The template is configured so that Django should already have Inertia, React, and Tailwind CSS configured. If generating the project using a template would be helpful to you, please visit the repository to get started. I hope it helps you build your application in record time!

speratus / django-inertia-template-react

A template repository for bootstrapping a Django project with InertiaJS and React

Django Inertia Template (React)

This is a template repository for bootstrapping an application based on the following stack:

Usage

The first step for using this template is to create a new repository based on this template.

Once your new repository is created, you will likely want to take a number of customization steps:

Change the name of the application. There are two parts to this a. Rename the webapp directory to the name of your application b. Update python references to the webapp package to the name of your application. For example, in the settings.py file, you will need to change the ROOT_URLCONF property and WSGI_APPLICATION property so that they reference the new package name instead of webapp.
Rename the default app app to a more descriptive name. Similarly to step 1, you will also need to replace any python references to…

View on GitHub

I'm Starting a dev log

Andrew Luchuk — Wed, 04 Sep 2024 20:48:30 +0000

It's been a while since I posted anything on dev. I've been trying out new things and exploring a lot of software, but I haven't really thought that I had much insight into what I was working on. Maybe I'm selling myself short, but that's how I've felt.

Well, I'm trying something new. I'm starting a dev log.

Backstory

For a while now, I've been working on a game. I have enjoyed RTS games and 4X games for a while, but my biggest complaint with them is that they take forever to complete a single game. I'm talking 2+ hours to complete one game of Age of Empires, or 10+ hours for a single game of Sid Meier's Civilization. For me, this is a pretty huge time commitment.

So, a while ago, I began building my own 4X RTS game with the goal of having a single round being completable within a range of thirty minutes to an hour. For now, I'm calling the game Exaforge.

At the moment, there's not a ton to show for this game, but I've found that sharing my progress in projects regularly helps me to stay motivated and keep up with the project. And, that's the reason I'm starting this dev log. Again, I don't feel like I'm particularly insightful into the world of game development, but I'd like to share my journey in building this game, and if you're interested, you'll be able to follow along.

I plan to be releasing the log mainly on YouTube, but when I'm able, I'll probably post updates here as well.

What is Exaforge?

If this whole endeavor sounds appealing to you, keep reading and I'll tell you a bit more about the game.

Exaforge is set in an out of the way corner of the galaxy where a number of civilizations have developed relatively peacefully alongside each other. Right before the start of the game, however, an alien species called the Kryllan Collective has invaded the sector and conquered all the civilizations.

Despite their military prowess, they know they will not be able to rule the sector on their own, so they have setup a contest for the civilizations in the sector to determine which civilization is most worthy of ruling the others. They call this contest the exaforge. The winning civilization will be made the ruler of the sector.

But the Kryllan Collective has displayed some cracks in its veneer of undefeatable power, and the civilization that you control not only aspires to win the exaforge, but to escape the clutches of the Kryllan Collective and save its people from the Kryllan Collective's tyranny. There are three potential paths of escape: military unity with your neighboring civilizations, scientific study of advanced technical artifacts which may enable your people to transcend the bounds of space and time, and finally, cultural hegemony that overtakes the Kryllan Collective's own, leaving them open to having their own leaders replaced with your own.

Which path will you choose?

Where can I find updates?

If this project sounds interesting, you can follow me here on dev where I may post updates.

The best place to find updates, though will be on YouTube where I plan to post regularly. The channel is called Exaforge dev log.

Here's the first video in the dev log:

Subscribe on YouTube

If you have any questions, I'd love to answer them in the comments!

What Alternatives to VS Code do you use?

Andrew Luchuk — Mon, 29 Jan 2024 00:18:22 +0000

What, if any, alternatives to VS Code do you recommend? I think VS Code is a pretty great editor, but I have some objections to it which have been stacking up for some time now, and I'm looking for something that could potentially replace it.

If you have any suggestions, I'd love to hear them! Here are the things I'm currently prioritizing:

Fast (read "not an Electron app"), preferably relatively small memory/CPU footprint.
Not owned by Microsoft
Excellent out of the box language support for many mainstream languages, or a plugin ecosystem which has plugins to that add support for those languages
Smart refactoring tools (sometimes find and replace isn't good enough)
A strong plugin ecosystem. I like to make use of advanced debugging tools when they are available. Also, good plugins can go a long way toward quality of life features.

Alternative's I'm considering

I have tried or looked into a few alternatives, but I'm not sold on any of them yet.

Lapce. Seems solid, but the plugins often seem like they are out of date and there's no way to tell whether they are except by trying them out. Also, even though Rust has good language support, I've found some of the other language support to be lacking.
Emacs. I've been hearing about Emacs lately, so I'm considering looking into it in more depth, but I haven't yet. I guess have two main concerns with Emacs: 1) I'm not sure how many advanced features it offers because I'm not sure what it's plugin ecosystem is like, and 2) How good is Emacs' Windows support?
Zed. I'm really excited about this option as it seems very promising, but I only use Windows and Linux 😥
Vim/Neovim. These tools have been around for a long time and are pretty performant according to my understanding, but from my experience, they don't seem to have many features beyond syntax highlighting, and I'd prefer more advanced features.

I'd love to hear any suggestions from the community! Also, if you have any thoughts about the editors I've already tried, I'd love to hear those too!

Designing a Full-Featured Web Synthesizer

Andrew Luchuk — Mon, 05 Jun 2023 15:45:00 +0000

Recap

I ended my last post with a working prototype of a Rust and WebAssembly based synthesizer using wasm-pack to build the JavaScript wrappers. Now that the prototype is complete, it's time to start designing and building a more feature-complete synthesizer.

This update will be short compared with previous entries.

Architecture

Here is an overview of the architecture I plan to use for the synthesizer.

The entry point for the synthesizer will be a wrapper struct that starts the process of fully synthesizing the sound:

The wrapper starts by sending information about the note that should be playing to the oscillator bank which will use that information to generate the initial audio buffers. From there, the audio buffer will be passed along the chain of modifiers to apply filters and other transformations to the audio. Finally, the audio buffer will be returned to the wrapper to be passed back to the best available audio device.

Why this design?

I chose this design to keep the code base as flexible as possible. I eventually want to turn the synthesizer into a plugin for digital audio workstations. To achieve that goal, I want to make the design as generic as possible so that it will be easily compatible with many different plugin formats.

How I used wasm-pack to build a WebAssembly module for an AudioWorkletProcessor

Andrew Luchuk — Mon, 15 May 2023 15:45:00 +0000

If you haven't been following this series, I have been building a synthesizer in Rust and WebAssembly. The advantage of using WebAssembly is that I can take advantage of all of Rust's features while simultaneously avoiding the pitfalls of trying to use the operating system's complex libraries for playing audio.

My Last Solution Was Not Ideal

In the last post, I arrived at a working, but less than ideal solution for importing WebAssembly into an AudioWorkletProcessor. Even though I couldn't initially figure out how to import a WebAssembly module into a worklet using wasm-pack, the process of doing so without wasm-pack enabled me to identify a potential solution that uses wasm-pack.
The next step was trying to implement it.

A Better Idea

Once I understood the process of importing a WebAssembly module into a worklet, doing so using wasm-pack proved to be fairly simple. There are two general steps:

Compile the WebAssembly module using the wasm-pack web target. The web target creates JavaScript code that works without a bundler or Node.
Copy the JavaScript into the AudioWorkletProcessor file and adapt it to the context of AudioWorkletGlobalScope.

Explanation

Since the web target is meant to work without the need for a bundler, the resulting JvaScript code can be copied into the AudioWorkletProcessor file and will only require minor changes. This approach is currently the best option because the AudioWorkletGlobalScope lacks the features required to import WebAssembly modules.

Implementing the Solution

The first step is to build the Rust code with the web

wasm-pack build --target web

Once the code is compiled, I opened the JavaScript file named "_bg.js". This file contains the WebAssembly bindings generated by wasm-pack. I copied everything in this file and pasted into my AudioWorkletProcessor class. This is the only way to get the JavaScript bindings into the AudioWorkletGlobalScope.

Next, I copied the .wasm file to a location where the browser could load it using fetch(). At the top of my worklet file, I had the following code which I knew would need to be adjusted.

// processor.js

let wasm;

const cachedTextDecoder = new TextDecoder('utf-8', { ignoreBOM: true, fatal: true });

cachedTextDecoder.decode();

let cachedUint8Memory0 = null;

function getUint8Memory0() {
    if (cachedUint8Memory0 === null || cachedUint8Memory0.byteLength === 0) {
        cachedUint8Memory0 = new Uint8Array(wasm.memory.buffer);
    }
    return cachedUint8Memory0;
}

// wasm-pack generated code ...

export { initSync }
export default init;

class WebSynthProcessor extends AudioWorkletProcessor {
    // ...
}

I replaced this code with the following:

// processor.js

let wasm;

let cachedTextDecoder;

// decode call will be made later

let cachedUint8Memory0 = null;

function getUint8Memory0() {
    if (cachedUint8Memory0 === null || cachedUint8Memory0.byteLength === 0) {
        cachedUint8Memory0 = new Uint8Array(wasm.memory.buffer);
    }
    return cachedUint8Memory0;
}

// wasm-pack generated JavaScript

// Notice, I removed the exports.

class WebSynthProcessor extends AudioWorkletProcessor {
    // ...
}

An Instance of TextDecoder class needs to be available in the AudioWorkletGlobalScope, but the audio worklet scope does not allow the TextDecoder class's constructor to be used. I used the AudioWorkletProcessor's MessagePort to give the audio worklet a TextDecoder instance.

Setting Up the WebAssembly Module

In order to pass the WebAssembly module to the AudioWorkletProcessor, I knew I would need to call WebAssembly.compile() in the main thread and pass it to my audio processor. To do this, I needed to call both fetch() and WebAssembly.compileStreaming() like this:

// index.js

// We will need the worklet node later.
let node = new AudioWorkletNode(context, 'web-synth-proto');

WebAssembly.compileStreaming(fetch('/path/to/library.wasm')).then(module => {
    // Pass the module to the AudioWorkletProcessor
});

I originally did this in an async function so that I could use await to get the return value directly. Here, I'm using a callback with a promise because this pattern is more common.
Once I had a WebAssembly module instance, I passed it to the AudioWorkletProcessor using the MessagePort instance like this:

// index.js

WebAssembly.compileStreaming(fetch('/path/to/library.wasm')).then(module => {
    // Now that the module has been created, it can be passed to the processor.
    node.port.postMessage({type: 'init-wasm', wasmData: module});
});

Using the Module in the AudioWorkletProcessor

To use the WebAssembly module, it needed to be instantiated from inside the audio worklet thread. The first step in this process was to set up a message listener for for the MessagePort instance. I did this in the constructor of the AudioWorkletProcessor.

// processor.js

class WebSynthProcessor extends AudioWorkletProcessor {
    constructor(options) {
        super(options);


        this.port.onmessage = event => this.onmessage(event.data);

    }

    onmessage(data) {
        // Check to make sure the message we receive is the correct type.
        if (data.type === 'init-wasm') {                                 
            // Finish instantiating the WebAssembly module
        }
    }
}

Now that there is an onmessage listener for the MessagePort, the worklet can listen for the message sent by the main thread.

// processor.js

class WebSynthProcessor extends AudioWorkletProcessor {
    constructor(options) {
        super(options);

        this.port.onmessage = event => this.onmessage(event.data);

    }

    onmessage(data) {
        // Check to make sure the message we receive is the correct type.
        if (data.type === 'init-wasm') {                                 
            cachedTextDecoder = data.decoder;

            // Load returns a promise
            load(data.wasmData, getImports()).then(mod => {
                // Once the WebAssembly module has been instantiated, it needs to be finalized
                // so that it can be accessed later.
                finalizeInit(mod.instance, mod.module);
            });
        }
    }
}

Once the worklet receives the WebAssembly module from the main thread, it needs to call the load() function copied from the wasm-pack output so that the WebAssembly module can be properly instantiated. Finally, the audio processor thread needs to call the finalizeInit() function to ensure that it can continue to access the WebAssembly code.

Now that all the setup is complete, the audio thread can use the SineOsc struct by calling the JavaScript wrapper functions.
Here is how I setup the oscillator:

// processor.js

class WebSynthProcessor extends AudioWorkletProcessor {
    constructor(options) {
        super(options);

        this.port.onmessage = event => this.onmessage(event.data);

    }

    onmessage(data) {
        // Check to make sure the message we receive is the correct type.
        if (data.type === 'init-wasm') {                                 
            cachedTextDecoder = data.decoder;

            // Load returns a promise
            load(data.wasmData, getImports()).then(mod => {
                // Once the WebAssembly module has been instantiated, it needs to be finalized
                // so that it can be accessed later.
                finalizeInit(mod.instance, mod.module);

                // Create the oscillator instance.
                this.osc = SineOsc.new(sampleRate);
            });
        }
    }
}

Now that the audio thread has created an oscillator, that oscillator can be called to do the actual sound generation.

// processor.js

class WebSynthProcessor extends AudioWorkletProcessor {

    // ...

    process(inputs, outputs, parameters) {
        if (typeof this.osc !== 'undefined' && this.osc !== null) {
            // Get the first output channel.
            let output = outputs[0];

            output.forEach(channel => {
                // populate the channel's buffer with samples from the WebAssembly code.
                for (let i = 0; i < channel.length; i++) {
                    // Remember the first argument for the sample method is the pitch we want to 
                    // synthesize and the second argument is the volume.
                    let sample = this.osc.sample(440, 0.5);

                    channel[i] = sample;
                }
            });
        } else {
            console.log('wasm not instantiated yet');
        }
        return true;
    }
}

What Next?

At this point, I have demonstrated how to adapt wasm-pack's output so that it can be used in an AudioWorkletProcessor file. The next step is to start building out the features necessary for a usable synthesizer.

If you want to read more about this project, feel free to follow me or read my other posts in this series.

Introduction to the series:

Building a Browser-Based Synthesizer Using Rust and WebAssembly

Andrew Luchuk ・ Apr 19 '23

#rust #javascript #webassembly

Source code for this prototype:

speratus / web-synth-proto2

Web Synthesizer prototype 2

Websynth Prototype

This project is a proof of concept for using Rust to generate samples for a Web Audio API backed synthesizer.

You can read an introductiont to the project on dev.to.

Dependencies

To build this project you will need the following:

Building

To build the Rust components of this project, simply run

wasm-pack build --target web

See this post for details regarding how to integrate it into a web page.

Running

This project can be run using Visual Studio Code's "Live Server" extension. Simply install it, and follow the instructions to go live. Once you have the server running, navigate to the "www" directory to see the web page.

If you don't have Visual Studio Code, you should also be able to open index.html in the www directory in any modern web browser Although I haven't thoroughly tested this method, I don't think you will run…

View on GitHub

How to Use Rust Code in a JavaScript Worklet (Without wasm-pack)

Andrew Luchuk — Fri, 28 Apr 2023 16:00:00 +0000

I recently posted about how I have wanted to build a synthesizer and that I finally found the technologies I needed to make it happen.

The next step in my project was to build a prototype. The first step of this process was to generate a sine wave and have it be played through the speakers. Once I had achieved this first step, I could start building more complex features on this foundation.

The Setup

After taking a good look through the Web Audio API documentation, I decided that the best way for my synthesizer to output sound to the speakers was through the use of the AudioWorkletNode combined with an AudioWorkletProcessor. This combination of two nodes would allow me to generate audio in a background thread which could then be played through the speakers.

If I wanted to take a different approach, I would need to extend AudioNode and implement the audio generation by using much less documented features. Since I could find no documentation on extending AudioNode, I wanted to avoid extending it for as long as possible.

Implementing an Oscillator

Now I was ready to start writing Rust code. Almost all the documentation and tutorials I was able to find online recommend using wasm-pack.

Once I had followed the setup tutorials, I added the following code to my lib.rs file.

#[wasm_bindgen]
pub struct SineOsc {
    sample_rate: i32,
    cycler: i32,
}

#[wasm_bindgen]
impl SineOsc {
    pub fn sample(&mut self, pitch: i32, gain: f32) -> f32 {
        // This number is the base from which `sine` is calculated
        let seed: f32 = ((2.0 * std::f32::consts::PI) / (self.sample_rate / pitch) as f32) * self.cycler as f32;

        // Keeps track of the position within the wave
        self.cycler += 1;

        // Reset position if it gets too large
        if self.cycler > (self.sample_rate / pitch) {
            self.cycler = 0;
        }

        // Control the volume by multiplying gain by the sine.
        gain * seed.sin()
    }

    pub fn new(sample_rate: i32) -> Self {
        SineOsc { sample_rate: sample_rate, cycler: 0 }
    }
}

At this point, I had a basic oscillator. Passing a pitch (in hertz) and gain value between 0 and 1 to the sample() function would produce a single number which can be added to the audio buffer. Calling sample() repeatedly produces the sequence of numbers need to create an audible sine wave.

To build this project, I ran wasm-pack build which compiles the Rust code to a .wasm file and generates JavaScript bindings which can be used to call the Rust code. I integrated my newly generated .wasm file into my prototype JavaScript code. And that's when I started running into problems.

Roadblocks

In order to use an AudioWorkletNode, one must first set up a separate file with a class that extends the AudioWorkletProcessor interface in it. The AudioWorkletProcessor class must be defined in a separate file because the AudioWorkletProcessor interface only exists in the AudioWorkletGlobalScope which is an independent thread from the main thread of JavaScript execution. Because JavaScript does not support multithreading, any multi-threaded behavior must be achieved using the Web Workers API - which can only run a JavaScript file in the background instead of branching like typical multi-threaded applications.

At first, I tried to follow the tutorials' instructions for importing my newly minted WebAssembly package. But based on the console errors I kept getting, I quickly discovered that the AudioWorkletGlobalContext does not support importing modules.

Next, I tried to copy and paste the code from the JavaScript package directly into the AudioWorkletProcessor file and load it from there. But the AudioWorkletGlobalScope doesn't support fetch() which is required to read the .wasm file behind the scenes, so this solution didn't work either.

I then tried passing the imported JavaScript package from the main JavaScript file to the AudioWorkletProcessor via AudioWorkletNode's MessagePort instance. That didn't work because using the MessagePort relies on the objects being passed being copyable, and JavaScript functions are not copyable. I tried variant after variant of these solutions, and nothing I did could get it to work.

Eventually, I stumbled upon this GitHub issue:

Support using wasm-pack in Worklets (particularly AudioWorklet) #689

Smona posted on Jul 21, 2019

💡 Feature description

One of the key use cases for WebAssembly is audio processing. wasm-pack doesn't currently support AudioWorklets (purportedly the future of custom audio processing on the web) with any of its current --target options.

The web and no-modules targets get close, but error out during instantiation because the AudioWorklet context is lacking several browser APIs which the JS wrappers expect. This problem may extend to other Worker/Worklet contexts, but I've only attempted this with AudioWorklets.

💻 Basic example

my_processor.worklet.js

class MyProcessor extends AudioWorkletProcessor {
  constructor() {
    super()
    import("../pkg/audio").then(module => {
      this._wasm = module
    });
  }

  process(inputs, outputs, parameters) {
    if (!this._wasm) {
      return true
    }

    let output = outputs[0]
    this._wasm.exports.process(this._outPtr, this._size)
    for (let channel = 0; channel < output.length; ++channel) {
      output[channel].set(this._outBuf)
    }

    return true
  }
}

View on GitHub

Finally, I knew why I couldn't figure out how to make this work. The answer was simple, wasm-pack does not support Worklet compilation targets.

In my opinion, this is a significant deficiency in the Rust to WebAssembly toolchain because Worklets are some of the use cases which could most benefit from using WebAssembly. Worklets are used to do computation intensive tasks in the background, tasks which could further be optimized by offloading them to WebAssembly code that runs at near-native speeds.

This discovery was proved to be a major roadblock to getting a prototype working, but I wasn't out of ideas yet.

Solution

I did a few quick searches, and discovered that Rust actually already has a WebAssembly compilation target built in. Unfortunately, because the features that wasm-pack provides are so much more useful than what are available using only the built in compilation target, there are basically no tutorials on how to use Rust WebAssembly without using wasm-pack.

Nonetheless, after some digging, I found an old project that compiled Rust WebAssembly code without using wasm-pack and I adapted what I learned from that project to my use case.

The cost of this approach was that I would no longer have JavaScript bindings for my Rust structs because the JavaScript bindings are a feature provided by wasm-pack. So, I adapted my sampling function so that it no longer needed a struct and this is what I ended up with:

#[no_mangle]
pub extern "C" fn samplex(pitch: i32, gain: f32, sample_rate: i32, transport: i32) -> f32 {
    // Does the same thing as above, but statelessly
    let seed = ((2.0 * std::f32::consts::PI) / (sample_rate / pitch) as f32) * transport as f32;

    gain * seed.sin()
}

from here, all I had to do was run

cargo build --target wasm32-unknown-unknown

and it would produce a .wasm file ready for use.

I learned how to pass the WebAssembly module to a Worklet while reading the Mozilla Developer Network article on the WebAssembly.compile() function. Armed with that knowledge, this is what my two JavaScript files ended up looking like:

// index.js

 let startBtn = document.getElementById('start-sound');

  async function setup() {
    // Load and compile our WebAssembly module
    const bin = await WebAssembly.compileStreaming(await fetch('/wasm_demo.wasm'));

    let context =  new AudioContext();

    // Add our processor to the Worklet
    await context.audioWorklet.addModule('processor.js');
    let node = new AudioWorkletNode(context, 'web-synth-proto');
    node.port.postMessage({type: 'init-wasm', wasmData: bin});

    // Connect to the speakers
    node.connect(context.destination);

    // Make sure sound can be stopped to prevent it from getting annoying
    let stopBtn = document.getElementById('stop-sound');
    stopBtn.addEventListener('click', () => {
      context.close();
    });
  }

  // User must click to start sound
  startBtn.addEventListener('click', () => {
    setup();
  });

// processor.js

class WebSynthProcessor extends AudioWorkletProcessor {

    constructor(options) {
        super(options);
        this.cycler = 0;
        this.transport = 0;

        // Setup `MessagePort` so we can receive WebAssembly 
        // module from the main thread
        this.port.onmessage = event => this.onmessage(event.data);
        console.log(sampleRate);
    }

    onmessage(data) {
        // Receive WebAssembly module from main thread
        if (data.type === 'init-wasm') {
            // Declare this as an async function so we can use `await` keyword
            const instance = async () => {
                try {
                    // We need to instantiate the module to use it
                    let mod = await WebAssembly.instantiate(data.wasmData, {});
                    this._wasm = mod;

                } catch(e) {
                    console.log("Caught error in instantiating wasm", e);
                }
            }

            // Call the setup function            
            instance();
        }
    }

    process(inputs, outputs, parameters) {
        if (typeof this._wasm !== 'undefined' && this._wasm !== null) {
            let output = outputs[0];

            output.forEach(channel => {
                for (let i = 0; i < channel.length; i++) {
                    let pitch = 880;

                    // Call our WebAssembly function
                    let sample = this._wasm.exports.samplex(pitch, 0.3, sampleRate, this.transport);

                    // Add Sample to audio buffer
                    channel[i] = sample;

                    this.transport += 1;

                    let resetPoint = Math.ceil(sampleRate / pitch);

                    if (this.transport > this.resetPoint) {
                        this.transport = 0;
                    }
                }
            });

        } else {
            console.log('wasm not instantiated yet');
        }

        // Must return `true` to continue processing audio
        return true;
    }

} 

// register our processor with the `AudioWorkletGlobalContext`
registerProcessor('web-synth-proto', WebSynthProcessor);

Time for Improvement

While this new solution worked, it wasn't ideal because there was no good way for me to track state in the Rust code, which I knew would prove to be problematic once I started making my synthesizer more advanced.

But, as I worked on redesigning my code to work without the need for wasm-pack, the puzzle pieces started to fall into place, and I began to see that, despite its flaws, I might still be able to use wasm-pack for this web-based synthesizer.

All it would take is a little adapting...

In my next article, I will describe my attempt to reincorporate wasm-pack into my synthesizer project.

Introduction to this project:

Building a Browser-Based Synthesizer Using Rust and WebAssembly

Andrew Luchuk ・ Apr 19 '23

#rust #javascript #webassembly

Building a Browser-Based Synthesizer Using Rust and WebAssembly

Andrew Luchuk — Wed, 19 Apr 2023 13:00:00 +0000

Ever since I learned the math behind sine waves, I've been fascinated by the idea of building my own synthesizer, however rudimentary it might turn out to be.

For those who don't know what a synthesizer is, it's a configurable software musical instrument which can generate periodic waves which can mimic the sounds of existing instruments, or create sounds that would be impossible to reproduce on any physical instrument.

I loved the idea of directly applying mathematics to a problem and having it translate into a meaningful phenomenon. Then my imagination would run wild with all the things that I might be able to do with a self-made synthesizer.

In practice, I can probably achieve anything I could imagine doing with a self-built synthesizer using a Digital Audio Workstation combined with a good synthesizer plugin, but that never stopped me from imagining.

Project Goals

I've wanted to build a larger Rust project for a while now, and I realized that this would be a great language in which to build the synthesizer.

Rust performs at a near-native level and doesn't have a garbage collector, making it ideal for applications that have to perform large numbers of operations per second.

Depending on the file format and the desired audio quality, a synthesizer needs to generate between 44,100 and 192,000 points of data per second at a bare minimum, so clearly performance is going to matter in any medium to large synthesizer.

Blockers

I had an idea and a language in which to build that idea. So, I began researching systems level APIs for sending an audio signal to a device's speakers. And then, almost immediately, I decided I didn't want to use system level APIs for playing audio.

You see, I develop mainly on Windows, so after taking a rudimentary glance at the documentation for sending a signal to audio output devices on Windows, I began to realize that developing a solution for sending my newly generated audio signal to the speakers was going to be quite a bit harder than I had anticipated.

This was in the days before ChatGPT and its power to almost immediately connect the dots for such sophisticated problems. As a result, I decided building a Synthesizer would be more trouble than I really wanted to put into it.

Enter The Web Audio API

A few weeks ago, I was reading the Mozilla Developer Network docs and stumbled upon the Web Audio API. Then, I had a flash of inspiration.

I knew Rust could compile to WebAssembly which is essentially a browser-based pseudo machine language that can have serious performance benefits over vanilla JavaScript.

Now that I knew there was an API for playing audio in JavaScript, and even some APIs for generating audio from JavaScript, all I had to do was build in Rust, compile to WebAssembly, and utilize the Web Audio API to do the hard work of sending the audio signal to the device speakers. This was the solution I was looking for to get my synthesizer started.

Easier Said Than Done

But, as often happens, I'm only two weeks into this project and have already encountered hurdles I could not have foreseen. These problems have forced me to push the existing solutions for both Rust-based WebAssembly and the Web Audio API to their limits to find a solution.

I've had to abandon my starting codebase and restart several times just to find a solution for using WebAssembly in the context I needed it. But I have found a solution that works and is generic enough to be applicable to a wide variety of situations. In so doing, I have greatly increased my understanding of WebAssembly as a technology, and hopefully, in writing this, I will be able to expand your understanding too.

In my next post, I will describe how I discovered a severe flaw in the current Rust toolchain for building WebAssembly and my current, rudimentary solution to compensate for that flaw.

What I Learned by Deploying a Discord Bot with Kubernetes

Andrew Luchuk — Tue, 28 Feb 2023 03:12:03 +0000

If you haven't seen my entry in the Linode + Dev Hackathon, I recently built a Discord bot and deployed it on Linode's cloud using Kubernetes. As I was unfamiliar with Kubernetes, I learned quite a lot from the process of deploying a working application with it.

I thought I would share some of my thoughts from the experience as well as summarize the concepts that I learned to help anybody else interested in learning how to use Kubernetes.

Kubernetes Features I like

Kubernetes offers several key features that I found very attractive formy project such as:

Automatic rebooting of failed containers.
Container replication, meaning that if one instance of a container goes down, traffic is automatically redirected to a healthy container, preventing service interruptions.
No downtime rollouts and rollbacks --- because containers can be replicated, updates and rollbacks can be deployed in such a way that the updates result in zero downtime for end users.
Finally, because containers can be distributed across multiple cloud machines, if one machine goes down, Kubernetes, can redirect all the web traffic to other healthy machines, again preventing disruptions.

Overall thoughts on using Kubernetes

Overall, I really enjoyed using Kubernetes. Unlike most of the projects I have hosted on the cloud where I have to set up a cloud instance, log in, run a bunch of commands to configure it correctly, then setup a bunch of DNS records, change firewall rules, etc., using Kubernetes was really simple: create a cluster, run kubectl apply -f several times,
and my project was live.

Getting to the point where I knew exactly which commands to run and how to setup my object files was a more difficult journey, but overall it was worth the time put into it.

The other downside of running a project with Kubernetes is the cost. Running a Kubernetes cluster with the recommended number of machines in it is more expensive than I would typically prefer for a project, but if high availability is a priority, then a Kubernetes cluster is probably an investment that's worth the money.

Concepts I Learned

Pod

A Pod is the core unit of work in a Kubernetes environment. Pods the code you deployed in containers.

Node

Nodes represent the underlying hardware on which pods run. Pods are not necessarily tied to specific nodes and nodes do not need to be limited to running only one pod (or one single type of pod).

It's important to separate the concept of nodes from the concept of code execution in Kubernetes because the nodes themselves aren't running your code, rather the pods run your code.

Service

Services group pods together under a single IP. Services are a little bit like load balancers. They take distributed pods and combine them under a single umbrella. Services are not one-to-one analogous to load balancers, though because services can group together different components under a single IP.

For example, one could configure a microservice Pod and a website
hosting Pod to be combined in a single service. Two different types of execution, one IP address for both types.

Configmap

Config maps are the most unfamiliar concept I had to deal with when deploying my Discord Bot. They way I used config maps, they were kind of like if I had a tiny redis database attached to a Pod that was pretending to be a file --- a little complicated, I know.

Basically, in the pod, the configmap functions as a file. In the mind of the Kubernetes cluster, however, the config map is more like a bunch of key-value pairs.

Secret

Finally, the last Kubernetes concept I learned was the concept of
Secrets. In my environment, the secrets I used functioned very similarly to environment variables, but with added security features to prevent them from being read directly.

Would I recommend Kubernetes for your project?

Possibly. If you want to learn Kubernetes, or want to create a project which is intended to have as little downtime as possible, then yes I would heartily recommend using a Kubernetes cluster. Otherwise, if you are planning on hosting a small project for friends and family that you don't intend to leave running for a long time, then Kubernetes is probably overkill.

That said, I quite enjoyed the process of learning how to use and deploy a Kubernetes cluster and hope to help out anyone with a similar interest. I'm happy to answer any questions you might have below.

Kubernetes Documentation:

https://kubernetes.io/docs/home/

My entry in the Linode + Dev hackathon:

Meet Casper, the Astral Librarian ✨, A Discord Bot for Searching the Web

Andrew Luchuk ・ Feb 21 '23

#llm #claude #gemini #discuss

Meet Casper, the Astral Librarian ✨, A Discord Bot for Searching the Web

Andrew Luchuk — Tue, 21 Feb 2023 00:26:34 +0000

What I built

Casper, the Astral Librarian, is a Discord bot for searching the internet. Unlike other web searching discord bots, Casper does not restrict search results to a single search engine, instead returning results from a whole host of search engines.

Out of the box, Casper supports a number of features provided by the underlying search engine, SearXNG, including searching specific engines by formatting queries like this:

!<ENGINE_NAME> my search

For example,

!reddit nvidia 3000 series review

These features are described in greater detail in the SearXNG documentation

Here is a list of some of the search engines Casper currently supports:

google
bing
duckduckgo
qwant
reddit
stackoverflow
github
bitbucket
gitlab
docker hub
deviant art
imdb
pypi
npm
packagist
rubygems
yahoo
vimeo
youtube
twitter
wolfram alpha

In addition to these features, I plan to add some exciting features like allowing users to add their own search engines to Casper as well as user and channel based customization options.

If things go really well, I may also port Casper to other messaging platforms too!

Category Submission:

Wacky Wildcards
Integration Innovators

App Link

Discord invite link:
Invite Casper to your Server

Source code:
https://github.com/speratus/indexor-discord-bot

Screenshots

Here is a series of screenshots demonstrating Casper in Use:

Screenshots of Kubernetes config

List of nodes in Kubernetes cluster according to Kubernetes control panel (identifying information has been removed):

Same list, but showing the nodes running as instances running in Linode's control panel (identifying information has been removed):

Description

Casper is a Discord bot built with Python, discord.py, Docker, Kubernetes, and SearXNG.. The main goal of Casper is to allow users to search for web results directly from within Discord. Secondary goals include a high degree of flexibility, enabling users to search using their preferred search engine, and, to that end, supporting the widest array of search engines possible.

Finally, Casper allows users to share search results with each other, enabling them to establish trust and common sources of information as well as a discussion of the quality of sources.

There are several major components of Casper:

The bot itself
The search library containing the main search features. This library is what will enable Casper to be ported to other messaging platforms
The SearXNG Instance, powering web-wide searches

Link to Source Code

Main Casper source code:

speratus / indexor-discord-bot

A Discord Bot that searches everywhere on the internet

Casper (Formerly, Indexor)

Casper is a Discord bot that searches the web for you. Casper gets the best results from around the web and returns them directly to your Discord channel.

Unlike other web searching Discord bots, Casper is not restricted to getting results from a single search engine. Instead Casper is powered by the metasearch engine SearXNG to get results from many sources simultaneously.

In addition to Casper's current features, there are many exciting features planned for future updates, including:

Multiple pages of results
Results caching for faster response times
Support for getting results from specific search engines
User-Added search engines (Anything powered by the OpenSearch standard)
Server and User based custom configurations
Direct messaging the bot to get answers from anywhere on the web
Support for other message platforms such as Slack, Telegram, Matrix.org, and others.

Installation

The easiest way to get Access to Casper is to follow…

View on GitHub

Search functionality core library:

speratus / indexor-core

Supporting library for the Casper Discord bot

Indexor Core

This library provides the core searching functionality required by the Casper discord bot. At the moment, its features are fairly minimal, but the majority of Casper's planned features will be added here.

Examples of which features will be supported by this library:

Results caching
Improved support for getting results from specific search engines
User based customization options
User-added search engines

Installation

You can install indexor_core by running the following command:

pip install git+https://github.com/speratus/indexor-core.git#egg=indexor_core

Usage

Here is a basic usage example:

from indexor_core.config import Config
from indexor_core.searcher import search

search_xng_instance_url = 'https://example.com'

c = Config(engine_url=search_xng_instance_url)

results = search('hello world', c)

View on GitHub

The Indexor core library contains the primary search feature and will contain other planned features such as results caching and user based searching preferences.

Permissive License

MIT License

Background

I came up with the idea for Casper on a whim, thinking how interesting it would be to get search results directly in a Discord server.

I also saw this as an opportunity learn a couple of technologies I had been interested in, but had never created any projects with: Docker and Kubernetes.

How I built it

I deployed Casper on top of Linode's Kubernetes engine. I chose Linode Kubernetes engine for this project so that it would be easy to scale, update and rollback as necessary. This also lets me exercise my interest in learning Kubernetes and deploying an application using it.

To deploy Casper on Linode's Kubernetes engine, I had to overcome several obstacles:

Packaging the source code as a Docker image to which I could transfer necessary project information while keeping it out of the source code for the sake of privacy

docker build -t casper:1.0.2

Creating a deployment for the SearXNG instances that had the configuration required to be compatible with the Casper source code

apiVersion: apps/v1
kind: Deployment
metadata:
  name: searxng-deploy
spec:
  replicas: ...
  selector:
    matchLabels:
      app: searxng
  template:
    metadata:
      labels:
        app: searxng
    spec:
      containers:
        - name: searxng
          image: searxng/searxng
          env:
            - name: INSTANCE_NAME
              value: 'casper-engine'
            - name: BASE_URL
              value: 'http://n.n.n.n'
          volumeMounts:
            - name: settings
              mountPath: /etc/searxng/settings.yml
              subPath: settings.yml
      volumes:
        - name: settings
          configMap:
            name: searxng-settings

Creating a Kubernetes service for the SearXNG instances so that they could be load balanced as well as simultaneously enabling the Casper source to communicate with the instances and preventing the SearXNG instances from being accessible outside of the Kubernetes Cluster

apiVersion: v1
kind: Service
metadata:
  name: lb-searxng
spec:
  selector:
    app: searxng
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 8080

Creating a configmap for the SearXNG instance that could be read as the settings.yml file and which also includes the required values to enable Casper to function.

kubectl create configmap searxng-settings --from-file=PATH/TO/FILE/searxng/settings.yml

Creating a Kubernetes secret to store the Discord bot's token without exposing it to outside access.

kubectl create secret generic ...

Creating a deployment for the bot itself which drew from the necessary secrets and had the proper environment variables to communicate with the SearXNG instances.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: casper-deploy
spec:
  replicas: ...
  selector:
    matchLabels:
      app: casper
  template:
    metadata:
      labels:
        app: casper
    spec:
      containers:
        - name: casper-bot
          image: speratus/casper:1.0.2
          env:
            - name: DISCORD_TOKEN
              valueFrom:
                secretKeyRef:
                  name: ...
                  key: ...
            - name: ENGINE_URL
              value: 'http://n.n.n.n'

Once I had tested out each of these steps in detail and identified working settings for each component, deployment was as easy as running a few commands. Once that was done, Casper was live with no headaches.

NOTE: In these samples, I replaced IP address with n to indicate that anybody wishing to follow along should use their own information instead. I also used ... to indicate regular values that need to be replaced with the information specific to your context as well.

Additional Resources/Info

SearXNG's documentation for creating and running an instance:
https://docs.searxng.org/admin/index.html

SearXNG Source:

searxng / searxng

SearXNG is a free internet metasearch engine which aggregates results from various search services and databases. Users are neither tracked nor profiled.

SearXNG is a metasearch engine. Users are neither tracked nor profiled.

Setup

To install SearXNG, see Installation guide.

To fine-tune SearXNG, see Configuration guide.

Further information on how-to can be found here.

Connect

If you have questions or want to connect with others in the community, we have two official channels:

#searxng:matrix.org
#searxng @ libera.chat (bridged to Matrix)

Contributing

See CONTRIBUTING for more details.

License

This project is licensed under the GNU Affero General Public License (AGPL-3.0). See LICENSE for more details.

View on GitHub

Planned Features

Multiple pages of results
Results caching for faster response times
Improved support for getting results from specific search engines
User-added search engines (Any sites supporting the OpenSearch standard)
Server and User based settings
Direct messaging Casper to get results in addition to using the slash command
Support for other messaging platforms such as Slack, Telegram, Matrix.org, and others.

Unsupported features

Currently, Casper does not support SearXNG's special queries features.

Making Our ⚛ Components Reusable♻️

Andrew Luchuk — Sat, 01 Aug 2020 20:30:54 +0000

React’s value add for frontend developers is that it makes single page web app development much easier by combining the well understood syntax of HTML with the scripting capabilities of JavaScript in an intuitive and convenient way.

One of React’s most important features that is easy for new developers to overlook is component reusability. We need to be building React components that are designed to be reused throughout the UI.

I get it though, it can be hard to see how a component can be reused. I hope to be able to pass on some tips that I’ve learned during my journey into React to help keep components reusable.

Start with the planning stage

In the last post in the series, I broke down a series of wireframes into a component hierarchy. Detailed planning is the first step to identifying reusable components.

When looking at a mockup or a wireframe, it’s critical to identify parts of the UI which are identical to other parts of the UI or are extremely similar but with minor variations.

Aristotle and UI

The Greek philosopher Aristotle formalized thought regarding an object’s essence. According to Aristotle, an object’s essence is the set of characteristics that make the object what it is and without which it would not be what it is.

For example, we could say that the essence of a button is its clickability. All buttons are clickable and perform some action when clicked. Similarly, if a part of a UI is never clickable, then we can say that it is not a button.

In contrast to an object’s essence, Aristotle held that objects also have “accidental” characteristics. Basically what Aristotle meant by the term “accidental” is “not essential”. That is, an accidental characteristic is something which can be removed from an object without making the object something other than what it is.

In our example, a button’s color, shape, or text would all be accidental characteristics because they can all be changed without making the button not a button. A red button is still a button.

In Aristotle’s thought, an “accidental” characteristic is not one which occurs by chance, but rather a characteristic which can be altered without changing the object into a different kind of object.

How does all this relate to reusability ♻️?

When identifying reusable components, first look for all the parts of the UI which share essential characteristics. Identify UI elements which are accidental characteristics of the components to which they belong, so that you can see all the features that it shares in common with similar components.

Reusable components share the same set of essential characteristics in every part of the UI, even though some of their accidental characteristics might change between parts of the UI.

Building Reusable components

If you haven’t already, create a new react app for our forum project.

npx create-react-app

When it’s finished, navigate to the new project and install missing dependencies:

yarn add @mdi/js @mdi/react bulma rbx \
  react-router react-router-dom \ 
  graphql-request redux react-redux \ 
  immer easy-redux-reducers

Here’s a brief explanation of the dependencies

Bulma, rbx: npm packages to use the bulma framework with react
@mdi/js, @mdi/react: packages to use the material design icon font with react
react-router, react-router-dom: allows us to have multiple pages in one react app.
graphql-request: allows us to easily query our GraphQL backend.
redux, react-redux: helps us manage complex application state
immer: allows us to maintain immutability but also to modify state objects directly.
easy-redux-reducers: a tiny package to eliminate the need for writing switch statements in redux reducers.

Once those are finished installing, we’re ready to begin building reusable components

Delete unnecessary files

Remove the files index.css, app.css, logo.svg, favicon.ico and all the references to those files. We won’t need them and they’ll just get in the way.

Creating our first reusable component

Let’s tackle the most reused component in our component hierarchy: Field. If you look back at the last post, you’ll see that this field is probably the most reused component in the whole hierarchy.

For clarity, I’m calling Field FormField in the actual code to reduce ambiguity since there is a field component in Bulma.

Here’s my code for FormField:

// src/components/FormField.js

import React from 'react';

import {Field, Label, Control, Input} from 'rbx';

const FormField = props => {
    return <Field>
        <Label>{props.name}:</Label>
        <Control>
            <Input 
                type="text" 
                placeholder={props.name} 
                value={props.value}
                onChange={props.onChange}
            />
        </Control>
    </Field>
};

export default FormField;

The Field, Label, Control, and Input components are all components from rbx required to use Bulma styles and make sure that they stay consistent.

Notice that I have not actually passed any values (other than the “text” property) to any of the components. This is key to keeping a component reusable. We need to make sure it behaves predictably in whatever context we use it.

FormField does not maintain any state, but rather expects an onChange prop so that it’s parent component can keep track of state management. Since FormField is a functional component, getting the value of the Input component would have been challenging.

The `TopicTitle` component

Let’s look at another example. Here’s my code for the TopicTitle component:

import React from 'react';

import { withRouter } from 'react-router-dom';
import { Box, Title } from 'rbx';

const TopicTitle = props => {
    return <Box onClick={()=> props.history.push({pathname: props.to})}>
        <Title>{ props.text }</Title>
    </Box>
}

export default withRouter(TopicTitle);

This component displays the title of a topic and also acts as a link to the topic itself. Again, by using props, I can make this component highly reusable with minimal effort. I wrapped the whole component in react-router’s withRouter() function to enable it to properly integrate with the browser’s history API.

Go build some reusable♻️ components

I hope I have been able to give you some tips regarding how to make React components reusable. As always, feel free to ask me questions in the comments.

The code for this part of the series is available on GitHub

speratus / miniforum-frontend

The React frontend for the Miniforum repo

This project was bootstrapped with Create React App.

Available Scripts

In the project directory, you can run:

`yarn start`

Runs the app in the development mode.
Open http://localhost:3000 to view it in the browser.

The page will reload if you make edits.
You will also see any lint errors in the console.

`yarn test`

Launches the test runner in the interactive watch mode.
See the section about running tests for more information.

`yarn build`

Builds the app for production to the build folder.
It correctly bundles React in production mode and optimizes the build for the best performance.

The build is minified and the filenames include the hashes.
Your app is ready to be deployed!

See the section about deployment for more information.

`yarn eject`

Note: this is a one-way operation. Once you eject, you can’t go back!

If you aren’t satisfied with the build tool and configuration…

View on GitHub

Django Intro From a Rails Perspective

Andrew Luchuk — Sat, 25 Jul 2020 19:12:58 +0000

If you’re a new developer, you may have started off your web development journey by learning Ruby on Rails. Rails is a great starting point, but maybe you now want to expand your horizons a bit and learn a new framework.

Django is a good choice of a web framework, to extend your knowledge with. It’s well established and well supported with lots of resources out there to help you learn. Here’s some of the basics that you’ll need to know before getting started.

Django is written in Python which makes it a particularly excellent choice if you want to integrate an application with data science tools.

Top Django Challenges

There are a few things that make the Django framework harder to work with than Rails. In some ways, these make it more difficult to use for beginners, though in my opinion, they are ultimately not much more challenging.

1. Django uses different names for things

Rails is an MVC framework. Models, Views, and Controllers are clearly defined in Rails. Django, on the other hand, is not explicitly an MVC framework, although you can change some of the terms around to get something fairly similar to MVC.

So here’s a translation of each of the major parts of MVC into Django’s terminology:

Rails	Django
Model	Model
View	Template
Controller	View

You can see why Django is confusing now. What Rails calls a controller, Django calls a view. Django views perform roughly the same function as Rails controller actions, though. Each Django view processes a request and returns a response. There are technical differences between how Rails controller actions work and Django views, but the analogy is pretty solid.

2. Routing is more verbose

Rails has a nice little DSL for defining routes to controller actions. Django developers, however, usually have to specify how each route maps to each view.

A few years ago, Django developers had to use regular expressions to describe url paths. If you’ve ever had to work with regular expressions you didn’t understand, you can imagine how frustrating that could be.

Fortunately, these days Django has become more user-friendly and has made crafting url paths somewhat easier (but still not as convenient as Rails).

Part of the reason Django’s routing is more difficult to understand is that Django does not follow Rails’ convention over configuration mentality. Rails expects developers to follow standard conventions, allowing rails to do some of the hard work for the developer.

Top Django Benefits

Don’t let Django’s greater difficulty deter you from trying it out, though. Django has some huge advantages over Rails in other areas.

1. No More Migrations

Rails developers have to run highly specific commands and write some boilerplate code to tell Rails how to change tables in the site’s database. Django developers, however, don’t often have to worry about writing migrations because Django takes care of migrations under the hood.

Django models are written entirely in python code. When Django detects that a model has been changed, it’ll warn the developer that it’s time to make migrations. Actually creating the migrations is a super simple process: just run a single command:

python manage.py makemigrations

Django will then figure out what’s changed in the model and update the schema accordingly.

As a side note, the fact that Django models are written in Python is something I really appreciate because it means if I ever have questions about the current schema, I don’t have to open up a schema file and sift through unintuitive lists of ruby commands. Instead, I just open up the model I want to know about and the answer is right there.

2. Out of the box support for Authentication and Authorization

If you’ve ever had to deal with authentication in Rails, you know that it can be super confusing the first couple of times. (What is BCrypt and how do I get it to hash the password correctly, again? And once I have gotten all that sorted out, how exactly do I keep track of a user’s authentication status across requests?)

Django comes with an authentication system right out of the box. Django has a robust User model that already takes care of password hashing and authentication. Django even gives you views and templates to handle user registration, logging in, password resets, etc.

Django also has an authorization system right out of the box to help developers control which users have access to which resources. Compared to Rails, this is a huge advantage, because in my opinion an application framework should have expectations regarding how authorization should work.

In fact, Rails’ lack of an authorization is such a problem, that I actually wrote my own authorization library which is available on RubyGems.

speratus / rails-action-authorization

An authorization system for Ruby on Rails

There are other solutions for authorization for Rails, but I designed mine to be extremely lightweight.

3. Built in Administration tools

Django has a built in administration site which developers can use to interact directly with the data in the database, allowing developers to create, update, and delete objects with ease. Granted, the Rails console allows developers to do many of the same things, but the fact that there is a pre-built dedicated site for administration is a huge advantage if a non-programmer team member needs to make some adjustments.

Rails or Django, Which is Better?

In my opinion, it really depends on the context to decide which is better.

If you need to build an app in a really short time, rails might be the better option, as it is often quicker to build an app in Rails than in Django.

On the other hand, if you need more flexibility than a RESTful application, Django might be a better choice as it doesn’t make any assumptions about what you’re building.

If (for some reason) you need your application to run on a Windows server, then Django is probably a better choice. Rails and Windows do not play nicely together in my experience.

But if all you need is a small application that won’t have a lot of users and does one main job, rails could be sufficient. It all depends on what you need.

I hope you’ve found this guide useful, and I’d be happy to try to answer any questions you might have in the comments.

Wireframes and Component Hierarchy

Andrew Luchuk — Sun, 19 Jul 2020 18:44:01 +0000

Welcome Back! It’s been a little bit longer than I planned between my last post in this series and this one, but I should be back on track soon. This series picks up where the last series left off:

Backend Wrap Up

Andrew Luchuk ・ Jun 27 '20

#webdev

Wireframes

Wireframing helps developers by laying out the look of a UI in advance. Knowing how the UI will look is not only useful for making sure the UI is clean and usable, but also helps developers by enabling them to identify which parts of a UI can be reused.

I’ve created a few basic wireframes to give a simple idea of how the UI should be laid out when it’s done. As I’ve mentioned before, I am by no means the world’s best frontend engineer or UI designer, so I tried to make the UI look roughly like it is made up of Bulma components, which I’ll be using for the frontend.

Users will be greeted with a sign in page:

If they do not have an account, they can click the sign up button to get one:

Once logged in, users will be greeted by a list of posts, and after clicking one, they will see the post detail page:

If there are replies to the topic, it will look like this:

Finally, when replying to a post, users will see something like this:

Component Hierarchy

Once the wireframes are finished, we can begin to analyze the UI to identify reusable components of the UI. The UI analysis process is fairly straightforward. Essentially, the developer takes each part of the UI and breaks it down into components that can't be broken down any further.

I'm not going to go through the whole process here because it would take many words to describe something which is much more easily understood through images. If analyzing the UI is new to you, then the React docs have an excellent tutorial to help you understand the process: Thinking in React.

I’ve gone ahead and created some simple charts to demonstrate how the components should work together. Identical names indicate that the component is to be reused in multiple places. Finally, since we will be using redux to share state across components, we won’t need to worry about making sure state flows in an easy way.

For the Login page, the component tree will look something like this:

The sign up page components:

The main page hierarchy:

Finally, the topic page is going to be the most complex page with a hierarchy something like this:

Each reply is going to be made up of a few more components, much like the topic:

I know it’s a lot to take in, but you won’t need to remember this, it just gives a skeleton around which to build the react page.

What’s next

As promised, this post starts a new series (which is itself part of a larger series) covering the frontend of our mini forum application.

Here’s the first post of the series:

Build a Forum App, from Code to Deploy

Andrew Luchuk ・ May 23 '20

#webdev

In keeping with the plan laid out there, this series will cover the following topics:

Wireframing and component Hierarchy (this post)
Writing tests for components and building the basic components
Querying the backend with GraphQL
Tying all the pieces together to complete the frontend.

Unfortunately, because I’m working on another project at the moment, I may not be able to post in this series every week, but I’ll do my best to keep on schedule.

Thank you all for reading, and I hope you find it helpful!