Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Events
Videos
Audiobooks
Packt Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds
CouchDB and PHP Web Development Beginner's Guide
CouchDB and PHP Web Development Beginner's Guide

CouchDB and PHP Web Development Beginner's Guide: Get your PHP application from conception to deployment by leveraging CouchDB's robust features

eBook
$26.99 $29.99
Paperback
$50.99
eBook + Subscription
$24.99 Monthly

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Modal Close icon
Payment Processing...
tick Completed

Billing Address

Table of content icon View table of contents Preview book icon Preview Book

CouchDB and PHP Web Development Beginner's Guide

Chapter 1. Introduction to CouchDB

Welcome to CouchDB and PHP Web Development Beginner's Guide. In this book, we will learn the ins and outs of building a simple but powerful website using CouchDB and PHP. For you to understand why we do certain things in CouchDB, it's first important for you to understand the history of NoSQL databases and learn CouchDB's place in database history.

In this chapter we will:

  • Go over a brief history of databases and their place in technology

  • Talk about how databases evolved into the concept of NoSQL

  • Define NoSQL databases by understanding different classifications of NoSQL databases, the CAP theorem and its avoidance of the ACID model

  • Look at the history of CouchDB and its main contributors

  • Talk about what makes CouchDB special

Let's start by looking at the evolution of databases and how NoSQL arrived on the scene.

The NoSQL database evolution

In the early 1960s, the term database was introduced to the world as a simple layer that would serve as the backbone behind information systems. The simple concept of separating applications from data was new and exciting, and it opened up possibilities for applications to become more robust. At this point, databases existed first as tape-based devices, but soon became more usable as system direct-access storage on disks.

In 1970, Edgar Codd proposed a more efficient way of storing data — the relational model. This model would also use SQL to allow the applications to find the data stored within its tables. This relational model is nearly identical to what we know as traditional relational databases today. While this model was widely accepted, it wasn't until the mid 1980s that there was hardware that could actually make effective use of it. By 1990, hardware finally caught up, and the relational model became the dominant method for storing data.

Just as in any area of technology, competition arose with Relational Database Management Systems (RDBMS) . Some examples of popular RDMBS systems are Oracle, Microsoft SQL Server, MySQL, and PostgreSQL.

As we moved past the year 2000, applications began to produce incredible amounts of data through more complex applications. Social networks entered the scene. Companies wanted to make sense of the vast amounts of data that were available. This shift brought up some serious concerns about the datastructure, scalability, and availability of data that the relational model didn't seem to handle. With the uncertainty of how to manage this large amount of ever-changing data, the term NoSQL emerged.

The term NoSQL isn't short for "no SQL;" it actually stands for "not only SQL". NoSQL databases are a group of persistent solutions, which do not follow the relational model and do not use SQL for querying. On top of that, NoSQL wasn't introduced to replace relational databases. It was introduced to complement relational databases where they fell short.

What makes NoSQL different

Besides the fact that NoSQL databases do not use SQL to query data, there are a few key characteristics of NoSQL databases. In order to understand these characteristics, we'll need to cover a lot of terminology and definitions. It's not important that you memorize or remember everything here, but it's important for you to know exactly what makes up a NoSQL database.

The first thing that makes NoSQL databases different is their data structure. There are a variety of different ways in which NoSQL databases are classified.

Classification of NoSQL databases

NoSQL databases (for the most part) fit into four main data structures:

  • Key-value stores: They save data with a unique key and a value. Their simplicity allow them to be incredibly fast and scale to enormous sizes.

  • Column stores: They are similar to relational databases, but instead of storing records, they store all of the values for a column together in a stream.

  • Document stores: They save data without it being structured in a schema, with buckets of key-value pairs inside a self-contained object. This datastructure is reminiscent of an associative array in PHP. This is where CouchDB lands on the playing field. We'll go much deeper into this topic in Chapter 3, Getting Started with CouchDB and Futon.

  • Graph databases: They store data in a flexible graph model that contains a node for each object. Nodes have properties and relationships to other nodes.

We won't go too deeply into examples of each of these types of databases, but it's important to look at the different options that are out there. By looking at databases at this level, it's relatively easy for us to see (in general) how the data will scale to size and complexity, by looking at the following screenshot:

