DEV Community: Diego Gallovich

Solving common issues when connecting locally run apps (In my case Strapi v4.x) to a production PostgreSQL database.

Diego Gallovich — Mon, 03 Jul 2023 09:08:27 +0000

Introduction

This article is for anyone aiming to connect to a production environment PostgreSQL database from a locally run Strapi CMS. While this approach is not considered best practice, it can be useful in scenarios where time is limited, complexity is moderate, and there is little risk. It’s important to note that working with SQLite for content type schema building and adding content in the production environment is recommended. However, in situations where speed is crucial, this guide provides steps to establish a connection.

My Environment

In my setup, I have a DigitalOcean VM (Droplet) hosting both the PostgreSQL database and the production Strapi app. On my local machine, I’m using Linux Ubuntu 22.04.

Prerequisites

Before proceeding, make sure the .env file in your Strapi app contains the correct environment variables. To ensure accuracy, I logged into my VM, copied the generated .env file from the app setup, and pasted it locally. This guarantees that the database name, host, user, and password are correct. Additionally, verify that the config/database.js file in your Strapi app is correctly configured to point to the appropriate environment variables or default to the desired values if no environment variables are set.

Solving Issue #1: Knex Timeout

One common issue you might encounter is the Knex timeout error. This typically occurs when TCP connections to port 5432 (the default PostgreSQL port) are not enabled for your local IP address. To resolve this, you need to ensure that your firewall allows incoming connections on port 5432 from your local IP address. How you do this depends on the firewall manager you are using.

Solving Issue #2: Connection Refused Error

If you encounter the “ECONNREFUSED” error despite enabling the connection, there is another step to consider. By default, PostgreSQL databases only allow connections from the localhost IP address. To allow connections from other IPs, modify the postgresql.conf file. Locate the postgresql.conf file on your system (e.g., /etc/postgresql/13/main/postgresql.conf on Ubuntu) and ensure that the listen_addresses setting includes the desired IP addresses or * to allow connections from any IP. Restart the PostgreSQL service for the changes to take effect.

listen_addresses = 'localhost, 192.168.0.100'
# or
listen_addresses = '*'

Solving Issue #3: pg_hba.conf Entry for IP

You may also encounter the “no pg_hba.conf entry for IP” error. This error is related to the pg_hba.conf file, which specifies access rules for PostgreSQL. To address this, locate the pg_hba.conf file on your system (e.g., /etc/postgresql/13/main/pg_hba.conf on Ubuntu) and add an entry to allow connections from your IP address. Make sure to document the entry with a comment for reference. Restart the PostgreSQL service for the changes to apply. Find the document, read it, it’s helpful, and then at the bottom of the file add your new rule, you’ll see that you will have to be specific about which ip, db, user, and method are used to connect. It is a layer of security that keeps you from making dumb mistakes. This is how a good rule might look:

# IPv4 remote connections for your-strapi-db-user
host    your-strapi-db    your-strapi-db-user    {your ip}/32    md5

Final notes

By following these steps, you should be able to establish a connection between your locally run Strapi CMS and the production PostgreSQL database. Remember that this approach is not the recommended best practice, but it can be a viable option in certain situations. Be mindful of security considerations and explore alternatives like SQLite for local development and content-type schema building. If you still have to connect remotely to your production environment database, then make sure to keep as much security at the psotgresql.conf and pg_hba.conf layer.

GitHub API OAuth in 2020.

Diego Gallovich — Mon, 06 Apr 2020 18:13:18 +0000

Small introduction to working with the GitHub API.

Working with restful APIs is becoming a standard for developers. Just like that, the GitHub API is becoming the go-to API for us developers to get some practice with micro-services.

In order to work with most APIs, including GitHub’s, your application’s request to such API must be authenticated in some way. To do this, GitHub’s API services offer different methods, and those methods depend on what your application’s request is actually asking for.

