DEV Community: Jacer Omri

Notification data model

Jacer Omri — Fri, 23 Oct 2020 00:31:20 +0000

I'm writing this post hoping to start a discussion about a good database model (Relational primarily) to serve most of the use-cases that require storing notifications in the database.
By notification, I mean something like "John commented on your post" or "Doe likes your profile".

I have been using polymorphism for the notification source and notification destination. I would use sometimes a JSON column to store arbitrary data, but I really hate it and would like to improve my methods.

Here are some points to discuss:

How to store notification source?
How to handle different notification types?
Notification messages?
Status?
Should a single notification instance be linked to multiple destinations or just duplicate for each destination?
What is an efficient query to list and paginate notifications when a user has different roles?

Cover image credit: https://www.kindpng.com/

A First Glance at AdonisJS 5.0 Preview

Jacer Omri — Tue, 03 Mar 2020 23:30:27 +0000

Tree days ago there was a BIG update. AdonisJS 5.0 Preview is released and we have waited for this for so long.
This tweet is from January

Adonis Js

@adonisframework

I heard that people like good news... 👀

Adonis 5 Preview will be released by the end of the month with a brand-new website and documentation!

In addition, @AmanVirk1 is recording few videos to cover the behind the scene of all the work made on this version.

18:35 PM - 08 Jan 2020

and just 4 days ago

Adonis Js

@adonisframework

Tomorrow. Pinkie promise 🤝🙌

04:42 AM - 29 Feb 2020

reasonably, this isn't that long. But for me at least, I wanted to test it so badly that I couldn't wait. I forked some modules and played with them before the release date. I liked the ideas behind Adonis from the beginning and even built and shipped projects with it back when version 3 was the latest.

I had so much fun when this was released! I'm in their Discord channel (if you're not, I recommend you joining). The moment I received the notification I started downloading and testing.

So I had an idea of what is inside and what to expect when this hits a stable version.

Release Process

The first big change is the release process. It's now a 6-week release cycle. This is important for a framework that is increasing in popularity very rapidly. This can help keep expectations in alignment with what is realistically possible, and for community modules and their maintainers to follow changes.

Typescript

Now everything is in Typescript. And I mean rewritten in Typescript, not just Javascript with typing. This means that everything can become typed, from request body (after validation), events, models to custom classes and modules.
This is so cool because this aspect can be a huge plus to code quality (especially in a large team setting), allows for more (accurate) help from the IDE and above all and provides ahead of time type checking and all the cool stuff that comes with Typescript.

use no longer, import instead

If you have tried AdonisJS before, you know the long story of use and how it magically solves bindings from the IoC and falls back to good old require call if the binding is not resolved.
This was a great technique that I actually liked very much and built my module provider around.
With the 5.0 release, this is no longer the case. We can now use standard ESM imports and prefix it with @ioc: if we intend to resolve a name from the IoC container.

Ace

The adonis CLI is being dropped in favor of ace. This way, ACE will always live inside your project and no longer need a global package to be installed. This should save us so much trouble with maintaining the right versions of tools across different projects.
To start a new project, all you have to do is npx

npx create-adonis-ts-app blog

Documentation

The new documentation is so good to follow!
For the time being it's still incomplete, but this makes it no less interesting. It's even been structured into smaller guides.

Performance

There has been an interesting effort put towards making small parts (that count) perform much better. The announced parts to receive most of the performance gain are the validator and the HTTP server (which is now decoupled in a standalone package)

Additions (aka new goodies)

Introduced in the new release are some new features and additions that personally felt the need for before (and thus find very interesting):

Signed Routes
Health Checks
Support for read/write replicas
Support for configuring runtime connections
RBAC
Queues
Caching

Progress

At the time of writing this, some work still needs to be done to have a final release of the 5.0. An overview of the ready to use feature vs pending ones are explained in this blog post by Harminder Virk, the creator of AdonisJS. I'll list here the content of that section of the blog post (don't hesitate to take a look at it though):

Functionality ready to be used

Router
Request, Response, and Templates
Cookies and Sessions
Lucid and its Active Record ORM
The Bodyparser with support for file uploads
Validator (some of the validation rules are missing)
Health checks
Logger
Mailer (some of the drivers are missing)
Events
Encryption and Hashing
Redis
Ace Commands

Packages that are not migrated yet

Authentication
Social Authentication
Websockets
Tests Runner
and Intl

New Functionality to be added

Support for RBAC
Queues
Caching (including Database queries)

You can also follow the roadmap on trello for more details about what is coming next weeks.

I have been testing this release in isolation, I haven't tried to migrate one of my projects yet (understandably because it's not a final release yet), but I've read some tweets from people saying it was really easy to do it

Nirmal Jasmatiya

@nir_jaz

bit.ly/nirmaljasmatiya
Just migrated my personal website to Adonis 5 from 4.1.
It's just awesome. I thought migration will take so much of time to get things done with preview release. But It just works. Thanks @adonisframework @AmanVirk1 @romainlanz

21:05 PM - 02 Mar 2020

In the end, if you haven't tried AdonisJS yet, I recommend you give it a try. Consider the bigger picture and all the good stuff that comes with it, and expect some missing features here and there (temporarily).

I hope you enjoyed reading this! Cheers!

Dynamic Api Url for your frontend project using Docker