If you look at this diagram, you'll see that I've placed a Typical Relational Database with a crude performance line. This performance line gives you a simple idea of how a database might scale in size and complexity. How is it possible that NoSQL databases perform so much better in regards to high size and complexity of data?

For the most part, NoSQL databases are scalable because they rely on distributed systems and ignore the ACID model. Let's talk through what we gain and what we give up through a distributed system, and then define the ACID model.

When talking about any distributed system (not just storage or databases), there is a concept that defines the limitations of what you can do. This is known as the CAP theorem.

CAP theorem

Eric Brewer introduced the CAP theorem in the year 2000. It states that in any distributed environment, it is impossible for it to provide three guarantees.

  • Consistency: All the servers in the system will have the same data. So, anyone using the system will get the latest data, regardless of which node they talk to in the distributed system.

  • Availability: All of the servers will always return data.

  • Partition-tolerance: The system continues to operate as a whole, even if an individual server fails or cannot be reached.

By looking at these choices, you can tell that it would definitely be ideal to have all three of these things guaranteed, but it's theoretically impossible. In the real world, each NoSQL database picks two of the three options, and usually develops some kind of process to mitigate the impact of the third, unhandled property.

We'll talk about which approach CouchDB takes shortly, but there is still a bit to learn about another concept that NoSQL databases avoid: ACID.

ACID

ACID is a set of properties that apply to database transactions, which are the core of traditional relational databases. While transactions are incredibly powerful, they are also one of the things that make reading and writing quite a bit slower in relational databases.

ACID is made up of four main properties:

  • Atomicity: This is an all or nothing approach to dealing with data. Everything in the transaction must happen successfully, or none of the changes are committed. This is a key property whenever money or currency is handled in a system, and requires a system of checks and balances.

  • Consistency: Data will only be accepted if it passes all of the validation in place on the database, such as triggers, data types, and constraints.

  • Isolation: Transactions will not affect other transactions that are occurring, and other users won't see partial results of a transaction in progress.

  • Durability: Once the data is saved, it is safe against errors, crashes, and other software malfunctions.

Again, as you read through the definition of ACID, you are probably thinking to yourself, "These are all must haves!" That may be the case, but keep in mind that most NoSQL databases do not fully employ ACID, because it's near impossible to have all of these restrictions and still have blazing fast writes to data.

So what does all of that mean?

I've given you a lot of definitions now, but let's try to wrap it together into a few simple lists. Let's talk through the advantages and disadvantages of NoSQL databases, when to use, and when to avoid NoSQL databases.

Advantages of NoSQL databases

With the introduction of NoSQL databases, there are lot of advantages:

  • You can do things that simply weren't possible with the processing and query power of traditional relational databases.

  • Your data is scalable and flexible, allowing it to scale to size and complexity faster, right out of the box.

  • There are new data models to consider. You don't have to force your data into a relational model if it doesn't make sense.

  • Writing data is blazing fast.

As you can see, there are some clear advantages of NoSQL databases, but as I mentioned before, there are still some negatives that we need to consider.

Negatives of NoSQL databases

However, along with the good, there's also some bad:

  • There are no common standards; each database does things just a little bit differently

  • Querying data does not involve the familiar SQL model to find records

  • NoSQL databases are still relatively immature and constantly evolving

  • There are new data models to consider; sometimes it can be confusing to make your data fit

  • Because a NoSQL database avoids the ACID model, there is no guarantee that all of your data will be successfully written

Some of those negatives may be pretty easy for you to stomach, except for NoSQL's avoidance of the ACID model.

When you should use NoSQL databases

Now that we have a good take on the advantages and disadvantages, let's talk about some great use cases for using NoSQL databases:

  • Applications that have a lot of writing

  • Applications where the schema and structure of the data might change

  • Large amount of unstructured or semi-structured data

  • Traditional relational databases feel restricting, and you want to try something new.

That list isn't exclusive, but there are no clear definitions on when you can use NoSQL databases. Really, you can use them for just about every project.

When you should avoid NoSQL databases

There are, however, some pretty clear areas that you should avoid when storing data in NoSQL.

  • Anything involving money or transactions. What happens if one record doesn't save correctly because of NoSQL avoidance of the ACID model or the data isn't 100 percent available because of the distributed system?

  • Business critical data or line of business applications, where missing one row of data could mean huge problems.

  • Heavily-structured data requiring functionality in a relational database.

