MongoDB is a cross-platform, open-source, NoSQL database, used by many modern Node-based web applications to persist data.

In this beginner-friendly tutorial, I’ll demonstrate how to install Mongo, then start using it to store and query data. I’ll also look at how to interact with a Mongo database from within a Node program, and also highlight some of the differences between Mongo and a traditional relational database (such as MySQL) along the way.

Terminology and Basic Concepts

MongoDB is a document-oriented database. This means that it doesn’t use tables and rows to store its data, but instead collections of JSON-like documents. These documents support embedded fields, so related data can be stored within them.

MongoDB is also a schema-less database, so we don’t need to specify the number or type of columns before inserting our data.

Here’s an example of what a MongoDB document might look like:

{ _id: ObjectId(3da252d3902a), type: "Tutorial", title: "An Introduction to MongoDB", author: "Manjunath M", tags: [ "mongodb", "compass", "crud" ], categories: [ { name: "javascript", description: "Tutorialss on client-side and server-side JavaScript programming" }, { name: "databases", description: "Tutorialss on different kinds of databases and their management" }, ], content: "MongoDB is a cross-platform, open-source, NoSQL database..."
}

As you can see, the document has a number of fields (type, title etc.), which store values (“Tutorial”, “An Introduction to MongoDB” etc.). These values can contain strings, numbers, arrays, arrays of sub-documents (for example, the categories field), geo-coordinates and more.

The _id field name is reserved for use as a primary key. Its value must be unique in the collection, it’s immutable, and it may be of any type other than an array.

Tip: for those wondering what “JSON-like” means, internally Mongo uses something called BSON (short for Bin­ary JSON). In practice, you don’t really need to know much about BSON when working with MongoDB.

As you might guess, a document in a NoSQL database corresponds to a row in an SQL database. A group of documents together is known as a collection, which is roughly synonymous with a table in a relational database.

Here’s a table summarizing the different terms:

If you’re starting a new project and are unsure whether to choose Mongo or a relational database such as MySQL, now might be a good time to read our tutorial SQL vs NoSQL: How to Choose.

With that said, let’s go ahead and install MongoDB.

Installing MongoDB

Note: if you’d just like to follow along with this tutorial without installing any software on your PC, there are a couple of online services you can use. Mongo playground, for example, is a simple sandbox to test and share MongoDB queries online.

MongoDB comes in various editions. The one we’re interested in is the MongoDB Community Edition.

The project’s home page has excellent documentation on installing Mongo, and I won’t try to replicate that here. Rather, I’ll offer you links to instructions for each of the main operating systems:

• Install MongoDB Community Edition on Windows
• Install MongoDB Community Edition on macOS
• the original (another 5877 bytes)

During a recent run of my Advanced Web Application Architecture training, we discussed the distinction between infrastructure code and non-infrastructure code, which I usually call core code.
One of the participants summarized the difference between the two as: “everything in your vendor directory is infrastructure code”.
I don’t agree with that, and I will explain why in this article.

Not all code in vendor is infrastructure code

Admittedly, it’s easy for anyone to not agree with a statement like this, because you can simply make up your own definitions of “infrastructure” that turn the statement false.
As a matter of fact, I’m currently working on my next book (which has the same title as the training), and I’m working on a memorable definition that covers all the cases.
I’ll share with you the current version of that definition, which consists of two rules defining core code.
Any code that doesn’t follow both these rules at the same time, should be considered infrastructure code.

Rule 1: Core code doesn’t directly depend on external systems, nor does it depend on code written for interacting with a specific type of external system.

Rule 2: Core code doesn’t need a specific environment to run in, nor does it have dependencies that are designed to run in a specific context only.

Following this definition means that as soon as a piece of code reaches out to something outside of the running application (e.g. it connects to the network, touches the file system, requests the current time or random data), it should be considered infrastructure code.
As soon as a piece of code could only runs in a particular environment (a web application, a CLI application, etc.) it should also be considered infrastructure code.

These rules don’t say anything about whether core code lives in src/ or in vendor/, and rightfully so.
Imagine you have a piece of code you are allowed to call core code because it matches its definition.
If you now move this code to a separate repository on GitHub, publish it as a package, and install it in your project’s vendor/ directory with Composer, would that same piece of code suddenly become infrastructure code? Of course not. The location of code doesn’t determine what kind of code it is.

So whether or not something is vendor code doesn’t determine if it’s infrastructure code. What makes the difference is whether or not you can run that code in complete isolation, without making external dependencies available, and without preparing the environment in some way.

Unit tests and core code

This may remind you of Michael Feather’s definition of a unit test:

A test is not a unit test if:

• It talks to the database
• It communicates across the network
• It touches the file system
• It can’t run at the same time as any of your other unit tests
• You have to do special things to your environment (such as editing config files) to run it.

Tests that do these things aren’t bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to be able to separate them from true unit tests so that we can keep a set of tests that we can run fast whenever we make our changes.