Jacer Omri — Sun, 01 Mar 2020 00:07:43 +0000

If you're doing frontend web developing you know you have to keep some aspect of your app configurable. The most obvious case of this configuration is the API base url. You should define it in a way you could pass it as an environment variable in the build process.

When you're building with docker, it means this becomes a build argument, as opposed to container argument.

This is not ideal. Because then you should have a separate and different docker image for each environment (say canary, staging and production).

I'll be sharing with you a solution i came up with to solve this in all of our frontend projects. I'll be using an Angular project to illustrate.

Before

The first solution i had is to include a script to create the specific environment.something.ts file before the build process.

Here is how it looks like:



// FILE: front/scripts/set-env.ts

import { writeFile } from 'fs';
import { argv } from 'yargs';

// This is good for local dev environments, when it's better to
// store a projects environment variables in a .gitignore'd file
require('dotenv').config();

// Would be passed to script like this:
// `ts-node set-env.ts --environment=dev`
// we get it from yargs's argv object
const environment = argv.environment;
const isProd = environment === 'prod';

const targetPath = environment === 'dev'
  ? `./src/environments/environment.ts`
  : `./src/environments/environment.${environment}.ts`;
const envConfigFile = `
export const environment = {
  production: ${isProd},
  apiBaseUrl: '${process.env.API_BASE_URL}',
  version: 'v${require('../package.json').version}'
};
`;

writeFile(targetPath, envConfigFile, function (err) {
  if (err) {
    console.log(err);
  }

  console.log(`Output generated at ${targetPath}`);
});

And i run the script in the docker build process as the following:



# FILE: Dockerfile

### STAGE 1: Build ###

# We label our stage as 'builder'
FROM node:10-alpine as builder
ARG NODE_ENV
ARG API_BASE_URL
ENV NODE_ENV "$NODE_ENV"
ENV API_BASE_URL "$API_BASE_URL"

COPY package.json package-lock.json ./
RUN npm set progress=false && npm config set depth 0 && npm cache clean --force
RUN npm install -g ts-node yargs dotenv typescript@2.4.2

## Storing node modules on a separate layer will prevent unnecessary npm installs at each build
RUN npm i && mkdir /ng-app && cp -R ./node_modules ./ng-app
WORKDIR /ng-app
COPY . .
## Build the angular app in production mode and store the artifacts in dist folder
RUN ts-node ./scripts/set-env.ts --environment=prod #actually this is defined as a script in package.json, let's add it here so things would make sense.
RUN npm run build


### STAGE 2: Setup ###

FROM nginx:1.13.3-alpine

## Copy our default nginx config
COPY nginx/default.conf /etc/nginx/conf.d/

## Remove default nginx website
RUN rm -rf /usr/share/nginx/html/*

## From 'builder' stage copy over the artifacts in dist folder to default nginx public folder
COPY --from=builder /ng-app/dist /usr/share/nginx/html
CMD ["nginx", "-g", "daemon off;"]

In the end, we end up with a very small docker file, containing nginx and only the build artifacts. No node_modules, no nodejs, nothing. This is good until you want to use the same image for multiple environments.
The first idea to come to mind is to ditch this 2 step build process and just ship the actual angular code and serve it on the fly using any runtime configuration. Right?

The only problem is, the docker image would get 200 times bigger, and this is a big no no.

Solution!

Let's use some Linux skills and figure out how we could change the API base url in the compiled Javascript files!

First, that old script becomes like this:



// FILE: front/scripts/set-env.ts

...
export const environment = {
  production: ${isProd},
  apiBaseUrl: 'API_BASE_URL',
  version: 'v${require('../package.json').version}'
};
`;
...
```
Basically, we are passing this string `'API_BASE_URL'` in the configuration.

Next, we need to find and replace that string in every compiled Javascript file in the resulting image. Let's make a small adjustment in the Dockerfile:

```Dockerfile
# FILE: Dockerfile

...
COPY --from=builder /ng-app/dist /usr/share/nginx/html
COPY --from=builder /ng-app/scripts/replace_api_url.sh /

CMD ["sh", "replace_api_url.sh"]
```

We did 2 things here:
* added a new script called `replace_api_url.sh` which we'll see in a minute
* and replaced the command line so it would no longer launch nginx directly, instead, we want to execute our newly added script.

Finally, this is what the new script looks like:

```typescript
// FILE: front/scripts/replace_api_url.sh

#!/usr/bin/env sh

find '/usr/share/nginx/html' -name '*.js' -exec sed -i -e 's,API_BASE_URL,'"$API_BASE_URL"',g' {} \;
nginx -g "daemon off;"
```

So we're launching nginx at the end, but we're expecting an environment variable *at runtime* to replace every occurrence of `API_BASE_URL` in all js files.

Now you only need to pass any API url when running a new docker contanaier!
```bash
docker run -p 3000:3000 -e API_BASE_URL=http://myawesomebackend.com/api front
```

Thats's it!

Thank you for reading, this is my first post here and would like to have your feedback so i can continue writing better and better stuff here.

![THE END](https://www.mememaker.net/api/bucket?path=static/img/memes/full/2015/Mar/3/2/you-made-it-to-the-end.jpg)
_Credit: Cover image from https://medium.com/developer-diary/quick-start-guide-for-docker-with-angular-on-windows-492263edeaf8_