Add the post about javascript patterns.
This commit is contained in:
parent
06af1be666
commit
fbc4db8da1
@ -1,83 +0,0 @@
|
|||||||
---
|
|
||||||
title: HS(D)P
|
|
||||||
description: Describing the architecture of Handlers, Services, (Domains), and Presentation
|
|
||||||
date: 2024-08-11
|
|
||||||
tags:
|
|
||||||
- development
|
|
||||||
- javascript
|
|
||||||
- typescript
|
|
||||||
- hono
|
|
||||||
slug: hsdp
|
|
||||||
draft: true
|
|
||||||
---
|
|
||||||
|
|
||||||
## Handlers, Services, (Domains?), Presentation
|
|
||||||
|
|
||||||
In [my last blog post](https://davesmithhayes.com/posts/fullstack-hono) I talked about how I have stopped thinking of my Node.js applications as Model-View-Controller and started thinking of the applications in a new, fun acronym: Handlers, Services, (_sometimes Domains_), and Prfesentation. I thought this would be a good topic for a new blog post. So here it is.
|
|
||||||
|
|
||||||
I am going to be talking about this pattern in relationship to JavaScript and why the language lends itself to the pattern when working on applications.
|
|
||||||
|
|
||||||
## The Application
|
|
||||||
|
|
||||||
Like the previous post, I talked about building this blog with Bun and Hono. I am going to do the same here, however the application we are going to build is the all time classic - The TODO Application.
|
|
||||||
|
|
||||||
## JavaScript
|
|
||||||
|
|
||||||
One of the important things about JavaScript that alluded me for far too long was how the modules actually worked with Node.js. A module before ES6 was simply a JavaScript file that declares a `module.exports` value with the code you want to expose to other modules with the `require` function. Like so:
|
|
||||||
|
|
||||||
```js
|
|
||||||
function doSomething() {
|
|
||||||
// ...
|
|
||||||
}
|
|
||||||
|
|
||||||
module.exports = doSomething;
|
|
||||||
```
|
|
||||||
_`example.js`_
|
|
||||||
|
|
||||||
Then we can pull in `doSomething` with `require`:
|
|
||||||
|
|
||||||
```js
|
|
||||||
const doSomething = require('./example');
|
|
||||||
```
|
|
||||||
_`index.js`_
|
|
||||||
|
|
||||||
I don't know why I didn't know this, but the code in the `example.js` file is evaluated **and** run during the `require()` call.
|
|
||||||
|
|
||||||
In my past life I would try and build a Singleton class for holding onto an application's Connection Pool to a database. But because of how the Modules in Node.js work, we only need to instantiate the Pool and export it. Here's an example of how we can set up a single pool using the MariaDB official package:
|
|
||||||
|
|
||||||
```js
|
|
||||||
const mariadb = require('mariadb');
|
|
||||||
|
|
||||||
const config = { ... };
|
|
||||||
const pool = mariadb.createPool(config);
|
|
||||||
|
|
||||||
module.eports = pool;
|
|
||||||
```
|
|
||||||
_`pool.js`_
|
|
||||||
|
|
||||||
Now the connection pool is only created once and you can require this
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Outline:
|
|
||||||
|
|
||||||
* Explain what I know about JavaScript
|
|
||||||
* How does this differ to my experience with PHP
|
|
||||||
* Describe modules
|
|
||||||
* Describe how we can set up singletons thinking in modules
|
|
||||||
* Talk about avoiding classes
|
|
||||||
* Talk about big express applications
|
|
||||||
* And how I used to make MVC applications
|
|
||||||
|
|
||||||
Different programming languages require different approaches for organizing code.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
67
posts/more-about-javascript.md
Normal file
67
posts/more-about-javascript.md
Normal file
@ -0,0 +1,67 @@
|
|||||||
|
---
|
||||||
|
title: Thoughts on JavaScript
|
||||||
|
description: Describing the architecture of Handlers, Services, (Domains), and Presentation
|
||||||
|
date: 2024-08-11
|
||||||
|
tags:
|
||||||
|
- development
|
||||||
|
- javascript
|
||||||
|
- typescript
|
||||||
|
slug: more-about-javascript
|
||||||
|
draft: true
|
||||||
|
---
|
||||||
|
|
||||||
|
## My History With JavaScript
|
||||||
|
|
||||||
|
I think the first time I wrote JavaScript and got paid for it, I was young, dumb, and willing to work at a design agency for nearly minimum wage making WordPress templates and CakePHP applications. The team I worked with had adopted jQuery for all things front-end - which was the style at the time. I think this time was about 2014.
|
||||||
|
|
||||||
|
From there, I moved on to other Agency jobs and finally ended up at my current place of employment as a lowly _PHP Developer_. This role was designed to solely work on a single Magento 1 codebase. Again, jQuery was the tool of choice. Of course the JavaScript landscape was changing rapidly with the introductions of Node.js, and frameworks like Angular and React. I paid no mind to these since the bulk of my work was still in the world of Magento 1 and working on a plan to migrate to Magento 2.
|
||||||
|
|
||||||
|
It wouldn't be until 2018 (or maybe 2019?) that I would write a line of JavaScript for Node.js. We had decided to go all-in on AWS Lambda. I worked on a service that would push order data out of our Magento instance into our Production Facility's database. Let's call this _The Bridge_. This Lambda was invoked by API Gateway. This was a very small web service, essentially. This was, also, my first experience with _Callback Hell_. There was no `await` and no real `Promise` API (except, _I think_ Bluebird, but I never knew about it at the time) yet. The service actually needed to do a lot of queries, and use those results for other queries, so on, and so forth. If you're familiar with working on Callback Hell you will recognize this:
|
||||||
|
|
||||||
|
```javascript
|
||||||
|
var mysql = require("mysql");
|
||||||
|
|
||||||
|
var config = {...};
|
||||||
|
|
||||||
|
mysql.connect(config, function (err, conn) {
|
||||||
|
// handle the error
|
||||||
|
if (err) {
|
||||||
|
console.error(err);
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
|
||||||
|
var query = "INSERT ...";
|
||||||
|
|
||||||
|
conn.query(query, function (err, results) {
|
||||||
|
if (err) {
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
|
||||||
|
// do something with results
|
||||||
|
// do another query
|
||||||
|
conn.query(query, function (err, results) {
|
||||||
|
// handle error
|
||||||
|
// do more queries
|
||||||
|
|
||||||
|
conn.query(query, function (err, results) {
|
||||||
|
// etc.
|
||||||
|
});
|
||||||
|
});
|
||||||
|
});
|
||||||
|
});
|
||||||
|
```
|
||||||
|
_This sucks._
|
||||||
|
|
||||||
|
We ended up rewriting this service in C# as that was the most popular language within the organization at the time. Honestly, thank god. I didn't need to write or maintain the service once it fell into the hands of the .NET team.
|
||||||
|
|
||||||
|
## How I Approached Big Applications
|
||||||
|
|
||||||
|
Eventually all the .NET guys left the company. My boss left the company. I was put in charge and the first thing I did was deploy an Express.js application to completely rewrite the service discussed above. I did this because this was actually faster to do than figure out how the build system (Jenkins, Ansible, and TeamCity _I think_) and deploy it to our common pattern architecture. It was also a way for me to prove to my new boss that I can get things done and that moving to slowly remove our reliance on .NET and IIS for our services was a worthy endeavor.
|
||||||
|
|
||||||
|
A lot of my experience up until that point was mostly working in Magento 2, which is a massive, Enterprisey, PHP application. Modern PHP tends look more and more like C# or Java as the years go on. So that's where my mind is - poisoned by web MVC and Enterprise OOP (_tm_).
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user