For all of these use cases, you should really focus on using relational databases that will make sure that your data is safe and sound. Of course, you can always include NoSQL databases where it makes sense.

When choosing a database, it's important to remember that "There is no silver bullet." This phrase is used a lot when talking about technology, and it means that there is no one technology that will solve all of your problems without having any side effects or negative consequences. So choose wisely!

Chapter 1. Introduction to CouchDB

Welcome to CouchDB and PHP Web Development Beginner's Guide. In this book, we will learn the ins and outs of building a simple but powerful website using CouchDB and PHP. For you to understand why we do certain things in CouchDB, it's first important for you to understand the history of NoSQL databases and learn CouchDB's place in database history.

In this chapter we will:

  • Go over a brief history of databases and their place in technology
  • Talk about how databases evolved into the concept of NoSQL
  • Define NoSQL databases by understanding different classifications of NoSQL databases, the CAP theorem and its avoidance of the ACID model
  • Look at the history of CouchDB and its main contributors
  • Talk about what makes CouchDB special

Let's start by looking at the evolution of databases and how NoSQL arrived on the scene.

The NoSQL database evolution

In the early 1960s, the term database was introduced to the world as a simple layer that would serve as the backbone behind information systems. The simple concept of separating applications from data was new and exciting, and it opened up possibilities for applications to become more robust. At this point, databases existed first as tape-based devices, but soon became more usable as system direct-access storage on disks.

In 1970, Edgar Codd proposed a more efficient way of storing data — the relational model. This model would also use SQL to allow the applications to find the data stored within its tables. This relational model is nearly identical to what we know as traditional relational databases today. While this model was widely accepted, it wasn't until the mid 1980s that there was hardware that could actually make effective use of it. By 1990, hardware finally caught up, and the relational model became the dominant method for storing data.

Just as in any area of technology, competition arose with Relational Database Management Systems (RDBMS) . Some examples of popular RDMBS systems are Oracle, Microsoft SQL Server, MySQL, and PostgreSQL.

As we moved past the year 2000, applications began to produce incredible amounts of data through more complex applications. Social networks entered the scene. Companies wanted to make sense of the vast amounts of data that were available. This shift brought up some serious concerns about the datastructure, scalability, and availability of data that the relational model didn't seem to handle. With the uncertainty of how to manage this large amount of ever-changing data, the term NoSQL emerged.

The term NoSQL isn't short for "no SQL;" it actually stands for "not only SQL". NoSQL databases are a group of persistent solutions, which do not follow the relational model and do not use SQL for querying. On top of that, NoSQL wasn't introduced to replace relational databases. It was introduced to complement relational databases where they fell short.

What makes NoSQL different

Besides the fact that NoSQL databases do not use SQL to query data, there are a few key characteristics of NoSQL databases. In order to understand these characteristics, we'll need to cover a lot of terminology and definitions. It's not important that you memorize or remember everything here, but it's important for you to know exactly what makes up a NoSQL database.

The first thing that makes NoSQL databases different is their data structure. There are a variety of different ways in which NoSQL databases are classified.

Classification of NoSQL databases

NoSQL databases (for the most part) fit into four main data structures:

  • Key-value stores: They save data with a unique key and a value. Their simplicity allow them to be incredibly fast and scale to enormous sizes.
  • Column stores: They are similar to relational databases, but instead of storing records, they store all of the values for a column together in a stream.
  • Document stores: They save data without it being structured in a schema, with buckets of key-value pairs inside a self-contained object. This datastructure is reminiscent of an associative array in PHP. This is where CouchDB lands on the playing field. We'll go much deeper into this topic in Chapter 3, Getting Started with CouchDB and Futon.
  • Graph databases: They store data in a flexible graph model that contains a node for each object. Nodes have properties and relationships to other nodes.

We won't go too deeply into examples of each of these types of databases, but it's important to look at the different options that are out there. By looking at databases at this level, it's relatively easy for us to see (in general) how the data will scale to size and complexity, by looking at the following screenshot:

Classification of NoSQL databases

If you look at this diagram, you'll see that I've placed a Typical Relational Database with a crude performance line. This performance line gives you a simple idea of how a database might scale in size and complexity. How is it possible that NoSQL databases perform so much better in regards to high size and complexity of data?