The most common use case for an API is to retrieve data from the database the API is connected to. With the GitHub API, a good example would be to retrieve a user’s most recent repositories. So… how do we do that?

-
Making an Authenticated request to the GitHub API the 2020 way.

Firstly, in order to make a request, API or not, we need a URL right?

'''
https://api.github.com/
'''

That right there, obviously, is the GitHub's API URL. Now, for our example, we want the repositories URL of the API. which is the same as above followed by a user’s username and the repositories’ slug provided by GitHub. Here’s mine for example:

'''
https://api.github.com/users/dieguiviti/repos/
'''

-
Very well… now, in order for us to make an authenticated request to that URL from our back-end application, we need something to identify our application. That is why before making any requests, we need to register our OAuth app from GitHub's developer settings in our profile. Once you do that, GitHub provides your application with two identification numbers: client_id & client_secret.

Before February of this year, we used these numbers in the query URL to identify ourselves with the service provider. Cyber crime is an ever growing trouble and in order to prevent faked URL authentications or exposing identifiers, GitHub is taking a new approach as to how they authenticate applications that use their API.

-
Query URL Authentication vs. Header Authentication.

Just like we talked about, GitHub’s accustomed way of authorizing apps to use their services came straight from the request’s URL, so something like this:

'''
https://api.github.com/users/dieguiviti/repos?client_id=my_client_id&client_secret=my_secret_id
'''

As you can see, using this authentication method exposes the client app’s id and secret in the URL to any cyber-criminals wishing to hijack the application.

You could probably make that request with axios with the following code:

'''
// Github api url
let url = "https://api.github.com/users/dieguiviti/repos? client_id=my_client_id&client_secret=my_secret_id";
// Axios request
axios.get(url).then("Whatever you are doing with the data");
'''

That is a viable way to get the desired repositories but, not a secure one.

-
How do we assess this?

Simple, send your identification credentials in the header of the request, or as options. Axios for example, takes an object as a second parameter called options. In the options object, you can specify configurations for your request. Something like this:

'''
// Github api url
let url = "https://api.github.com/users/dieguiviti/repos";

// Request's options
const OPTIONS = {

headers: { 'user-agent': 'node.js' },

client_id: CONFIG.get('githubClientID'),

client_secret: CONFIG.get('githubSecret')

};

// AXIOS request

axios.get(url, OPTIONS).then("whatever you are doing with the data");
'''

As you can see, we are specifying our apps client id and client secret by inserting them in an options object that retrieves the data from a configuration file in our app. We then pass those options to axios and make the request.

Yes, just like that we kept our app from exposing Authentication Identifiers to anyone out there.

-
What next?

There is a deprecation notice for the query URL authentication method and it will no longer be available to use later this year.

If you have any apps that communicate with the GitHub API using URL authentication, it is probably best, well actually, it is best for you to quickly adapt all your requests to this more secure way of authenticating your application.

Refer to GitHub API documentation for more information and feel free to reach out to me if you have any other questions.

Thank you for reading on and remember to stay relevant!!!

Track user behavior & resource demand with ‘mongoose-morgan’

Diego Gallovich — Mon, 30 Mar 2020 12:52:59 +0000

Hello and welcome to this weeks’s article. Today, we will discuss three npm packages. Two will be explained very briefly ( mongoose and morgan ), and the third one is the one we will focus on ( mongoose-morgan ).

Mongoose is a MongoDB modeling tool for node.js applications. With it, we use object-oriented JavaScript programming to create MongoDB schemas and models. It also allows us to interact and query the database right from the backend of our node.js application. In the example below, we create a schema, then use the schema to create a model and finally export it to be used across our app’s code.

const MONGOOSE = require('mongoose');
const SCHEMA = MONGOOSE.Schema; 
// create User Schema
const USER_SCHEMA = new SCHEMA({  
   name: {    
       type: String,    
       required: true  
   },  
   email: {    
       type: String,   
       required: true,    
       unique: true  
   },  
   password: {    
       type: String,    
       required: true  
   },  
   avatar: {    
       type: String  
   },  
   date: {    
       type: Date,    
       default: Date.now()  
   }
}); 