In fact, following my definition of core code, we can conclude that core code is the only code that can be unit tested. This doesn’t mean that you can’t test infrastructure code, it only means that such a test could not be considered a unit test. These tests are often called integrated or integration tests instead.

Most, but not all code in vendor is infrastructure code

So there is no strict relation between being-infrastructure-code and being-inside-the-vendor-directory.
However there is somewhat of an inverse relation: much of your application’s infrastructure code lives in your vendor directory.
You could also say that you write most of the core code yourself.

Let’s take a look at some examples of code that lives in vendor, but would (according to my rules) not be called infrastructure code:

• An event dispatcher library
• An assertion library
• A value object library

Libraries that only deal with transforming data (like some kind of data transformer, mapper, or serializer) could be considered non-infrastructure code as well.

In practice, you can use the following checklist to find out if code (wherever it lives, in src or vendor)

Truncated by Planet PHP, read more at the original (another 1256 bytes)

Within the IBM i community, we often talk about modernization. Regardless of approach, the goals of every modernization project are based on making it easier to consume the golden gems contained in Db2 databases: 

Truncated by Planet PHP, read more at the original (another 16164 bytes)

The PHP development team announces the immediate availability of PHP 7.2.28. This is a security release.All PHP 7.2 users are encouraged to upgrade to this version.For source downloads of PHP 7.2.28 please visit our downloads page, Windows source and binaries can be found on windows.php.net/download/. The list of changes is recorded in the ChangeLog.

Say, you’re in a situation where you have a user type, that looks a bit as
follows:

export type User = { firtName: string; lastName: string; email: string;
} function save(user: User) { // ...
} const user = { firstName: 'Evert', lastName: 'Pot', email: 'foo@example.org',
} save(user);

But, instead of accepting any string for an email address, you want to
ensure that it only accepts email addresses that are valid.

You might want to structure your user type as follows:

type Email = string; export type User = { firtName: string; lastName: string; email: Email
}

This doesn’t really do anything, we aliased the Email to be exactly like a
string, so any string is now also an Email.

We can however extend the email type slighty to contain a property that
nobody can ever add.

declare const validEmail: unique symbol;
const validEmail = Symbol('valid-email'); type Email = string & { [validEmail]: true
} export type User = { firstName: string; lastName: string; email: Email
}

In the above example, we’re declaring a symbol. This is similar to using
const validEmail = new Symbol('valid-email');, but it doesn’t exist
after compiling.

The unqiue symbol type is a type that can never be created.

We’re adding a property with this key to our Email string. A user can only
add this property, if they have an exact reference to the original symbol.

Given that we don’t export this symbol, it’s not possible anymore for a user
to construct an

Truncated by Planet PHP, read more at the original (another 13090 bytes)

What Is PHP?

PHP is a highly flexible language for writing server-side scripts that can run on virtually any platform, including Linux, Microsoft Windows, and even proprietary platforms such as IBM i. Developers can also use the language to write in both procedural and object-oriented styles.

What Is PHP Used for?

PHP is most commonly used to develop websites and web applications. More and more, however, developers use it to build backend APIs that are consumed by frontend web applications, mobile apps, and IoT devices including wearables.

I recently needed to validate the value created by PHP for its session ID. After a bit of research, I realised that there are two interesting php.ini config settings that relate to this value:

• session.sid_length is the number of characters in the ID
• session.sid_bits_per_character controls the set of characters used. From the manual:
  

  The possible values are ‘4’ (0-9, a-f), ‘5’ (0-9, a-v), and ‘6’ (0-9, a-z, A-Z, “-“, “,”).

Therefore, to validate the session ID we need to create a regular expression that looks for the correct set of characters of the expected length.

I wrote function to do this:

function isValidSessionId(string $sessionId): bool
{ $sidLength = ini_get('session.sid_length'); switch (ini_get('session.sid_bits_per_character')) { case 6: $characterClass = '0-9a-zA-z,-'; break; case 5: $characterClass = '0-9a-z'; break; case 4: $characterClass = '0-9a-f'; break; default: throw new \RuntimeException('Unknown value in session.sid_bits_per_character.'); } $pattern = '/^[' . $characterClass . ']{' . $sidLength . '}$/'; return preg_match($pattern, $sessionId) === 1;
}

You could use it like this:

$name = session_name();
if (isset($_COOKIE[$name])) { if (!isValidSessionId($_COOKIE[$name])) { // invalid - return an error, just send back a 500 or something exit; }
}

As far as I can tell, we can’t use session_id() as we haven’t started the session yet, however as the session is just a cookie at the HTTP level, we can use $_COOKIE instead.

Note also that the manual has an excellent section on Sessions and Security which is worth reading.

Truncated by Planet PHP, read more at the original (another 26960 bytes)

The Zend Framework project, which was formerly led and managed by Rogue Wave Software, is now called Laminas. To receive security updates, bug fixes, and new features for your Zend Framework code, you need to migrate it to the Laminas-branded packages.