For the most part, NoSQL databases are scalable because they rely on distributed systems and ignore the ACID model. Let's talk through what we gain and what we give up through a distributed system, and then define the ACID model.

When talking about any distributed system (not just storage or databases), there is a concept that defines the limitations of what you can do. This is known as the CAP theorem.

CAP theorem

Eric Brewer introduced the CAP theorem in the year 2000. It states that in any distributed environment, it is impossible for it to provide three guarantees.

  • Consistency: All the servers in the system will have the same data. So, anyone using the system will get the latest data, regardless of which node they talk to in the distributed system.
  • Availability: All of the servers will always return data.
  • Partition-tolerance: The system continues to operate as a whole, even if an individual server fails or cannot be reached.

By looking at these choices, you can tell that it would definitely be ideal to have all three of these things guaranteed, but it's theoretically impossible. In the real world, each NoSQL database picks two of the three options, and usually develops some kind of process to mitigate the impact of the third, unhandled property.

We'll talk about which approach CouchDB takes shortly, but there is still a bit to learn about another concept that NoSQL databases avoid: ACID.

ACID

ACID is a set of properties that apply to database transactions, which are the core of traditional relational databases. While transactions are incredibly powerful, they are also one of the things that make reading and writing quite a bit slower in relational databases.

ACID is made up of four main properties:

  • Atomicity: This is an all or nothing approach to dealing with data. Everything in the transaction must happen successfully, or none of the changes are committed. This is a key property whenever money or currency is handled in a system, and requires a system of checks and balances.
  • Consistency: Data will only be accepted if it passes all of the validation in place on the database, such as triggers, data types, and constraints.
  • Isolation: Transactions will not affect other transactions that are occurring, and other users won't see partial results of a transaction in progress.
  • Durability: Once the data is saved, it is safe against errors, crashes, and other software malfunctions.

Again, as you read through the definition of ACID, you are probably thinking to yourself, "These are all must haves!" That may be the case, but keep in mind that most NoSQL databases do not fully employ ACID, because it's near impossible to have all of these restrictions and still have blazing fast writes to data.

So what does all of that mean?

I've given you a lot of definitions now, but let's try to wrap it together into a few simple lists. Let's talk through the advantages and disadvantages of NoSQL databases, when to use, and when to avoid NoSQL databases.

Advantages of NoSQL databases

With the introduction of NoSQL databases, there are lot of advantages:

  • You can do things that simply weren't possible with the processing and query power of traditional relational databases.
  • Your data is scalable and flexible, allowing it to scale to size and complexity faster, right out of the box.
  • There are new data models to consider. You don't have to force your data into a relational model if it doesn't make sense.
  • Writing data is blazing fast.

As you can see, there are some clear advantages of NoSQL databases, but as I mentioned before, there are still some negatives that we need to consider.

Negatives of NoSQL databases

However, along with the good, there's also some bad:

  • There are no common standards; each database does things just a little bit differently
  • Querying data does not involve the familiar SQL model to find records
  • NoSQL databases are still relatively immature and constantly evolving
  • There are new data models to consider; sometimes it can be confusing to make your data fit
  • Because a NoSQL database avoids the ACID model, there is no guarantee that all of your data will be successfully written

Some of those negatives may be pretty easy for you to stomach, except for NoSQL's avoidance of the ACID model.

When you should use NoSQL databases

Now that we have a good take on the advantages and disadvantages, let's talk about some great use cases for using NoSQL databases:

  • Applications that have a lot of writing
  • Applications where the schema and structure of the data might change
  • Large amount of unstructured or semi-structured data
  • Traditional relational databases feel restricting, and you want to try something new.

That list isn't exclusive, but there are no clear definitions on when you can use NoSQL databases. Really, you can use them for just about every project.

When you should avoid NoSQL databases

There are, however, some pretty clear areas that you should avoid when storing data in NoSQL.

  • Anything involving money or transactions. What happens if one record doesn't save correctly because of NoSQL avoidance of the ACID model or the data isn't 100 percent available because of the distributed system?
  • Business critical data or line of business applications, where missing one row of data could mean huge problems.
  • Heavily-structured data requiring functionality in a relational database.

For all of these use cases, you should really focus on using relational databases that will make sure that your data is safe and sound. Of course, you can always include NoSQL databases where it makes sense.