// Define Model
const USER_MODEL = MONGOOSE.model('user', USER_SCHEMA);
// Export model
module.exports = USER_MODEL;

So, let’s talk about morgan before we derail this any further. Morgan is an HTTP request logger for node.js applications. It works as middleware in the request cycle of the ‘request-response’ life-cycle of your application. Meaning that it plays a roadblock role in your applications HTTP requests. Each time a request is made to your server, morgan will log it to the console in the format of your choice. Morgan has many formats available but, I use ‘tiny’ format, which just logs the URL the request was made to, the status code of the response and the time it took to respond. Here’s a simple example:

// Require morgan in your server.js or index.js after npm install
const MORGAN = require('morgan');

// Whatever code you have...

// Right before your router and routes initialization, use morgan.
MORGAN('dev');

// Example route, router initialization
APP.use('/api/profiles/', require('./routes/api/profiles'));
APP.listen (PORT, () => console.log('Working...'));

With the example above, morgan would log something like this to the console each time a request is made:

POST /api/users 200 195 - 720.322 ms

So it gives us the method of the request, the resource the request was made to, its status code and the time it took to send a response. There is a format called ‘dev’ which also gives you the date. And other formats allow you to extract the remote address the request was made from as well.

Now… the underdog of the day… mongoose-morgan!!!

I think that by now you have a pretty good guess of what this package does. This ingenious package, grants you the easiest way to track all requests made to your application by not only logging them but also saving them to your desired database. The way I use this package for example is to check which are the most demanded resources on my site without using any heavy analytics tools. Not only that, I can also see which resources take longer to load or tend to crash more. Here’s an example of it in my code:

// This is file is logger.js
const MONGOOSE_MORGAN = require('mongoose-morgan');
const CONFIG = require('config');

// Mongoose-morgan
const DB = CONFIG.get('mongoURI');
const MORGAN = MONGOOSE_MORGAN(  
      // DB object with connection string and target collection
      {   
       collection: 'request-logs',    
       connectionString: DB  
      },
      // Options object. Custom preferences
      {},
      // Logging format
      'tiny'
); 

// Export Middleware
module.exports = MONGO_MORGAN;

Easy… We require mongoose-morgan and then config to retrieve the desired configuration variables (you could use dot-env too). We proceed to retrieve the Database URI for all requests to be saved, then we initialize a variable containing the mongoose-morgan call. MONGOOSE_MORGAN takes in three areguments:

An object defining database collection and connectionString.
After this object, we pass another one with any custom preferences, more of that in mongoose-morgan@npm.
Finally pass in the logging format you desire and close the call.

Finish up by exporting the middleware and import it in your server like we did with the morgan package:

// Server.js

// import
const MONGO_MORGAN = require('./middleware/logger.js');

// Call before router, route instance
APP.use(MONGO_MORGAN);

// Routes and APP.listen below.

After that, you will see the collection you defined added to your database and all of your server requests logged to it. Giving you heavy impact data more lightly than ever before.

This is a powerful tool that gives you both marketing and performance related data about your application and saves it as you please.

Fun facts:

Mongoose has 800,000+ downloads a week
Morgan has 2,000,000+ downloads a week
Mongoose-morgan only has 200–400 downloads a week.

I hope you take advantage of this information and use it strategically. That was all folks!

Make sure to share this with your coworkers and fellow devs.

See you next week and stay safe!

Replacing the deprecated npm package ‘request’ without altering your project.

Diego Gallovich — Tue, 24 Mar 2020 09:45:34 +0000