When choosing a database, it's important to remember that "There is no silver bullet." This phrase is used a lot when talking about technology, and it means that there is no one technology that will solve all of your problems without having any side effects or negative consequences. So choose wisely!

Introduction to CouchDB

For this book and for a variety of my own projects and startups, I chose CouchDB. Let's take a historical look at CouchDB, then quickly touch on its approach to the CAP theorem, and its strengths and weaknesses.

The history of CouchDB

In April 2005, Damien Katz posted a blog entry about a new database engine he was working on, later to be called CouchDB, which is an acronym for Cluster Of Unreliable Commodity Hardware. Katz, a former Lotus Notes developer at IBM, was attempting to create a fault-tolerant document database in C++, but soon after, shifted to the Erlang OTP platform. As months went by, CouchDB started to evolve under the self-funding of Damien Katz, and in February 2008, it was introduced to the Apache Incubator project. Finally, in November 2008, it graduated as a top-level project.

Damien's team, CouchOne, merged with the Membase team in 2011 to form a new company called Couchbase. This company was formed to merge CouchDB and Membase into a new product, and increase the documentation and visibility for the product.

In early 2012, Couchbase announced that it would be shifting focus from facilitating CouchDB and moving to create Couchbase Server 2.0. This new database takes a different approach to the database, which meant that it would not be contributing to the CouchDB community anymore. This news was met with some distress in the CouchDB community until Cloudant stepped in.

Cloudant, the chief CouchDB hosting company and creator of BigCouch, a fault tolerant and horizontally scalable clustering frameworking built for CouchDB, announced that they would merge their changes back to CouchDB, and take on the role of continuing development of CouchDB.

In early 2012, at the time of writing, CouchDB's most major release was 1.1.1 in March 31, 2011. But CouchDB 1.2 is looking to be released just around the corner!

Defining CouchDB

According to http://couchdb.apache.org/, CouchDB can be defined as:

  • A document database server, accessible via a RESTful JSON API
  • Ad-hoc and schema-free with a flat address space
  • Distributed, featuring robust, incremental replication with bi-directional conflict detection and management
  • Query-able and index-able, featuring a table oriented reporting engine that uses JavaScript as a query language.

You might be able to read between the lines, but CouchDB chose availability and partial-tolerance from the CAP theorem, and focuses on eventual consistency using replication.

We could go really deep into what each of these bullet points mean, because it will take the rest of the book until we've touched on them in depth. In each chapter, we'll begin to build on top of our CouchDB knowledge until we have a fully operational application in the wild.

Left arrow icon Right arrow icon

Key benefits

  • Build and deploy a flexible Social Networking application using PHP and leveraging key features of CouchDB to do the heavy lifting
  • Explore the features and functionality of CouchDB, by taking a deep look into Documents, Views, Replication, and much more.
  • Conceptualize a lightweight PHP framework from scratch and write code that can easily port to other frameworks

Description

CouchDB is a NoSQL database which is making waves in the development world. It's the tool of choice for many PHP developers so they need to understand the robust features of CouchDB and the tools that are available to them.CouchDB and PHP Web Development Beginner's Guide will teach you the basics and fundamentals of using CouchDB within a project. You will learn how to build an application from beginning to end, learning the difference between the "quick way"ù to do things, and the "right way"ù by looking through a variety of code examples and real world scenarios. You will start with a walkthrough of setting up a sound development environment and then learn to create a variety of documents manually and programmatically. You will also learn how to manage their source control with Git and keep track of their progress. With each new concept, such as adding users and posts to your application, the author will take you through code step-by-step and explain how to use CouchDB's robust features. Finally, you will learn how to easily deploy your application and how to use simple replication to scale your application.

Who is this book for?

This book is for beginner and intermediate PHP developers interested in using CouchDB development in their projects. Advanced PHP developers will appreciate the familiarity of the PHP architecture and can easily learn how to incorporate CouchDB into their existing development experiences.

What you will learn

  • Set up a web development environment from scratch
  • Dive into CouchDB and learn how it looks at databases, documents, design documents, and views
  • Conceptualize and create a simple PHP framework from scratch that will interact directly with CouchDB
  • Create the ability for users to sign up, log in, and reset their password through our application using CouchDB
  • Allow users to create posts and leverage design documents, views, and lists to do the heavy lifting
  • Learn how to add some of the bells and whistles commonly used by modern social networks
  • Add security and deploy your application to production
  • Learn how to use CouchDB to replicate your database

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Jun 22, 2012
Length: 304 pages
Edition : 1st
Language : English
ISBN-13 : 9781849513593
Languages :
Tools :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Modal Close icon
Payment Processing...
tick Completed

Billing Address

Product Details

Publication date : Jun 22, 2012
Length: 304 pages
Edition : 1st
Language : English
ISBN-13 : 9781849513593
Languages :
Tools :

Packt Subscriptions

See our plans and pricing
Modal Close icon
$19.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
$199.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts
$279.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total $ 145.97
CouchDB and PHP Web Development Beginner's Guide
$50.99
Responsive Web Design with HTML5 and CSS3
$45.99
PHP and MongoDB Web Development Beginner's Guide
$48.99
Total $ 145.97 Stars icon

Table of Contents

10 Chapters
Introduction to CouchDB Chevron down icon Chevron up icon
Setting up your Development Environment Chevron down icon Chevron up icon
Getting Started with CouchDB and Futon Chevron down icon Chevron up icon
Starting your Application Chevron down icon Chevron up icon
Starting your Application
What we'll build in this book
Bones
Project setup
Time for action — creating the directories for Verge
Time for action — initializing a Git repository
Implementing basic routing
Time for action — creating our first file: index.php
Time for action — creating the .htaccess file
Time for action — hooking up our application to Bones
Time for action — creating the class structure of Bones
Time for action — creating functions to access the route on Bones creation
Time for action — creating the register function to match routes
Time for action — creating a get function in our Bones class
Time for action — creating routes for us to test against Bones
Handling layouts and views
Time for action — using constants to get the location of the working directory
Time for action — allowing Bones to store variables and the content path
Time for action — allowing our application to display a view by calling it in index.php
Time for action — creating a simple layout file
Time for action — rendering views inside of our routes
Time for action — creating views
Adding support for other HTTP methods
Time for action — retrieving the HTTP method used in a request
Time for action — altering the register to support different methods
Time for action — adding simple but powerful helpers to Bones
Adding support for complex routing
Adding support for public files
Time for action — altering .htaccess to support public files
Time for action — creating a stylesheet for the application
Publishing your code to GitHub
Get complete code from GitHub
Summary
Connecting your Application to CouchDB Chevron down icon Chevron up icon
Modeling Users Chevron down icon Chevron up icon
User Profiles and Modeling Posts Chevron down icon Chevron up icon
Using Design Documents for Views and Validation Chevron down icon Chevron up icon
Adding Bells and Whistles to your Application Chevron down icon Chevron up icon
Deploying your Application Chevron down icon Chevron up icon

Customer reviews

Top Reviews
Rating distribution
Full star icon Full star icon Full star icon Full star icon Half star icon 4.5
(6 Ratings)
5 star 50%
4 star 50%
3 star 0%
2 star 0%
1 star 0%
Filter icon Filter
Top Reviews

Filter reviews by