If you are a working developer, then you are probably aware that the HTTP caller package ‘request’ has not so recently been tagged as deprecated. In the JavaScript world, we would argue that a month is not a little amount of time, when it comes to JavaScript, a lot can happen in that amount of time. In today’s article we will go over why it has been deprecated and then we will start discussing how to replace it in your project without affecting it or doing any major refactoring using axios.
Since ‘request’ is a package that is still downloaded 10 million times a week, I cannot help but wonder, why are so many developers still downloading a package that is posing so many vulnerability threats for the future of any application that uses it? Those 10 million downloads are the reason of why I am writing this article.
Why is it deprecated…? The ‘request’ package is an HTTP caller like many other good ones you may or may not know. The thing about this particular package is that it is one of the first modules ever created for the Node.js ecosystem. That was in 2009 (A very long time in the JavaScript world), so obviously, even if it evolved across the years, its respectfully primitive or older code base has reached a spot where it must rest in maintenance until it slowly fades away from apps in development and production today. The main reason is that JavaScript evolved and changed at a much faster rate that anyone could expect, meaning that more HTTP calling packages have been developed on a more modern and secure code base. You can find a more detailed account on why ‘request’ is deprecating at an issue opened in its own GitHub repo.
How do we replace it…? Request’s deprecation becomes harmful to your app the longer it stays a part of it. Why? Simply because modern, constant changes to JavaScript mean more attack vectors opening up for cyber-criminals on older JavaScript code based apps and packages, that includes ‘request’ now that it has been deprecated.
There are several module options to replace ‘request’ without affecting the flow or structure of your application. My replacement choice is axios. Axios can do everything request can do and much more… And they look just about the same when written out.
Here’s a basic ‘request’ HTTP call example:

/const request = require('request'); request('http://www.google.com', function (error, response, body) { console.error('error:', error); // Print the error if one occurred console.log('statusCode:', response && response.statusCode); // Print the response status code if a response was received console.log('body:', body); // Print the HTML for the Google homepage. });

So very simple, we require 'request' after doing an npm install, then we call it the module while passing a URL and a function that handles the request, response life-cycle.
In Axios, we do just about the same…

// Github api url const URL =https://api.github.com/users/${request.params.username}/repos?per_page=5&sort=created:asc;
// Request's options const OPTIONS = { headers: { 'user-agent': 'node.js' }, client_id: CONFIG.get('githubClientID'), client_secret: CONFIG.get('githubSecret') }; // AXIOS request's response const AXIOS_RESPONSE = await AXIOS.get(URL, OPTIONS); // Response to client response.json({ count: AXIOS_RESPONSE.data.length, repos: AXIOS_RESPONSE.data });

Simply install axios on your app and then use it to make API calls in the back or front end of your application, you can even set headers through options passed to the request function. In the example above, the axios request is running inside an asynchronous server request, response cycle for a user’s five most recent repositories and inside a trycatch an AXIOS_RESPONSE constant awaits to make a get request to the GitHub API using the previously instantiated URL and OPTIONS constants. Then, the returned promise in AXIOS_RESPONSE.data is sent as response to the client.
You could also do .then() and not use async/await… There is simply no limit… get started with axioss npm documentation and start replacing ‘request’ in order to secure your application.
If you want to consider other options to replace ‘request’, there is an issue open on GitHub for that as well. Just click here!
That was all for today, I hope you found valuable information in this article and keep your app secure thanks to it.

Any questions or feedback? Feel free to reach out to me…

Liked the article? Clap for it to reach others, share it on twitter and any other social media.

Stay relevant!

From LAMP to MERN: Understanding similarities and differences

Diego Gallovich — Tue, 24 Mar 2020 09:00:14 +0000

Not so long ago, when I started my journey as a Full Stack Web Developer, the stack that appealed to me the most was initially the LAMP stack. This is because I love Laravel but, like many others, I have seen myself inevitably adapting to more updated stacks like the MERN stack.
In this article, I will talk about how I used my understanding of the LAMP stack to move on to MERN stack, and caught up with the JavaScript-as-a-server-side-language trend.
Let’s start by breaking both stacks down:

LAMP:

L: Linux Operating System ( I am not mentioning WAMP because I simply hate Windows ).
A: Apache HTTP server.
M: MySQL Relational Database Management System.
P: PHP programming language (Could be Python or Perl). MERN:
M: MongoDB Database Management System.
E: ExpressJS Web Application Framework for NodeJS.
R: ReactJS, a JavaScript library for building User Interfaces (UI — Frontend).
N: NodeJS server, or just call it Server-side JavaScript.

Okay, great… and?

Well, let’s cross-match a little bit... And in order to do so, let’s think about how the app communicates internally across its stack elements.

First, the most important difference between the stacks are the languages used on the server. A LAMP stack application communicates with its server (Apache) using the P (PHP, Python or Perl), while a MERN stack application communicates with its server (NodeJS) using the N (NodeJS). You might ask yourself, what the heck is that supposed to mean?… Turns out that, until recent years, JavaScript could only run on the browser, meaning that it handled data only on the front-end of an application. But then came NodeJS, a runtime environment that allowed JavaScript to run on the server. That is why we call NodeJS the server-side JavaScript. So cross-match number one: (N)odeJS is to the MERN stack what (P)HP and Apache are to the LAMP stack. Paradox.

Second, a server-side language is a good thing but, a server-side framework is even better. Here is where our stacks’ cross-matching goes a bit off. PHP has frameworks that allow it to simplify server creation and management (Laravel, Symfony), and so does NodeJS. The difference is that, the framework NodeJS uses to manage and delegate server requests is actually part of the MERN stack… you’ve guessed it! It is Express JS, which leads us to our cross-match number two: ExpressJS is, to NodeJS in the MERN stack, what PHP (Laravel, Symfony) is to Apache in the LAMP stack.

Reality is, NodeJS does not need ExpressJS to create an HTTP server, just as Apache does not need Laravel or Synfony, but does need PHP, Python or Perl. ExpressJS is a framework that simplifies the creation and development of a NodeJS server.

Third, so far we have mostly talked about LAMP’s and MERN’s respective servers, and the respective server-side languages for each. Now, let’s talk about the why. Databases.
This is a pretty obvious but, interesting cross-match: While LAMP uses an SQL based database management system, MERN uses a JavaScript based database management system through the use of JSON-like syntax. This is where you notice the power of MERN… it is simply JavaScript all accross.
In the LAMP stack you have to worry about handling SQL, PHP and maybe even some JavaScript for the front-end.
For the MERN stack, learning JavaScript gives you a whole stack foundation of knowledge.
I mean… it is 3 vs. 1 language, you tell me what’s simpler…

Anyways… cross-match number three: MongoDB is to the MERN stack what MySQL is to the LAMP stack.

Fourth crossmatch… ReactJS is to the MERN stack what nothing is to the LAMP stack.

Here is the funny thing… You could actually use ReactJS to style the front-end of a LAMP stack application, and you probably know that but, notice how there is no accountability for a technology that handles the front-end responsibility in the LAMP stack. This is because the LAMP stack architecture is more server based than client based. The elements of the LAMP stack do not mention any User Interface related technologies while the MERN stack does (ReactJS).

Finally… a stack is a stack but… In my junior, humble opinion, unlike the LAMP stack definition, the MERN stack definition pretty much covers all the elements of a modern web app:

MongoDB, a database management system;
Express, a speedy and simple server-side framework;
React, a technology able to create modern UIs;
Node, a flexible server-side language and server environment.

Note that all the elements of the MERN stack were built with JavaScript in mind, and that JavaScript is in fact, The Web-App Development Language.
This is my humble perspective on the similarities and differences between the most used web app stacks today. I might be wrong about some things so feedback on my opinion is very welcome!
Thank you for reading on through the very end, and I hope this article helped you in any way possible!
If you liked it, please give this article a thumbs up and share it with fellow developers.
Now, get your eyes back on your editor!!!