Amazon Customer Feb 15, 2014
Full star icon Full star icon Full star icon Full star icon Full star icon 5
I found this book to be a very useful tool. For anyone considering using CouchDB and PHP this is the place to start.
Amazon Verified review Amazon
Thomas Hunter II Sep 22, 2012
Full star icon Full star icon Full star icon Full star icon Full star icon 5
When I first picked up this book, I was expecting a boring, text-book approach to code examples for PHP talking with CouchDB. Boy was I wrong. What I found was a book that has you build a complete working application. And by complete, I mean you'll add the Twitter Bootstrap framework and it will be sexy. You'll do things the hard way, and refactor with an easier method. You'll be building a PHP framework with controllers and views. You'll be integrating a third party library for communicating with CouchDB which follows a similar simplistic approach as the framework. You'll also be keeping track of everything in GIT and committing to GitHub. These are all very important things for any application developer to know, and this book will get you into some good habits.The book starts off with an introduction to general NoSQL concepts (schema-less, fast), as well as the history of database systems. It then gets into the history of CouchDB itself. Nothing in there was too surprising, however the author did put a larger emphasis on the lack of ACID compliance than I have seen elsewhere (which means data isn't 100% guaranteed). This is a great thing to point out; it prevents CouchDB from being a fit for many projects (such as financial) however perfect for other projects (high traffic logging applications) and the risk and reward gradient for every application in-between.The author also guides the reader through the complete OS X setup process for getting Apache started, configuring it to work with PHP, getting the homebrew package manager working and subsequently CouchDB installed, running, and persisting between restarts. This means the beginning programmer can take on building this application without any prior knowledge of PHP development. I thought this was a great touch, it is probably the biggest thing holding back people from programming.Overall, this book does a great job explaining REST and the HTTP verbs, how those translate into their CRUD counterparts, how JSON is a great data language to be sent over the wire. Early on we use command line cURL for interacting with the CouchDB server, a slightly tedius method. I absolutely LOVE that the author had us run through cURL requests in the command line BEFORE sending us to the web-based GUI administration app, Futon. This puts a huge emphasis on exactly what kind of data is sent over the wire, something most MySQL developers, for example, will never know.In the third chapter of the book, the author has us dive into securing our CouchDB installation. This is an important topic that could have been otherwise omitted, since it isn't necessary to get an application up and running. By default, CouchDB is insecure, and many a developer may not ever realize this until something bad happens. By calling it out early on, the code doesn't need a large refactor later on to bolt-on authentication.The book has us building a simple PHP framework, named Bones by the author. Of course, we could have skipped building this framework and simply used raw PHP scripts (e.g. having .php extensions in your address bar). This would have been a bit easier for the reader to handle, and wouldn't have required the configuration of mod_rewrite in apache.conf. However, by using this framework, the reader is more likely to explore different frameworks down the road, instead of taking a simpler route. There is a small risk though that the user won't fully understand how Apache maps URI requests to the filesystem. Overall though, by having pretty URLs the completed application looks and feels like more of a solid accomplishment, bringing confidence to the reader.Another thing worth mentioning about the Bones framework is that it makes heavy use of PHPs Anonymous Functions. I personally love this method, as it feels a lot like the Node.js Express framework. PHP didn't get support for Anonymous Functions until version 5.3, which did come out a few years ago and is largely the standard. As a PHP beginner, by learning recent features of the languages, they may be more likely to grok the language than users learning from antiquated tutorials. The framework is currently hosted on GitHub, but it appears largely dead, not having been updated in a year.The author also guides the reader step-by-step through creating a GitHub account, something that can be a little scary to beginners. I used to teach a PHP meetup regularly, and getting an account setup was one of the hardest things to do (it would require an entire session). Creating an SSH key, and doing other configurations on the command line can be daunting, but it really is necessary. So many great projects are hosted on GitHub and the sooner a developer can get in the club the better. After each big milestone, the author has us committing our changes and pushing to GitHub. This is an excellent habit to get into and the author puts a good emphasis on it.When it gets time to have PHP begin communicating with CouchDB, the author has us do so using the cURL library built in to PHP. While cURL is incredibly powerful, it is very difficult for beginners to use. It is also overly verbose. It is generally not appreciated by the PHP crowd and there are many libraries (such as Requests for PHP) built to encapsulate the difficulty with a clean, Object Oriented interface. Luckily for us, the author was using cURL to show us one way of doing things (e.g. the hard way) before switching to a better solution. He soon has us install a library specifically meant for working with CouchDB called Sag, which follows the same beginner-friendly, simple methodology as the Bones framework. He also guides us through refactoring our existing code.The Bones framework soon gets an upgrade as we add a PHP autoloader to load Sag (and later the rest of our classes). The author really does a great job of "sneaking" in a lot good practices like this. Some other nice things that sneak their way in are using Gravatar for displaying users avatars, and using simple jQuery calls for making DELETE requests and fading out newly deleted items. There is also an emphasis on code refactoring and removing redundant code, and the reason we do so is explained nicely.Of course, the application we've bene building so far is not the prettiest (Times New Roman is everyones enemy after all). Thankfully, we soon add support for the Twitter Bootstrap framework. This allows us to quickly get a good looking website up with minimal HTML boilerplate code. Throughout the book we display code in the browser using normal text, then spruce it up with markup to follow Bootstrap methodologies.A lot of PHP developers start by using MySQL as their Database System. To help make the transition to a NoSQL database system easier for those developers, the author often compares a schema-less CouchDB document to an equivalent MySQL tables and relationships. The two approaches to building database management systems are quite different, so this is a helpful comparison.At the end of the book, we take out application and deploy it to some cloud services. The author has us go through the process of setting up a PHP Fog hosting account, as well as a Cloudant CouchDB hosting account, and of course getting the two to communicate. Both of these services offer free accounts, so this doesn't hold back the user. The account setup pages have screenshots for us to follow along and we are told how to get the PHP application to connect to the remote CouchDB instance. We also take our local CouchDB and have it replicate to the remote server, a nice feature which didn't have to make the cut for a beginners book.One thing that I didn't quite understand is why we used the CouchDB _users database instead of rolling our own. It could be that I'm not as familiar with CouchDB as I should be, but it seems like an application specific way would be better than a database specific method. CouchDB uses salted SHA1 password encryption, which we've seen a lot of negative press around over the past year or so. By rolling our own encryption we could have used a more secure encryption such as bcrypt.Another thing I wasn't a fan of was enabling hidden files in Finder. Personally, I would have had the users use the `ls` command in terminal, and mention that there are hidden files that aren't normally shown in Finder. For editing the config files, we could have used the `mate` command provided with Textmate (the text editor the author suggests). By using the command line more it might have made the reader a little more comfortable with it. Thankfully the author does provide a command to disable hidden files once we're done.Overall, CouchDB and PHP Web Development Beginner's Guide is an amazing book for any beginner looking to get into building PHP applications to persist data using CouchDB. There are many good practices sprinkled into the pages within. Anyone running a computer with OS X can follow along, even if they have no prior experience with programming or databases. The verbose code explanations do a great job explaining what the author is having us build. If you are interested in either of these technologies I highly recommend picking up this book.
Amazon Verified review Amazon
Brent Eyler Jun 25, 2012
Full star icon Full star icon Full star icon Full star icon Full star icon 5
The author does a terrific job complementing the learning with actual coding to reinforce what I'm reading. Really enjoying it and recommend for anyone seeking to learn CouchDB with PHP
Amazon Verified review Amazon
Dave Poon Sep 25, 2012
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
Recently I have been researching about NoSQL, I was looking for a NoSQL database to add more capability to one of my web applications. And I heard something good about CouchDB, I went to the CouchDB official website, I had a quick read at the documentation, however, there're not much tutorials and books about CouchDB and PHP until this book CouchDB and PHP Web Development Beginner's Guide has been published. I found this book is a great resource for learning how the CouchDB and PHP work for web development.The hands-on tutorial writing style that make complicated concept easier to understand, we just need to follow every step, we will discover and learn more through each step. The great thing is not just follow the steps, the author also explain "What Just Happened" for each step that have done. This make me easier to understand the code better, not like some books, we just follow and put the code, run it, it's work, and no explanation about what just happened about the example codes.One of the best parts that I really like is the author teaches you to create a PHP MVC framework called "Bones framework" with CouchDB database, this book teach you how to build a best practices PHP and CouchDB web application from scratch. The author also inform us to use Git (version control system) to commit your code once you have done the changes to your code. This is a great practice to use version control system to keep track of your source code while developing our application. I am really impressed with details like this, it's not just teach you one thing, and forget the others, the author also teach you good programming practice when building a PHP and CouchDB web application.This is the beginner's guide series of the book, however, this book is not easy for beginner to understand. You need or recommend to have experience in object oriented PHP programming, and understand what MVC Model-View-Controller design pattern is, and also have experience using command line for basic system operations.
Amazon Verified review Amazon
Raistrick Jul 27, 2012
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
I like the way this book is written. Software books are always nice when you can be taken on a journey through learning (provided you have the time) and this book takes time to introduce you to lots of techniques and tools that will make CouchDB development easier and more organised. For someone wanting to swap an SQL database for a NoSQL database, whilst keeping the server-side programming consistent with previous methods, then this book is great. I'm looking to do this so that the site and data management can be kept separate and take some of the load off the CouchDB developer. However, at the rate that these technologies are changing, along with the errors you are likely to encounter developing anything in CouchDB, you'll find the IRC channel and stackoverflow far more use.
Amazon Verified review Amazon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.

Modal Close icon
Modal Close icon